No star, No fix

एक GitHub project जो उन users के issues स्वतः बंद कर देता है जिन्होंने repo को star नहीं किया है, ethics, practicality, और platform policy पर बहस छेड़ रहा है। आलोचकों का तर्क है कि bug reports और feature requests को “internet points” पर निर्भर बनाना stars के अर्थ को भ्रष्ट करता है, मूल्यवान reports को हतोत्साहित करता है (security issues सहित), और संभवतः inauthentic activity पर GitHub के नियमों का उल्लंघन करता है। समर्थकों का कहना है कि maintainers बिना भुगतान के हैं, अत्यधिक बोझ में हैं, और सार्वजनिक popularity signals को skew करने के बावजूद भी, समर्थन के छोटे इशारों या friction जोड़ने का अधिकार रखते हैं.

नीति और नियम अनुपालन

  • कुछ लोग तर्क देते हैं कि “स्टार-गेटेड” बॉट (रिपोर्टर के रेपो को स्टार करने तक issues बंद करना) संभवतः GitHub के स्वचालित starring / “coordinated inauthentic activity” संबंधी नियमों का उल्लंघन करता है।
  • अन्य लोग इसका प्रतिवाद करते हैं कि यह नियमों के स्पष्ट रूप से खिलाफ नहीं है क्योंकि: यह उपयोगकर्ता-प्रेरित है, स्पष्ट सहमति की आवश्यकता होती है, यह स्वतः starring नहीं है, और repo मालिकों पर सहायता प्रदान करने की कोई बाध्यता नहीं है।
  • कुछ लोग नोट करते हैं कि, मौजूदा नियमों से परे, ऐसे तरीकों को अस्वीकृत किया जाना चाहिए क्योंकि वे प्लेटफ़ॉर्म संकेतों को विकृत करते हैं।

Stars का अर्थ और अखंडता

  • कई लोग stars को निजी bookmarks या वास्तविक समर्थन मानते हैं; issue handling को stars पर निर्भर बनाना उस संकेत को भ्रष्ट करना माना जाता है।
  • आलोचक कहते हैं कि इससे star counts झुंझलाहट या आवश्यकता के आधार पर बढ़ते हैं (जैसे, dependencies टूटने पर), न कि प्रशंसा या लोकप्रियता के आधार पर।
  • समर्थकों का कहना है कि bug reporters पहले से ही “रुचि रखने वाले उपयोगकर्ता” हैं, इसलिए star की शर्त वास्तव में stars को वास्तविक उपयोग के अधिक निकट लाती है।

नैतिकता, शक्ति-संतुलन, और “extortion” की व्याख्या

  • कई टिप्पणीकार इस प्रथा को घटिया, petty, या “extortion-like” कहते हैं: “मैं आपके issue पर तब तक विचार भी नहीं करूँगा जब तक आप सार्वजनिक रूप से मुझे पसंद नहीं करते।”
  • चिंताओं में शामिल हैं: भावनात्मक हेरफेर, परियोजना का मूल्यांकन करने वाले संगठनों के लिए प्रतिष्ठात्मक लाल झंडे, और मूल्यवान drive-by reports (संभावित security issues सहित) को हतोत्साहित करना।
  • अन्य लोग तर्क देते हैं कि maintainers मुफ़्त श्रम के लिए मनमानी सीमाएँ तय कर सकते हैं, और एक star माँगना ध्यान के लिए न्यूनतम भुगतान है।

Maintainer पर बोझ और शोर में कमी

  • बचाव करने वाले maintainer overload पर ज़ोर देते हैं: issue queues भर जाती हैं, और हल्का friction (जैसे star) कम-प्रयास वाले reports को छाँट सकता है।
  • आलोचक जवाब देते हैं कि यह अच्छे और खराब reports में अंतर नहीं करता और code योगदान करने के उच्च-गुणवत्ता वाले प्रस्तावों को भी रोकता है।

व्यावहारिक परिणाम और सीमांत मामले

  • टिप्पणीकार ऐसे उपयोग-केस उजागर करते हैं जहाँ लोग “like” किए बिना issues दर्ज करते हैं: automated tools, security research, transitive dependencies, या कई विकल्पों का मूल्यांकन।
  • कुछ लोग अपना issue संभाले जाने तक थोड़ी देर के लिए star करेंगे, फिर unstar कर देंगे; अन्य लोग सिद्धांत के आधार पर मना करते हैं, और donations या bounties को प्राथमिकता देते हैं।
  • कई लोग नोट करते हैं कि यदि यह प्रथा फैलती है, तो यह एक “star inflation war” शुरू कर देती है, जिससे stars बाज़ारों पर manipulated reviews की तरह कमज़ोर हो जाते हैं।