उपयोगकर्ता सीधे 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 में बदलने के मानदंड स्पष्ट किए गए हैं

[GN⁺]

Hacker News की राय

• 100% सहमत। अगर यह किसी और का प्रोजेक्ट है, तो issue क्या माना जाए इसका अधिकार पूरी तरह उसी व्यक्ति का है
  प्रोजेक्ट जितना बड़ा होता है, उतने ही ज़्यादा ऐसे लोग मिलते हैं जो message नहीं पढ़ते, अजीब requests करते हैं, यहाँ तक कि AI से CVE को बढ़ा-चढ़ाकर पेश करने के मामले भी आते हैं

  • जो लोग error message तक नहीं पढ़ते, उन्हें मैं सच में समझ नहीं पाता
    user को error का मतलब न पता हो, तब भी कम-से-कम कौन-सा error आया था यह बताना चाहिए
    पहले testing के दौरान मैंने साफ़ तौर पर “broken pipe error” लिखा था, लेकिन engineer ने “reproduce नहीं हो रहा” कहकर बंद कर दिया, और फिर उसी error को वजह बताकर कहा कि reproduce नहीं हो रहा
  • Github Issues में bug tracker के रूप में सीमाएँ हैं
    ज़्यादातर trackers में “unconfirmed” जैसी status classification हो सकती है, लेकिन Github सिर्फ़ एक discussion system है, इसलिए manage करना मुश्किल है
  • ChatGPT लॉन्च होने के तुरंत बाद मुझे एक CVE report मिली थी
    मैंने 4 घंटे तक code और evidence देकर उसका खंडन किया, लेकिन जवाब में बस “shrugs AI” मिला
  • बहुत-से users बिना tools का सही इस्तेमाल सीखने का समय लगाए सिर्फ़ result चाहते हैं
    “Facebookization” ने यह धारणा बना दी कि कुछ clicks में सब हो जाता है, और अब “LLMization” से यह और बढ़ेगा ऐसा लगता है
    professional software के लिए यह approach सही नहीं है, लेकिन expectations अब वैसी ही बन चुकी हैं
  • एक अच्छा issue tracker ऐसा होना चाहिए जिसमें इस तरह के noise को फ़िल्टर करने की क्षमता हो
    Ghostty का discussions के ज़रिए requests को classify करना एक अनोखा लेकिन असरदार approach है

• memory leak की जाँच कई platforms पर बिखरी हुई है
  X लिंक1, X लिंक2, चर्चा1, चर्चा2
  इसे अभी तक official issue में promote नहीं किया गया है

  • memory leak की वजह से मैंने Ghostty इस्तेमाल करना छोड़ दिया
    8GB system पर भी terminal कुछ ही बार चलाने से memory shortage हो जाती थी
    Foot में features कम थे, लेकिन वह काफ़ी ज़्यादा stable था
  • पहले लिंक के अनुसार लेखक कहता है कि यह समस्या सिर्फ़ दो बार report हुई है
    दूसरा लिंक सिर्फ़ बहस शुरू करने की कोशिश जैसा लगता है
  • मैंने भी यह समस्या चर्चा में report की थी, लेकिन कोई प्रतिक्रिया नहीं मिली
    Claude Code और logs का analysis करके मैंने अस्थायी रूप से fix किया, और अब यह 10 में 1 बार ही reproduce होता है
    उम्मीद है कि कोई आगे जाँच करे तो यह मददगार होगा
  • GPU compatibility भी मुश्किल है
    integrated GPU पर भी समस्या आती है, लेकिन हर बार blame GTK या Nvidia पर डाल दिया जाता है
  • लगता है contributors ने माना कि इसे issue बनाने लायक स्पष्ट reproduction conditions अभी नहीं हैं

• मुझे “Issues” और “Discussions” का विभाजन अकुशल लगता है
  duplicate search करनी पड़ती है, और tickets को move भी नहीं किया जा सकता
  email से follow-up करो तो notifications टूट जाते हैं
  इसलिए मैंने अपने प्रोजेक्ट में Discussions बंद कर दिए

  • Discussions साधारण सवालों या installation problems के लिए उपयोगी जगह है
    अगर सच में bug हो, तब उसे issue में बदल सकते हैं
  • यह process label system से भी लागू किया जा सकता है
    admin अगर “bug” label लगा दे तो काफ़ी है
  • duplicate check की ज़रूरत नहीं है
    discussion साफ़ हो जाए, तब issue बनाया जा सकता है
  • असल में issue और discussion एक-दूसरे में बदले जा सकते हैं
    notifications भी बनी रहती हैं
  • Ghostty की संरचना की तरह, Discussions कोई भी खोल सके और Issues को admin manage करे — यह तर्कसंगत विभाजन लगता है

• Python community के कुछ बड़े projects भी यही तरीका अपनाते हैं
  लेकिन power users के नज़रिए से bug report process झंझटभरा है
  “हमारा project परफेक्ट है” जैसा रवैया अहंकारी लगता है

  • ऐसी शिकायत समझना मुश्किल है
    ज़्यादातर drive-by bug reports बेकार होती हैं, बल्कि noise बढ़ाती हैं
    अगर सच में योगदान देना है, तो पहले से defined bugs को fix करना बेहतर है
  • अहंकारी? उल्टा वे लोग मुफ़्त में अपना समय और मेहनत लगा रहे हैं
    report करने के तरीक़े पर सीमाएँ रखना स्वाभाविक है
  • अगर आप इतनी बार bugs ढूँढ़ते हैं, तो project में सीधे शामिल होने पर भी विचार कर सकते हैं
  • उल्टा, ख़ुद यह मान लेना कि “यह तो साफ़ bug है” भी एक तरह का अहंकार हो सकता है
  • discussion खोलना, issue खोलने से ज़्यादा झंझटभरा है? मुझे नहीं लगता

• “हर issue काम शुरू करने के लिए पूरी तरह तैयार होना चाहिए” इस दावे पर,
  सवाल उठा कि “तो फिर ‘ready-to-be-worked-on’ tag लगा दें, वही काफ़ी नहीं?”

  • लेकिन Github में default view को “triage” पर सेट नहीं किया जा सकता, और बड़े projects में issue management अकुशल हो जाता है
    यह system काफ़ी ज़्यादा सफल रहा
  • tag वाला तरीका कई feedback rounds माँगता है, इसलिए details comments में बिखर जाती हैं
  • अगर किसी को भी comments करने दो, तो अनावश्यक शोर पैदा होता है
    इसलिए developers के लिए अलग space और users के लिए अलग space बनाया गया
  • ग़लत issues को बंद कर दो, तब भी वे फिर से खुल सकते हैं, और आख़िर में issue list संभालना मुश्किल हो जाता है
  • किसी और के workflow पर “मेरा तरीका बेहतर है” थोपने की ज़रूरत नहीं है

• Issues scale बढ़ने पर manage नहीं हो पाते
  Discussions को filter की तरह इस्तेमाल करना असरदार है

  • लेकिन आख़िर में maintainers को हर post पढ़कर classify करना ही पड़ता है, इसलिए काम का बोझ लगभग वही रहता है
    Github के ये दोनों features लगभग एक जैसे UI वाले हैं
    बस Discussions में upvote feature है
  • “क्यों न सभी issues को 2 हफ़्ते बाद अपने-आप बंद कर दिया जाए, क्या वह ज़्यादा efficient नहीं होगा?” जैसी व्यंग्यात्मक प्रतिक्रिया भी थी
  • Curl जैसे बड़े project में भी सिर्फ़ 5 open issues हैं
    curl/curl/issues

• कुछ लोगों का मानना है कि यही default setting होनी चाहिए
  community discussions संभाले और contributors issues — ऐसी संरचना आदर्श है

  • लेकिन यह बस process की पुनर्व्यवस्था है, मूल बात वही रहती है
    GitHub का label system भी इसे ठीक से संभाल सकता है
    GitHub label management दस्तावेज़
  • “default” तय करने से बेहतर है कि हर project स्वाभाविक प्रयोग के ज़रिए अपने लिए सही तरीका खोजे
    जैसे Natural experiment

• user submission policy से मैं सहमत हूँ
  बंद discussions को देखें तो वे बंद issues जैसे ही लगते हैं, लेकिन कम-से-कम issue tab का noise घटता है
  Ghostty बंद discussions की सूची

  • हर user report discussion से शुरू होती है, और अगर वह असली bug साबित हो जाए तो उसे issue में ले जाया जाता है
    बहुत-सी discussions उस चरण तक नहीं पहुँचतीं, फिर भी user की समस्या हल हो जाती है
    मुझे यह अलगाव वाली संरचना काफ़ी स्मार्ट डिज़ाइन लगती है

• असल में “issue नहीं खोला जा सकता” कोई GitHub feature नहीं है,
  बल्कि यह सिर्फ़ template में लिखा guidance है: “नई issue न खोलें, Discussions का उपयोग करें”

• मैंने दूसरे projects में भी यह तरीका देखा है,
  discussion को शुरुआती बिंदु बनाने वाली संरचना काफ़ी तर्कसंगत लगती है
  लेकिन अभी भी बहुत-से projects ने GitHub Discussions सक्षम नहीं किया है

[iolothebard]

उस discussion में issue से अलग क्या है? Issue सिर्फ “bug” नहीं होता। चाहे bug हो, feature suggestion हो, या PR… अगर चर्चा करने लायक कुछ है, तो वह issue है.
अगर उस पर चर्चा करने की ज़रूरत नहीं है, तो उसे बंद किया जा सकता है।

[nemorize]

ऐसा नहीं है कि discussion और issue में कोई बुनियादी फर्क है, बल्कि शायद अलग टैब में बाँटना उनकी पसंद के हिसाब से ज़्यादा सही लगा होगा.

Issue टैब में एक तरह की todo list और discussion दोनों पोस्ट करके उन्हें tag से मैनेज करना
vs
Issue टैब को सिर्फ todo list के लिए, और discussion को सिर्फ discussion के लिए इस्तेमाल करना