प्राथमिकता (आदि) के लिए गितुब मुद्दों का प्रबंधन कैसे करें? [बन्द है]

49

मैं github में नया हूं, और मुद्दों का प्रबंधन करने के तरीके के बारे में सलाह ले रहा हूं। मुझे प्राथमिकता और अन्य ऑर्डर करने के विकल्प हैं, लेकिन देखते हैं कि कोई भी मौजूद नहीं है।

बग / फ़ीचर के जीवनचक्र के दौरान अन्य लोग कैसे समस्याओं का प्रबंधन करते हैं?

अग्रिम में धन्यवाद।

project-management github issue-tracking

— DJF
स्रोत

1

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

— BrainSlugs83

52

आप विभिन्न प्रकार के लेबलों को परिभाषित कर सकते हैं जैसे कि मुद्दे प्रकार , प्राथमिकताएँ जारी करना , स्टेटस स्टेटस , संस्करण टैग और शायद अधिक। यह देखने में सक्षम होने के लिए कि आप किस समूह के लेबल से संबंधित हैं, जैसे नामकरण सम्मेलन का उपयोग कर सकते हैं <label-group>:<label-name>।

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

ऊपर बताई गई योजना के अनुसार आप समूहों और संबंधित लेबल को निम्नानुसार परिभाषित कर सकते हैं।

'इश्यू टाइप' ग्रुप

प्रकार: बग
प्रकार: सुविधा
प्रकार: विचार
प्रकार: अमान्य
प्रकार: समर्थन
प्रकार: कार्य

'जारी प्राथमिकता' समूह

prio: कम
prio: सामान्य
prio: उच्च

'स्थिति जारी करें' समूह

(ये लेबल परिभाषित वर्कफ़्लो में किसी समस्या की स्थिति का वर्णन करते हैं।)

स्थिति: पुष्टि की गई
स्थिति: आस्थगित
स्थिति: ठीक-प्रतिबद्ध
स्थिति: में प्रगति
स्थिति: अधूरा
स्थिति: अस्वीकार कर दिया
स्थिति: संकल्प लिया

'सूचना जारी करें' समूह

जानकारी: प्रतिक्रिया जरूरी
जानकारी: मदद जरूरी
जानकारी: प्रगति -25
जानकारी: प्रगति-50
जानकारी: प्रगति-75

'संस्करण टैग' समूह

ver: 1.x
ver: 1.1

— जॉनी डी
स्रोत

2

लेकिन यह हल नहीं करता है, यह करता है?

— पावेल एस।

4

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

— यानिस

@YannisRizos: आप बिल्कुल महान (+1) हैं। आपकी तेजी से प्रतिक्रिया के लिए बहुत बहुत धन्यवाद, इसे हटाने के लिए, और आपकी स्पष्टीकरण के लिए भी :)

— जॉनी डी

मैं बस यह जोड़ना चाहूंगा कि जानकारी होना: प्रगति-एक्स अत्यधिक है। मैं एक जानकारी से सहमत हूँ: इन-प्रोगेस लेकिन प्रगति को निर्धारित करने के लिए थोड़ा खिंचाव है। मेरे पास कुछ मुद्दे हैं जिन्हें मैंने सोचा था कि मैं 90% किया गया था और फिर मैंने कुछ देखा और मुझे पता था कि मैं केवल 50% किया गया था। अब यह करने के लिए github पर सिर्फ मेरी राय में समय की बर्बादी होगी।

— एंटोनियोकेस

22

GitHub मुद्दा ट्रैकर काफी लचीला है। वास्तव में कोई प्राथमिकता नहीं है, न ही कोई आदेश। यह तीन प्रमुख स्तंभों के आसपास घूमता है: असाइनमेंट , लेबल और मील के पत्थर ।

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

आखिरकार, साइडबार के लिए धन्यवाद, आप इसे प्रबंधित करने में मदद करने के लिए मुद्दों की सूची को "फ़िल्टर" कर सकते हैं।

इस विषय पर एक पूर्ण ब्लॉग पोस्ट "इश्यूज़ 2.0" आपको सुविधाओं के बारे में अधिक विस्तृत जानकारी देगा।

— nulltoken
स्रोत

1

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

— डीजेफ

1

जॉनी डी के जवाब में @djf के रूप में, आप प्राथमिकताएँ निर्दिष्ट करने के लिए लेबल का उपयोग कर सकते हैं।

— डेविड ब्राउन

8

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

यह वास्तव में एक HTML टिप्पणी के रूप में इस समस्या को ही प्राथमिकता देता है:

Your normal issue text here...
<!---
@huboard:{"order":465.0}
-->

— joseph.hainline
स्रोत

मैं अब इस उद्देश्य के लिए waffle.io का उपयोग करता हूं। यह थोड़ा अच्छा है।

— joseph.hainline

5

हम अपनी परियोजनाओं के प्रबंधन के लिए जीथब पर लेबल का उपयोग कैसे करते हैं, इसका उदाहरण

श्रेणी लेबल (नेत्रहीन अलग करने के लिए सभी कैप का उपयोग भी कर सकते हैं)

कार्य
बग
फ़ीचर
विचार-विमर्श

प्राथमिकता लेबल

अति आवश्यक

हम हर चीज को सामान्य प्राथमिकता मानते हैं और वास्तव में "कम" की आवश्यकता नहीं देखते हैं। ताकि केवल एक लेबल उन चीजों को चिह्नित करने के लिए छोड़ दे, जिन पर तत्काल ध्यान देने की आवश्यकता है।

स्थिति लेबल

समीक्षा की गई (कार्यवाहक ने इसे पढ़ा है)
कतारबद्ध (शीघ्र ही इस पर काम करेंगे)
कार्य प्रगति पर है (अब इस पर कार्य कर रहा है)
अमान्य (यदि बग यह प्रतिलिपि प्रस्तुत करने योग्य नहीं है)
प्रतिक्रिया की जरूरत है (लोगों को पढ़ने और टिप्पणी करने और सहायता प्रदान करने के लिए बल्ले का संकेत)

हम सभी दस्तावेज एक विकी में रखते हैं जिसमें कैसे-कैसे, वास्तुकला, बुनियादी ढांचा, केस स्टडी, योजना और आवश्यकताएं शामिल हैं।

पुल-अनुरोध कोड समीक्षा और सुविधा चर्चा के लिए हैं यदि यह एक शाखा का हिस्सा है

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

— ब्रायन बोटराइट
स्रोत

1

मैं जीएच मुद्दों में दो प्रकार के लेबल के लिए जाता हूं - पहला मुद्दे के प्रकार से संबंधित है, और दूसरा प्राथमिकता से संबंधित है:

बग
सुविधा - (नया सामान)
वृद्धि - (मौजूदा सामान को बेहतर बनाना)
प्रश्न / डिस्कशन - (सामान पर चर्चा करते हुए)

यदि आप विकी का अच्छी तरह से उपयोग करते हैं तो प्रश्न / चर्चा आवश्यक नहीं हो सकती है। लेकिन मुझे यह पसंद है क्योंकि यह मुझे किसी विशेष व्यक्ति पर एक प्रश्न या एक विचार को निर्देशित करने की अनुमति देता है।

फिर तीन वास्तव में सरल प्राथमिकता वाले लेबल हैं:

अभी
जल्द ही
बाद में

आसान है, है ना?

— रेयान किनल
स्रोत

1

ऊपर दिए गए टैगिंग समाधानों के अलावा, हमारे पास blockingऔर blockedलेबल के रूप में हैं।

किसी मुद्दे को पहले सही व्यक्ति को सौंपा जाना चाहिए, लेकिन अगर वह व्यक्ति किसी अन्य समस्या के समाप्त होने तक इस मुद्दे पर काम करने में असमर्थ होता है, तो इस मुद्दे को इस रूप में चिह्नित किया जाता है blocked। और दूसरे मुद्दे को हैश टैग का उपयोग करके संदर्भित किया जाता है।

इसी तरह अगर कोई कार्य किसी अन्य व्यक्ति को किसी चीज़ पर काम करने से रोक रहा है, तो उसे blockingअन्य मुद्दे के संदर्भ में चिह्नित किया जाना चाहिए ।

मुझे यह पता लगाना थोड़ा मुश्किल था कि किसी विशेष व्यक्ति को सौंपी गई वस्तुओं को कैसे सूचीबद्ध किया जाए;

इसका समाधान 'खोज' आइकन पर क्लिक करना है (जिसमें कोई खोज मापदंड टाइप नहीं है) और परिणाम पृष्ठ पर बाईं ओर एक ड्रॉप-डाउन है।

— डीन राथर
स्रोत