उपयोगकर्ता सीधे Issue क्यों नहीं बना सकते

• Ghostty repository में उपयोगकर्ता सीधे Issue नहीं बना सकते, और पहले GitHub Discussions में चर्चा शुरू करनी होती है
• प्रोजेक्ट bug या feature request पर चर्चा के लिए Issue tracker का उपयोग नहीं करता, और सभी चर्चाएँ Discussions में होती हैं
• जब चर्चा पर्याप्त रूप से स्पष्ट होकर कार्रवाई योग्य आइटम में व्यवस्थित हो जाती है, तब maintainer उसे Issue में बदलता है
• यह तरीका maintainer और contributor को वास्तव में काम किए जा सकने वाले issues जल्दी खोजने में मदद करने वाली संरचना है
• अधिकांश रिपोर्टें उपयोगकर्ता environment की समस्या, गलतफहमी, या अभी तक implement न हुई feature request होती हैं, इसलिए यह प्रक्रिया प्रोजेक्ट की quality management के लिए महत्वपूर्ण है

---

Issue निर्माण प्रतिबंध नीति

• Ghostty repository में उपयोगकर्ता सीधे Issue नहीं बना सकते
  • इसके बजाय पहले GitHub Discussions में समस्या या सुझाव साझा करना होता है
  • maintainer चर्चा की समीक्षा करके यदि उसे स्पष्ट रूप से reproduce की जा सकने वाली समस्या मानता है, तो उसे Issue में बदल देता है
• यह तरीका Issue tracker में केवल वास्तव में काम किए जा सकने वाले आइटम बनाए रखने के लिए है
  • क्योंकि सभी Issues पहले से ही ठोस रूप ले चुके होते हैं, contributors तुरंत काम शुरू कर सकते हैं

Issue tracker संचालन सिद्धांत

• Ghostty Issue tracker का उपयोग चर्चा या feature request के लिए नहीं करता
  • feature request या सामान्य प्रश्न Discussions में संभाले जाते हैं
  • Issue में केवल स्पष्ट रूप से परिभाषित bug या कार्रवाई योग्य कार्य आइटम शामिल होते हैं
• यह दृष्टिकोण open source project maintenance के अनुभव के आधार पर बना संचालन सिद्धांत है
  • पिछले अनुभव के अनुसार, उपयोगकर्ता रिपोर्टों में 80~90% वास्तविक bug नहीं बल्कि गलतफहमी या environment समस्या थीं
  • बाकी अधिकांश अभी implement न हुई feature requests थीं, जिनके लिए अक्सर अतिरिक्त specification की ज़रूरत होती थी

maintenance दक्षता में सुधार

• Discussions चरण से गुजरने पर maintainer केवल सत्यापित समस्याओं को ही Issue के रूप में प्रबंधित कर सकता है
  • अनावश्यक duplicate reports या गलत bug reports कम हो जाती हैं
  • Issue सूची तुरंत काम किए जा सकने वाले आइटमों के आधार पर व्यवस्थित रहती है
• उपयोगकर्ता वैध समस्या मिलने पर भी कोई अतिरिक्त काम करने की आवश्यकता नहीं होती
  • maintainer स्वयं उसे Issue में बदलकर संभाल लेता है

संदर्भ दस्तावेज़

• विस्तृत प्रक्रिया और contribution guidelines CONTRIBUTING.md फ़ाइल में देखी जा सकती हैं
• उस दस्तावेज़ में Discussions में भाग लेने का तरीका और Issue में बदलने के मानदंड स्पष्ट किए गए हैं