Pods: गिटहब लेबल

~"चेंजलॉग की आवश्यकता है" एक लेबल के रूप में जाने में सक्षम हो सकता है। मैं चेंजलॉग अपडेट को मर्ज प्रक्रिया का हिस्सा बना रहा हूं और उस अल्पकालिक लेबल का उपयोग नहीं कर रहा हूं। ~
किया हुआ

मेरे पास ठीक दांतों वाली कंघी से गुजरने का समय नहीं है, लेकिन मुझे पहली स्किम में तुरंत कुछ भी नहीं दिख रहा है। मुझे एक ठोस पास पर कुछ मोड़, चूक, विलोपन मिल सकते हैं, लेकिन मेरी प्रवृत्ति यह है कि यह वर्तमान लेबल प्रणाली पर प्रस्तावित के रूप में एक बड़ा सुधार होगा।

"पैच" वह है जिसे मैंने अपने वर्कफ़्लो में कभी उपयोग नहीं किया है, क्योंकि यह मुझे बेमानी लगता है। अगर यह एक पीआर है, तो यह एक पैच है। लेकिन @ sc0ttkclark ने परंपरागत रूप से उस लेबल का उपयोग किया है, इसलिए इसमें उसके लिए कुछ वर्कफ़्लो मान हो सकता है।

~ Component: Multi-site एक अच्छा अतिरिक्त होगा, यह REST API जैसा एक और क्षेत्र है, और टेम्प्लेट जो फ़िल्टरिंग उद्देश्यों के लिए टैगिंग शुरू करने में सहायक होंगे।~

किया हुआ

फोकस: पिछड़ी संगतता
फोकस: संगतता/बहिष्करण
फोकस: संगतता

इन तीनों के लिए, शायद परिष्कृत:

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

संपादित करें: यह हो गया

अब तक के उस छोटे से सामान के अलावा, मैं इस पर आगे बढ़ रहा हूँ। वर्गीकरण बहुत बेहतर है और मैं 2.7.7 के बावजूद इसका उपयोग करना चाहता हूं।

मैं पहले @jimtrue और @ sc0ttkclark से भी स्पष्ट संकेत प्राप्त करना चाहता हूं।

Discussion और Team Discussion क्या अंतर है? क्या उन्हें Needs: Developer Feedback बदला जा सकता है?

Integration क्या है?

ये रहा मेरा दूसरा पास। कुछ नए परिवर्धन/परिवर्तन। प्रमुख प्रश्नवाचक चिह्नों का उपयोग न करने पर उन्हें छोड़ा जा सकता है:

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

चर्चा और टीम चर्चा में क्या अंतर है? क्या उन्हें आवश्यकताएँ: डेवलपर फ़ीडबैक से बदला जा सकता है?

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

एकीकरण क्या है?

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

मुझे यकीन नहीं है कि 'आवश्यकताएं:' अनुभाग बेहतर है... मुझे "स्थिति:" के हिस्से के रूप में उनका विचार पसंद आया क्योंकि मुझे लगता है कि अक्सर उनका उपयोग किया जाता है।

संपादित करें: यह सब संबोधित किया गया है

~ मुझे लगता है कि निम्नलिखित कीवर्ड वास्तव में प्रकार हो सकते हैं: रिलीज, समर्थन और उपकरण।~

~ वे टिकट के प्रकार की तरह लगते हैं जिनका वर्णन किसी अन्य ने नहीं किया है।~

किया हुआ

साथ ही, स्क्रॉल करने के लिए मुझे आश्चर्य है कि क्या हमें नए संस्करण पोस्ट करने के बजाय सूची को प्रारंभिक संदेश में अद्यतित रखना चाहिए?

किया हुआ।

मुझे इसका विचार पसंद है:

आवश्यकताएँ: डेवलपर प्रतिक्रिया
आवश्यकताएँ: अनुसंधान
आवश्यकताएँ: कार्यसूची
आवश्यकताएँ: परीक्षण
आवश्यकताएँ: उपयोगकर्ता प्रतिक्रिया
आवश्यकताएँ: सत्यापन / प्रजनन
जरूरत: वोट

लेकिन 'उपयोगकर्ता प्रतिक्रिया' और 'सत्यापन/पुनरुत्पादन' वास्तव में 'स्थिति/कार्यप्रवाह' हैं जैसा कि @pglewis ने ऊपर उल्लेख किया है या हम उन्हें स्थिति के रूप में रख सकते हैं: अवरोधक के लिए आवश्यकताओं के साथ अवरोधक अवरोधक के लिए 'कारण' है।

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

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

मैंने इसे देखा, और मैं निम्नलिखित परिवर्तन देखना चाहता हूं:

• प्रकार : Support और Docs Update ( Support को Keyword से हटाकर)
• घटक : हमें support.pods.i o या doc.pods.io में Component । उन दो रेपो की अपनी परियोजनाएं हैं। घटक पूरी तरह से पॉड्स कोर क्षेत्र के फोकस के लिए होना चाहिए।
• प्राथमिकता : Focus को कीवर्ड से Priority । Blocker ठीक है जब तक हम कारण जानते हैं, जो आवश्यकता से आना चाहिए।

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

मैंने WaffleBot को हटा दिया है ताकि उन स्थितियों को अब स्वचालित रूप से नहीं जोड़ा जाना चाहिए।

अवरोधक इंगित करता है कि यह तब तक काम नहीं किया जा सकता जब तक आवश्यकताओं को संभाला नहीं जाता है।

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

मेरे वर्कफ़्लो में 'ब्लॉकर' के माध्यम से किसी चीज़ को होल्ड करने के रूप में चिह्नित करने का कोई कारण नहीं है ... वर्तमान स्थिति लेबल का अर्थ यह होना चाहिए। मुझे "उपयोगकर्ता प्रतिक्रिया की आवश्यकता है" और "अवरोधक" की आवश्यकता नहीं है क्योंकि पहले वाला मुझे पहले ही बताता है कि यह अवरुद्ध है और क्यों।

मेरा मत है कि हम इसे इस तरह उपयोग करते हैं और इसे "प्राथमिकता: *" के अंतर्गत रखते हैं क्योंकि यह मेरे लिए एकदम सही वर्णन है।

~मुझे लगता है कि "फोकस" को भी कीवर्ड्स से प्रायोरिटी की ओर जाना चाहिए।~ कीवर्ड्स को छोड़कर

मुझे इसका विचार पसंद है:

आवश्यकताएँ: डेवलपर प्रतिक्रिया
आवश्यकताएँ: अनुसंधान
आवश्यकताएँ: कार्यसूची
आवश्यकताएँ: परीक्षण
आवश्यकताएँ: उपयोगकर्ता प्रतिक्रिया
आवश्यकताएँ: सत्यापन / प्रजनन
जरूरत: वोट

ये मुख्य रूप से मेरे लिए टिकट की स्थिति हैं इसलिए मैं उन्हें अभी के लिए वहां रखने का प्रस्ताव दूंगा। यदि लंबाई चिंता का विषय है तो हम कुछ को संक्षिप्त कर सकते हैं ("स्थिति: देव एफबी की आवश्यकता है", "स्थिति: सत्यापन की आवश्यकता/रेप्रो")।

मुझे लगता है कि "टास्कलिस्ट की जरूरत है" जा सकता है। मुझे नहीं लगता कि यह एक लेबल की गारंटी देने के लिए पर्याप्त होता है। मुझे यकीन नहीं है कि मैंने कभी इसका इस्तेमाल किया है, शायद ही कभी ऐसा होता है। शायद "टेस्ट की जरूरत है" के लिए ठीक वैसा ही। शेष सभी "स्थिति: *" के तहत मेरे लिए बिल्कुल फिट हैं।

इसके अलावा, सूची मेरे लिए अच्छी तरह से आकार ले रही है, हमें शायद रंग योजना पर चर्चा करनी चाहिए।

कुछ और जिन्हें शायद "नीड्स टास्कलिस्ट" के साथ स्टैटस से ट्रिम किया जा सकता है:

• ~"समीक्षा के लिए तैयार" शायद "समीक्षा के लिए तैयार" का अनपेक्षित दोहराव है~ इसे छोड़ना
• "यूनिट टेस्टेड" एक स्थिति नहीं है (अभी तक कम से कम नहीं), अधिक विविध... तो शायद कीवर्ड में ले जाया गया है?

इससे मुझे स्थिति सूची अच्छी लग रही है।

"समीक्षा के लिए तैयार" शायद "समीक्षा के लिए तैयार" का अनपेक्षित दोहराव है

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

शायद "टेस्ट की जरूरत है" के लिए ठीक वैसा ही।

अधिक कोड कवरेज चाहने के लिए (हालाँकि मैंने अभी तक व्यक्तिगत रूप से इस क्षेत्र पर अधिक ध्यान नहीं दिया है), यह लेबल यह कहने के लिए हो सकता है कि "फिक्स अच्छा है, लेकिन हम देखना चाहते हैं कि यूनिट परीक्षण किनारों को कवर करते हैं/सत्यापित करते हैं विशिष्ट बग फिक्स इसलिए कोई प्रतिगमन पेश नहीं किया गया है"।

मुझे लगता है कि "फोकस" को भी खोजशब्दों से प्राथमिकता पर जाना चाहिए।

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

अवरोधक इंगित करता है कि यह तब तक काम नहीं किया जा सकता जब तक आवश्यकताओं को संभाला नहीं जाता है।

मैं यहां फिल से सहमत हूं - मुझे इसका मतलब यह समझ में आया कि जिस मुद्दे में यह लेबल है वह _release_ के लिए अवरोधक है। हो सकता है कि जिम की व्याख्या Status: Is Blocked या इसी तरह के लेबल के लिए बेहतर अनुकूल होगी, हालांकि Needs: * संकेत देगा।

BTW, क्या यहां अंतरिम सूची को हटाना ठीक है: #5016 (टिप्पणी)?

@pglewis आगे बढ़ें और जो कुछ भी आप चाहते हैं उसे हटा दें (या ऐतिहासिक संदर्भ के लिए <details>...</details> में छुपाएं)।

support.pods.io और docs.pods.io यहां बिल्कुल नहीं होने चाहिए

मौजूदा "डॉक्स इम्प्रूव" टैग (बनाम डॉक्स: इनलाइन) के बारे में अनिश्चितता के कारण मैं उन्हें जोड़ रहा था - अगर उन्हें कहीं और संभाला जाता है तो उन्हें हटाया जा सकता है।

डॉक्स इम्प्रूवमेंट को 'डॉक्स: इनलाइन' 'डॉक्स: उदाहरण' 'डॉक्स: टूलटिप्स' और उस तरह की चीजों के रूप में बेहतर तरीके से लिखा जा सकता है। जब तक हम GitHub में दस्तावेज़ीकरण (अर्थात docs.pods.io वेबसाइट में लिखित दस्तावेज़) वर्कफ़्लो को हैंडल नहीं कर रहे हैं, यहाँ इसका कोई कारण नहीं है। हमारे कोड के अंदर किसी भी डॉक्स सुधार का अर्थ है डॉक्स _in_ हमारा कोड या हमारे कोड के भीतर प्रबंधित या रीडमी की तरह जो पार्स किया जाता है और WordPress.org प्लगइन रेपो तक धकेल दिया जाता है।

मुझे Status: Is Blocked क्योंकि यह बहुत जानकारीपूर्ण है, लेकिन यदि आप उस प्रकृति का कुछ करते हैं, तो इसके लिए आवश्यकताएँ:* भी आवश्यक हैं

जैसा मैंने कहा, सब कुछ एक Type और एक Status । जब तक हम गिटहब के साथ पूर्ण चंचल परियोजना प्रबंधन नहीं कर रहे हैं, प्राथमिकताओं को वहां परिभाषित करने की आवश्यकता नहीं है और वास्तव में 'कहानी' को पूरा करने के लिए आवश्यक कार्य की इकाइयों द्वारा बेहतर प्रतिनिधित्व किया जाता है। हमने हमेशा 100 मुद्दों में वस्तुओं को अलग करने के लिए फोकस का उपयोग किया है जिन्हें अगले रखरखाव रिलीज में ध्यान केंद्रित करने की आवश्यकता है।

मेरे विचार केवल UI/CSS लेबल के संबंध में हैं, क्योंकि वे ही हैं जिनसे मैं सबसे अधिक निपटता हूं... सुनिश्चित नहीं है कि आप लोगों के पास वहां कोई विचार है, लेकिन सीएसएस परिणाम है, न कि मूर्त चीज जिसे ठीक करने की आवश्यकता है ... अगर यह समझ में आता है। यूआई पर काम करने या सुधारने के लिए मूर्त चीज होगी, सीएसएस परिणाम होगा या यह कैसे तय होगा। वरना मुझे अच्छा लगता है

मेरे विचार केवल UI/CSS लेबल के संबंध में हैं, क्योंकि वे ही हैं जिनसे मैं सबसे अधिक निपटता हूं... सुनिश्चित नहीं है कि आप लोगों के पास वहां कोई विचार है, लेकिन सीएसएस परिणाम है, न कि मूर्त चीज जिसे ठीक करने की आवश्यकता है ... अगर यह समझ में आता है। यूआई पर काम करने या सुधारने के लिए मूर्त चीज होगी, सीएसएस परिणाम होगा या यह कैसे तय होगा।

हाँ, वहाँ शोधन किया जाना है। मैंने आपके और/या जॉरी को फ़िल्टर करने के लिए बैट-सिग्नल के रूप में ज्यादातर सीएसएस लेबल का उपयोग किया है क्योंकि आप उस दिशा में जाने-माने लोग रहे हैं।

मैं अभी के लिए प्रस्तावित सीएसएस और यूआई को छोड़ने के लिए वोट दूंगा लेकिन हम निश्चित रूप से चरण I के बाद इसे परिष्कृत करना जारी रख सकते हैं।

आरई: टेस्ट की जरूरत है

अधिक कोड कवरेज चाहने के लिए (हालाँकि मैंने अभी तक व्यक्तिगत रूप से इस क्षेत्र पर अधिक ध्यान नहीं दिया है), यह लेबल यह कहने के लिए हो सकता है कि "फिक्स अच्छा है, लेकिन हम देखना चाहते हैं कि यूनिट परीक्षण किनारों को कवर करते हैं/सत्यापित करते हैं विशिष्ट बग फिक्स इसलिए कोई प्रतिगमन पेश नहीं किया गया है"।

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

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

मुझे स्थिति पसंद है: अवरुद्ध है क्योंकि यह बहुत जानकारीपूर्ण है, लेकिन यदि आप उस प्रकृति का कुछ करते हैं, तो इसके लिए आवश्यकताएँ:* भी आवश्यक हैं

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

और अगर यह कुछ भी स्पष्ट करने में मदद करता है, तो यह सामान्य वर्कफ़्लो है जिसका उपयोग मैं औसत बग पर करता हूं:

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

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

मुझे लगता है कि होल्ड लेबल ऐतिहासिक रूप से उन मामलों में समीक्षा के लिए खींचे जाने से बेहतर रहा है।

FYI करें, अतीत में, मैंने किसी रिलीज़ को ब्लॉक करने वाली समस्या को इंगित करने के लिए Blocker का उपयोग किया है।

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

क्या मूल समस्या विवरण की सूची उन परिवर्तनों के साथ अप-टू-डेट है, जिन पर हम सभी चर्चा कर चुके हैं?

क्या मूल समस्या विवरण की सूची उन परिवर्तनों के साथ अप-टू-डेट है, जिन पर हम सभी चर्चा कर चुके हैं?

शायद पूरी तरह से नहीं, अगर आप चाहें तो कुछ को परिष्कृत करने के लिए स्वतंत्र महसूस करें। एक बार जब हमारे पास पूरी तरह से थम्स-अप और कंघी हो जाती है, तो हमने जो कुछ भी तय किया है, उसे अपडेट नहीं किया गया है।

हम यहां जो कुछ भी तय करते हैं, हमें उन्हें सिंक करने के लिए https://github.com/dwyl/labels जैसे टूल का उपयोग करके अपने सभी अन्य पॉड्स रेपो पर लागू करने की आवश्यकता है।

"रिग्रेशन" को टाइप से कीवर्ड में ले जाना। बग अभी भी प्रतिगमन मुद्दों का प्रकार है।

यह अब काफी हद तक लागू है। कुछ विविध चीजें जो मैं अभी के लिए "कीवर्ड" के अंतर्गत अटका हुआ हूं।

इस बिंदु पर काम करने के लिए रंग मुख्य चीज हैं।

?बंद: अमान्य

मैं कम से कम इसे रखने का सुझाव दूंगा, संभवतः यह भी ठीक नहीं होगा। वे अन्य बग ट्रैकर्स पर काफी मानक संकल्प हैं।

इस बिंदु पर काम करने के लिए रंग मुख्य चीज हैं।

इस बिंदु पर रंग गौण हैं - लेबल लागू करवाएं, और बाद में रंग योजना पर निर्णय लें।

मैं कम से कम इसे [अमान्य] रखने का सुझाव दूंगा, संभवतः यह भी ठीक नहीं होगा। वे अन्य बग ट्रैकर्स पर काफी मानक संकल्प हैं।

मैं अमान्य जोड़ दूंगा, मैंने इसे अभी एक अनुस्मारक के रूप में चिह्नित किया है क्योंकि हमारे पास यह पहले से नहीं था।

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

इस बिंदु पर रंग गौण हैं - लेबल लागू करवाएं, और बाद में रंग योजना पर निर्णय लें।

लेबल बहुत अधिक लागू किए गए हैं।

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

Type: Project ?

क्या होगा यदि "ठीक नहीं होगा" के बजाय हमने "जैसा है वैसा छोड़ो" या ऐसा कुछ इस्तेमाल किया?

क्या होगा यदि "ठीक नहीं होगा" के बजाय हमने "जैसा है वैसा छोड़ो" या ऐसा कुछ इस्तेमाल किया?

यह एक असामान्य स्थिति है इसलिए हमने इसे इतना लंबा कर दिया है बिना किसी ऐसी चीज की आवश्यकता के। मैं वहां कुछ भी जोड़ने की प्रतीक्षा करने के लिए वोट देता हूं जब तक कि कोई विशिष्ट उदाहरण सामने न आए।

साथ ही, मैंने कुछ समूहों के लिए कुछ मनमाना रंग निर्णय लिए हैं। वहां पत्थर में कुछ भी सेट नहीं है।

मुझे लगता है कि हम शायद इस बिंदु पर इस मुद्दे को बंद कर सकते हैं और स्लैक के माध्यम से किसी और परिशोधन पर चर्चा कर सकते हैं।

What if instead of "Won't Fix" we used "Leave as is" or something like that?

यह एक असामान्य स्थिति है इसलिए हमने इसे इतना लंबा कर दिया है बिना किसी ऐसी चीज की आवश्यकता के। मैं वहां कुछ भी जोड़ने की प्रतीक्षा करने के लिए वोट देता हूं जब तक कि कोई विशिष्ट उदाहरण सामने न आए।

मैं सहमत हूं। वर्डप्रेस कोर जो कुछ भी करता है उसे डुप्लिकेट करने की आवश्यकता नहीं है

मैं सहमत हूं। वर्डप्रेस कोर जो कुछ भी करता है उसे डुप्लिकेट करने की आवश्यकता नहीं है

जीएच पर एक नया रेपो स्थापित करते समय यह डिफ़ॉल्ट लेबल में से एक है - https://github.com/GaryJones/daterange/labels देखें जिसमें डिफ़ॉल्ट लेबल हैं।

I agree. Not everything that WordPress core does needs to be duplicated

जीएच पर एक नया रेपो स्थापित करते समय यह डिफ़ॉल्ट लेबल में से एक है - https://github.com/GaryJones/daterange/labels देखें जिसमें डिफ़ॉल्ट लेबल हैं।

मुझे याद नहीं है कि यह कब GitHub के लिए एक डिफ़ॉल्ट बन गया, लेकिन एक स्वयंसेवक योगदानकर्ता के टिकट को संलग्न करना हमेशा एक भयानक टैग रहा है। मैंने उस टैग के साथ GitHub पर बहुत कम मुद्दों को देखा है, लेकिन वर्डप्रेस की दुनिया में अधिकांश अभ्यस्त-फिक्स टिकट किसी अन्य मुद्दे से आच्छादित हैं, एक फिक्स को सही ठहराने के लिए अधिक जानकारी की आवश्यकता है, या सिर्फ यह उम्मीद करना कि कोई भी शिकायत करने के लिए वापस नहीं आएगा (अक्सर मामला) .

मैं अपनी नापसंदगी पर कायम रहूंगा। "ठीक नहीं होगा" पर मेरा तत्काल प्रश्न है "हम कुछ ठीक करने से इनकार क्यों करेंगे?" और अगर कोई मुझे टिकट पर इसका एक अच्छा संक्षिप्त उत्तर देता है तो मैं कहूंगा _that_ वह है जो लेबल को 'ठीक नहीं होगा' के बजाय पढ़ना चाहिए।

मुझे लगता है कि Out of Scope वैसे भी एक बेहतर जवाब है। विल फिक्स जस्ट का तात्पर्य है और समस्या को खोलने वाले व्यक्ति को 'कुछ नहीं' प्रदान करता है।

शायद यह दिशा में जा सकता है - "समाधान" जमा करने के लिए स्वतंत्र महसूस करें लेकिन टीम के पास ऐसा करने के लिए पर्याप्त संसाधन नहीं हैं: डी शायद किसी के पास इसके लिए संक्षिप्त संक्षेप का विचार है ^^

एक उपयोग का मामला कुछ फीचर में बग या सीएस उल्लंघन हो सकता है, जो कि थोक को फिर से लिखा और अगले संस्करण में जारी किया जा रहा है।

हालांकि इसे छोड़ने के लिए स्वतंत्र महसूस करें।