GitHub में परित्यक्त मुद्दों के साथ क्या करना है?

Question

अगर कोई GitHub पर कोई समस्या खोलता है, लेकिन त्रुटि को पुन: उत्पन्न करने के लिए अधिक जानकारी मांगी जाती है और कभी नहीं दी जाती है, तो सामान्य प्रक्रिया क्या है? उदाहरण है ।

यहाँ लेखक कहता है कि "नौसेना टूटती है"। जबकि मेरा मानना ​​है कि यह तय है, मैं लेखक से यह सुनिश्चित करने के लिए शब्द चाहूंगा कि हम उसी चीज के बारे में बात कर रहे थे। लेकिन कभी-कभी मुद्दे के रिपोर्टर सिर्फ गायब हो जाते हैं। परित्यक्त मुद्दों के लिए एक समाप्ति तिथि निर्धारित करना एक अच्छा / सामान्य अभ्यास है ?

इन शर्तों की तरह कुछ:

• इसे डिबेट करने में सक्षम होने के लिए एक प्रश्न उठाया जाता है।
• देव टीम के आखिरी अनुत्तरित प्रश्न / टिप्पणी के बाद 2-6 महीने बीत चुके हैं।
• इसे बंद करने के समय बग को पुन: पेश नहीं किया जा सकता है (किसी भी कारण से, शायद उन्हें कभी भी पुन: प्रस्तुत नहीं किया जा सकता)।
• इसे बंद करने से 2 हफ्ते पहले एक चेतावनी जारी की जाती है।

प्रोजेक्ट्स आम तौर पर क्या करते हैं? मुझे Google पर कुछ भी नहीं मिला। इसके अलावा, मैं इसे कैसे प्रलेखित करूंगा? क्या README.md में एक सरल नोट ऊपर दिए गए बिंदुओं का विवरण देता है और इस मुद्दे की एक टिप्पणी में यह बताता है कि यह बंद होने का कारण क्यों है?

नोट: यह इस सवाल से अलग है क्योंकि बग अभी भी प्रासंगिक (या नहीं) हो सकता है, हालांकि जानकारी का अभाव है।

Comments

मेरा मानना है कि आपको कहीं न कहीं इस बात का दस्तावेज़ होना चाहिए कि आपको विश्वास है कि समस्या ठीक हो गई है (लेकिन शायद नहीं README.md)। हालाँकि, आपका प्रश्न राय का विषय हो सकता है।

— बेसिल स्टारीनेविच

अगर किसी मुद्दे के प्रस्तुतकर्ता को पुष्टि के लिए नहीं पहुँचा जा सकता है कि यह तय हो गया है, तो मैं बस इस मुद्दे को बंद कर दूंगा, एक टिप्पणी के साथ कि मूल प्रस्तुतकर्ता द्वारा फिक्स को सत्यापित नहीं किया गया था, सक्रिय रूप से उसके बारे में संपर्क करने की कोशिश करने के बाद। एक महीना। लेकिन यह मेरा विचार मात्र है।

— बार्ट वैन इनगेन शेनॉ

@BasileStarynkevitch क्षमा करें, मेरा मतलब है कि इस प्रक्रिया को README.md में दस्तावेज़ित करना है। इस मुद्दे को बंद करने के बारे में, मैं इसे इस मुद्दे में ही दस्तावेज़ित करूँगा।

— फ्रांसिस्को प्रेसेंशिया

एक बग को बंद करने के लिए

— gnat

नहीं, एक बग जो अब प्रासंगिक नहीं है वह बग के समान नहीं है जिसके लिए एक फिक्स मौजूद है लेकिन रिपोर्टर जवाब नहीं देता है।

— dcorking

Answer 1

यह एक दुविधा है: आप इस मुद्दे को "निश्चित" के रूप में बंद नहीं कर सकते, क्योंकि आप वास्तव में नहीं जानते हैं कि क्या यह तय किया गया था, या कम से कम कुछ मुद्दा तय होने पर भी, आप वास्तव में नहीं जानते कि क्या यह मुद्दा रिपोर्टर था के बारे में बात कर रहा था। दूसरी ओर, आप एक ऐसे मुद्दे को नहीं छोड़ना चाहते हैं, जो खुले तौर पर तय किया गया हो, खासकर यदि आप कभी भी इसे बंद नहीं कर पाएंगे क्योंकि आपको कभी पुष्टि नहीं मिलेगी।

तो, आपको इसे बंद करना चाहिए , लेकिन शायद "निश्चित" के रूप में नहीं। यदि आप नहीं चाहते हैं कि आप एक कस्टम क्लोज़ कारण "प्रोफ़िफ़िक्सड" या "अनकॉन्फिम्डफ़िक्स" का आविष्कार कर सकते हैं। आप बस यह भी कह सकते हैं "पुन: पेश नहीं कर सकते", और एक ही बग के लिए और अधिक उत्तरदायी रिपोर्टर के लिए पॉप अप करने के लिए प्रतीक्षा करें।

हालांकि, आपको बग पर संसाधनों का खर्च नहीं करना चाहिए, जिसके लिए आप कभी नहीं जान पाएंगे कि यह वास्तव में तय किया गया था या नहीं।

Comments

अब जब मैं इसे देखता हूं, तो यह उपयोगकर्ता प्रोफ़ाइल में "हटाए गए उपयोगकर्ता" भी कहता है ... इसलिए मुझे लगता है कि भूत जवाब नहीं देगा। उत्तर के लिए धन्यवाद, मैं एक कस्टम टैग के साथ बंद कर दूंगा।

— फ्रांसिस्को प्रेसेंशिया

बेमतलब का लगता है। क्या आप टिकट में विवरण से मुद्दे को पुन: पेश कर सकते हैं? नहीं? Unreproducible।

— एबीमैगिल

शराब बगज़िला में एक विशेष स्थिति है: उदाहरण ।

— रुस्लान

'अमान्य' एक और अच्छा, सामान्य, राज्य है। GitHub में, इसे एक लेबल के रूप में जोड़ा जा सकता है और बाद में समस्या बंद हो सकती है।

— कैटरपिलर

इसे "AbandonedByOpener" या "RequiredInformationMissing" के रूप में बंद करें। ठीक ऐसा ही हुआ। और कोई भी स्पष्ट रूप से देख सकता है कि आपने इस मुद्दे से क्यों नहीं निपट लिया।

— यूएसआर

Answer 2

आपका मुख्य प्रश्न पहले से ही उत्तर दिया गया था, लेकिन आपने प्रक्रिया के दस्तावेजीकरण के बारे में भी पूछा था और इसका उत्तर देने की आवश्यकता है।

कई परियोजनाओं में मैंने जो समाधान देखा है, वह परियोजना की README.md में नहीं है, लेकिन योगदानकर्ताओं के लिए README फ़ाइल - README में एक विशेष योगदान है। यह फ़ाइल आपके द्वारा अपनी परियोजना में योगदान करने वाले लोगों को जानने के लिए सब कुछ का वर्णन करती है - यह कोड (नामकरण सम्मेलनों, मॉड्यूल संगठन आदि) के बारे में हो या प्रक्रिया के बारे में हो (कैसे लिखना है, टिकट कैसे संभालना है)। यह फ़ाइल .MDप्रोजेक्ट में एक और फ़ाइल हो सकती है , या पूरी तरह से अलग रिपॉजिटरी में रखी जा सकती है (इसलिए इसे आपकी सभी परियोजनाओं के बीच साझा किया जा सकता है)। बस इसे मुख्य से लिंक करने के लिए मत भूलना README.md!

उस सूचना को मुख्य README से अलग करने का उद्देश्य यह है कि आमतौर पर परियोजना के उपयोगकर्ता का केवल एक अंश सीधे इसमें योगदान देता है। अधिकांश उपयोगकर्ताओं को उस जानकारी से ऊबने की आवश्यकता नहीं है - उन्हें बस यह जानना होगा कि आपकी परियोजना क्या करती है और इसका उपयोग कैसे करना है, और मुख्य README में क्या होना चाहिए। आपकी परियोजना के मामले में योगदान खंड बहुत छोटा है, इसलिए यह मुख्य README को संलग्न नहीं करता है - लेकिन यदि आप उन सभी वर्कफ़्लोज़ को दस्तावेज़ित करते हैं, जिनका आप योगदान करना चाहते हैं, तो इसका पालन करना ठीक नहीं होगा।

ध्यान दें कि कोई भी उपयोगकर्ता बग खोल सकता है, इसलिए यदि आपके पास बग खोलने के बारे में विशेष आवश्यकताएं हैं, तो आपको उन्हें मुख्य README में रखना चाहिए (हालांकि इसे shourt रखने की कोशिश करें - कोड योगदानकर्ताओं के विपरीत, बग रिपोर्टर शायद कम लंबाई में जाने के लिए तैयार होंगे। अध्ययन करना और अपने नियमों के अनुरूप होना)। हालांकि, वह व्यक्ति जो वास्तव में बग को ठीक करता है और टिकट को बंद कर देता है (जैसा कि आप या आपके द्वारा पुष्टि किए गए योगदानकर्ताओं में से एक है) एक प्रत्यक्ष contributer है और योगदान README को पढ़ने की उम्मीद की जा सकती है - इसलिए जब रिपोर्टर करता है तो टिकट बंद करने की प्रक्रिया जवाब नहीं वहाँ वर्णित किया जाना चाहिए।

Comments

गितुब पर, कोई विशेष रूप से एक CONTRIBUTING.mdदस्तावेज का उपयोग कर सकता है । इस दस्तावेज़ को विशेष रूप से गितुब द्वारा व्यवहार किया जाता है, अर्थात्, यह खुले अंक पृष्ठ के शीर्ष से जुड़ा हुआ है, इसलिए यह मुद्दा पत्रकारों के लिए फ्रंट-एंड-सेंटर है। देखें: help.github.com/articles/…

— cbojar

Answer 3

मैं इसे आसपास के अभ्यासों के बारे में अधिक प्रश्न के रूप में पढ़ता हूं कि किसी अन्य चीज़ की तुलना में असत्यापित बग (गीथूब के मुद्दे पर नजर रखने वाले) का उपयोग कैसे किया जाए।

मेरे लिए, कि मैं इस्तेमाल किया है अन्य मुद्दे पर नजर रखने वालों के आधार पर एक बल्कि सीधे आगे जवाब है। Github किसी को भी किसी भी वर्कफ़्लो का उपयोग करने के लिए मजबूर नहीं करता है और यह इसे बहुत लचीला बनाता है ... और इसके डिफ़ॉल्ट कॉन्फ़िगरेशन में बेकार है।

Bugzilla के डिफ़ॉल्ट वर्कफ़्लो को देखते हुए:

मैं वहाँ एक बहुत ही महत्वपूर्ण बात यह है कि बाहर बिंदु लिए जा रहा हूँ - यह हो जाता है का समाधान के रूप में तय होने से पहले ही हो जाता है बंद कर दिया जा रहा है के बाद सत्यापित । मूल Github वर्कफ़्लो केवल लाल (खुला) और हरा (बंद) अवस्था दिखाता है।

इस प्रकार, एक दृष्टिकोण अतिरिक्त जानकारी दिखाने की कोशिश करने के लिए जीथब ( आपके आवेदन के लेबल ) के भीतर लेबल का उपयोग करता है । आप समस्या को बंद करने के बाद एक लेबल बना सकते हैं जो 'असत्यापित' और 'सत्यापित' हो। ध्यान दें कि यह केवल एक दृष्टिकोण है - यदि आप खोजते हैं तो आप लेबल के उपयोग के दर्जनों विभिन्न दृष्टिकोण पा सकते हैं। यहाँ, सवाल (प्राथमिकता, आदि) के लिए जीथब मुद्दों का प्रबंधन कैसे करें? इसे संबोधित करता है।

आपने इसे ठीक कर लिया है, एक डेवलपर के दृष्टिकोण से यह किया जाता है। गितुब पर मसला बंद करो। उस पर 'असत्यापित' लेबल लागू करें। एक बार पिछले संस्करण में बग से परिचित किसी व्यक्ति का कहना है "हाँ, यह तय हो गया है" आप लेबल को 'सत्यापित' में बदल सकते हैं। अगर वे कहते हैं कि यह नहीं था, तो आप इसे फिर से खोलें।

ध्यान दें कि 'निश्चित' के अलावा अन्य हल किए गए राज्य भी हैं। 'वॉन्टफिक्स' है (फिक्स एक ऐसी चीज है जिसे केवल वर्तमान संरचना के साथ नहीं किया जा सकता है) और 'वर्कटफॉर्म' (बग को पुन: पेश नहीं किया जा सकता) और 'अमान्य' (आप ओएस के बारे में बग दर्ज कर रहे हैं, नहीं अनुप्रयोग प्रकार)।

Answer 4

मैं दो में से एक विचार लूंगा, मैं इस बात पर निर्भर था कि मैं मूल रिपोर्टर के रूप में एक ही बात कर रहा था:

1) चूंकि रिपोर्टर अब उपलब्ध नहीं है, इसलिए डीम कि सवाल में बग का मतलब है जो भी आप तय किए गए थे। यदि यह मदद करता है, तो परीक्षण मामलों को स्पष्ट करने के लिए संलग्न करें कि आपको क्या विफलता मिली। बग रिपोर्ट पर विस्तार से वर्णन करें कि यह आपके द्वारा तय किया गया था और एक नोट को छोड़ दें, जैसे "मुझे विश्वास है कि यह 'नेवले ब्रेक' का अर्थ है, कृपया फिर से खोलें या एक नया बग बढ़ाएं यदि यह आपका मतलब नहीं है"। बग को निश्चित रूप से चिह्नित करें।

2) चूंकि रिपोर्टर अब उपलब्ध नहीं है, इसलिए डीम कि बग को नहीं जाना (जाना जा सकता है) पुन: पेश किया जाता है, क्योंकि इसके लिए केवल रिपोर्टर का शब्द ही पुष्टि करेगा कि यह वही बात है जो उन्होंने रिपोर्ट की थी। आपके द्वारा तय की गई चीज़ का वर्णन करने के लिए एक नया बग उठाएँ, क्रेडिट उल्लेख के लिए कि यह अनुपस्थित रिपोर्टर द्वारा वर्णित शर्तों के तहत देखा गया था, दोनों पर ध्यान दें कि वे डुप्लिकेट हो सकते हैं, तय किए गए नए बग को चिह्नित करें और इस एक को चिह्नित करें या अमान्य एक नोट के साथ प्रतिलिपि प्रस्तुत करने योग्य नहीं है, जैसे "मैं 'नेवी ब्रेक' से आपका मतलब नहीं निकाल सकता, लेकिन मैंने जो समस्या पाई है, उसे हल किया है। कृपया फिर से खोलें या एक नया बग बढ़ाएं, यदि नौसेना अभी भी अंदर का वर्णन करती है। अधिक विस्तार क्या गलत है "।

के रूप में timescale के लिए, मुझे लगता है कि यह परियोजना पर निर्भर होना चाहिए। यदि आप बहुत प्रतिक्रियाशील हैं, और इस बग के साथ काम कर रहे हैं, तो इसे उठाए जाने के दिनों के भीतर, तो लोगों को यह समझना चाहिए कि आप समस्या को हल करने से पहले प्रतिक्रिया के लिए हफ्तों इंतजार नहीं करेंगे। दूसरी ओर, यदि यह महीनों से आपके स्लैशपाइल पर है, तो यह आपको किसी भी परेशानी के बिना एक या दो महीने के लिए खोल सकता है।

इस कारण से मुझे नहीं लगता कि एक विशेष समय सीमा है जो "अच्छा अभ्यास" का गठन करती है, या आपको अपनी नीति को प्रकाशित करने और उस पर टिकने की आवश्यकता है। निश्चित रूप से आप यह रिकॉर्ड नहीं करना चाहेंगे कि जब तक आप उनसे संपर्क करने का प्रयास नहीं करते हैं, तब तक रिपोर्टर से संपर्क नहीं किया जा सकता है। लेकिन मुझे यह भी नहीं दिखाई पड़ता है कि कई चेतावनियों को एक समय सीमा तक गिनते हुए छोड़ दिया जाए: या तो वे बग को फिर से देख लेंगे और कुछ कहना चाहेंगे, या वे नहीं करेंगे।