1 पॉइंट द्वारा GN⁺ 2023-07-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub Profile Achievements फीचर बनाते समय अस्वीकार की गई उपलब्धियों को इकट्ठा करके सूचीबद्ध करने वाला कलेक्शन
  • हर आइटम एक सूची के रूप में है, जिसमें उपलब्धि का शीर्षक, badge prototype, और उसे पाने की शर्तें शामिल हैं
  • उदाहरण के तौर पर ऐसी उपलब्धियाँ हैं: केवल +1 या thumbs-up इमोजी वाले issue comments 100 से अधिक करना, public repository में गलती से secret API key commit कर देना, या main branch में सीधे commit करके build process तोड़ देना
  • अन्य उदाहरणों में शामिल हैं: अपने public repository में 1,000 से अधिक open issues होना, merge हो चुकी लेकिन delete न की गई 150 से अधिक branches बनाए रखना, या 10,000 लाइनों से बड़े pull request को 15 सेकंड के भीतर review करके approve करना
  • यह स्पष्ट रूप से “This is a joke” लिखा हुआ एक मज़ाकिया प्रोजेक्ट है, और इसमें PR स्वीकार किए जाते हैं
  • इसमें लिखा है कि इसे Schweinepriester/github-profile-achievements से प्रेरणा मिली, और badges OpenMoji की art पर आधारित बनाए गए हैं

1 टिप्पणियां

 
GN⁺ 2023-07-06
Hacker News राय
  • सुझाव: “The Artist” उस व्यक्ति के लिए जो टेक्स्ट को copy-paste करने के बजाय terminal screenshot अपलोड करता है, और “The Filmmaker” उस व्यक्ति के लिए जो क्या किया उसे लिखने के बजाय terminal session GIF अपलोड करता है
    maintainers सच में कलाकारों और फिल्मकारों से बहुत प्यार करते हैं!

    • “The Novelist”: वह व्यक्ति जो issue या thread में क्या try किया, क्यों लगा कि यह काम नहीं करेगा, error message क्या था—कुछ भी बताए बिना सिर्फ “doesn't work” छोड़ देता है
      “Captain Obvious”: वह व्यक्ति जो project install न होने पर बहुत आक्रामक issue खोलता है, और जब maintainer जवाब देता है कि क्या आपने docs में साफ़ लिखे गए महत्वपूर्ण निर्देश मिस तो नहीं किए, तो वह गायब हो जाता है और फिर कभी जवाब नहीं देता
    • debugging के समय वीडियो और GIF वास्तव में बहुत अच्छे होते हैं
      कई बार वे इंसान की व्याख्या से कहीं बेहतर छोटे-छोटे details पकड़ लेते हैं। bug किसी ऐसी action पर निर्भर हो सकता है जिसे कई तरीकों से किया जा सकता है, या user को यह पता ही न हो कि bug trigger होने से ठीक पहले उसने जो किया वही समस्या का हिस्सा है। यह सिर्फ किसी खास screen size, terminal color, या touchscreen के इस्तेमाल जैसी शर्तों में भी हो सकता है
      वीडियो होने पर ऐसी चीज़ें नोटिस करना बहुत आसान हो जाता है। यह परफेक्ट नहीं है, और वीडियो के साथ विस्तृत विवरण हो तो सबसे अच्छा है, साथ में error या महत्वपूर्ण text copy करने लायक रूप में भी चिपका दिया जाए तो और बेहतर। फिर भी, अगर दोनों में से एक चुनना हो तो मैं अक्सर text से ज़्यादा वीडियो को पसंद करता हूँ
      इसलिए इस संदर्भ में मुझे सचमुच “Filmmaker” पसंद है। screenshot भी भेजिए, और वीडियो भी भेजिए
    • “Wikipedian”: main पर push होने के 10 मिनट के भीतर commit revert कर देता है
      “Social distancer”: सिर्फ spaces जोड़ने वाला commit submit करता है
      “Edgycat”: इस repository के लिए badge contribute या suggest करता है। मैं अभी यही badge हासिल कर रहा हूँ
      “Duct tape”: fix tests टेक्स्ट वाला commit लगातार तीन बार भेजता है
    • terminal text को copy-paste करने के बजाय screenshot के रूप में भेजना कृपया बिल्कुल नहीं
      अजीब तरह से, technical roles वाले लोगों से भी text screenshots अक्सर मिलते हैं। log files, error messages, सब कुछ image में भेज देते हैं। लगता है जैसे वे समझते हों कि Slack सिर्फ images और emojis भेजने का tool है
      मैं Java exception के 3 पेजों में से keywords खुद टाइप करने वाला नहीं हूँ, और न ही encoded AWS auth message हाथ से उतारकर लिखने वाला हूँ
    • “not helping”: बिल्कुल भी मदद न करने वाला low-effort comment छोड़ता है
      “Internet famous”: repository में इतना गंभीर bug होता है कि उस पर article तक लिख दिया जाता है
      दोनों मुझे https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue... को याद करके सूझे
  • “Unpopular opinion”: issue पर किया गया एक comment 100 से ज़्यादा downvotes पाता है
    “I will raise with the team”: 100 से ज़्यादा upvotes वाला issue या pull request 1 साल से अधिक समय तक खुला रहता है
    “For legal reasons”: issue fix करने वाला pull request आता है, लेकिन CYA पर sign न करने के कारण अपने-आप बंद हो जाता है
    “Business Model Blues”: LICENSE file के text का 50% से ज़्यादा बदल जाता है
    “Back from the dead”: 1 साल से अधिक पहले खोले गए issue या pull request पर comment करता है

  • अगर किसी public repository में 1,000 से ज़्यादा open issues हों, तो “This is fine” badge की सच में ज़रूरत है
    10 साल पहले की तुलना में open source projects बहुत ज़्यादा हो गए हैं, और खासकर JavaScript तरफ़ तो ऐसे projects भरे पड़े हैं जिनमें हैरान कर देने वाली संख्या में खुले bugs हैं
    समस्या यह है कि इन bugs में से अधिकतर की quality कम लगती है। इसलिए अगर contribution experience वाला कोई skilled developer मदद करने के लिए bug खोलता भी है, तो उसके अनदेखा हो जाने की संभावना रहती है
    मैं अभी next.js में उस bug के fix का इंतज़ार कर रहा हूँ जहाँ 404, 404 return नहीं करता, और वह महीनों से खुला है(https://github.com/vercel/next.js/issues/51021)। मेरे पास pull request लिखने का समय नहीं है, लेकिन मैंने इतने सालों में अनगिनत pull requests और bug reports लिखी हैं और कई open source projects में हिस्सा लिया है, इसलिए मुझे लगता है मैंने अपना हिस्सा कर दिया है
    यह elitist लग सकता है, लेकिन अच्छा होता अगर maintainers के पास bugs को reporter की reputation के आधार पर sort करने का कोई तरीका होता। तब projects high-quality issues को प्राथमिकता दे सकते थे

    • काश लोगों के पास value exchange करने का कोई तरीका होता। जैसे paid license, support tiers, और वे चीज़ें जिन्हें प्राचीन रोमन “business चलाना” कहते थे। /s
      लेकिन नहीं, सब कुछ free होना चाहिए, और फिर हैरानी की बात है कि open issues जमा होते जाते हैं और कोई उन्हें handle नहीं करना चाहता
    • इसका मतलब “public repositories में मेरे बनाए 1,000 open issues” नहीं, बल्कि मेरे स्वामित्व वाले public repositories के 1,000 open issues है
      दोनों ही दिलचस्प हैं
  • “The thief”: open source के साथ ऐसा व्यवहार करना कि pull request बंद कर दिया जाए और उसके अंतर को अपने नाम से manually merge कर लिया जाए
    बड़ी कंपनियों द्वारा चलाए जाने वाले projects में यह काफ़ी होता है, और शायद compliance कारणों से होता हो, लेकिन ऊपर से देखने पर काफ़ी संदिग्ध लगता है

    • यह काफ़ी गंभीर है, क्या आप बता सकते हैं कि कौन से उल्लेखनीय projects ऐसा करते हैं?
  • अफ़सोस कि मेरा निजी पसंदीदा इसमें नहीं है। ऐसा व्यक्ति जिसने 50 से ज़्यादा feature request issues खोले हों, लेकिन उसके अलावा कोई contribution न हो

    • achievement का नाम “I'm more of an idea person” या “chop-chop” जैसा कुछ अच्छा रहेगा
    • “10 contributions किए लेकिन 1 साल से ज़्यादा समय तक बिना review के पड़े रहे” जैसा achievement कैसा रहेगा?
    • “Architecture Astronaut”
    • सामान्य users के लिए लेखक से संपर्क करने का यही एकमात्र तरीका होता है
    • “Idea guy”
  • मैंने “patient skeleton” दो बार हासिल किया है
    सच में हैरान करने वाली बात यह है कि उनमें से एक 2 साल बाद merge हुआ। उस pull request पर कोई बातचीत भी नहीं हुई थी, और project में activity कम होने के कारण वह बस नज़र से छूट गया था। मैंने उम्मीद छोड़ दी थी और requirements.txt को अपनी fork की ओर point करने दिया था
    किसी और ने उसी समस्या के लिए issue खोला जिसे मेरा पुराना pull request ठीक करता था, और जब मैंने उस issue में जवाब दिया कि वह pull request इसे solve करता है, तो उसी activity की वजह से आखिरकार वह दिख गया
    दूसरा अब भी pending है

    • mainline में merge हुए बिना, सिर्फ एक महत्वपूर्ण बदलाव रखने वाले forked projects में फँसी हुई unrecovered value आसानी से दर्जनों अरब डॉलर की हो सकती है
  • मैं “YOLO” सुझाता हूँ। अगर Dependabot alerts को 3 महीने से ज़्यादा अनदेखा किया गया हो
    मान लीजिए इस award पर मेरा नाम लिखा है

    • पहले से एक असली achievement YOLO नाम से मौजूद है। उसका मतलब है “code review के बिना अपनी pull request merge करना”
      असली achievements की पूरी सूची यहाँ है: https://github.com/Schweinepriester/github-profile-achieveme...
  • सुधार करूँ तो, ये GitHub द्वारा reject किए गए achievements नहीं हैं, बल्कि GitHub से असंबंधित developer “flet” के बनाए हुए मज़ाकिया ideas हैं

    • Captain Obvious achievement हासिल करने पर बधाई!
  • मैं सुझाव दूँगा कि अपनी ही repository को star करने पर “Copium” achievement दिया जाए

    • पक्का नहीं, लेकिन लगता है पहले GitHub repository बनाते समय अपने-आप उसे star कर देता था
    • “Narcissist” शायद ज़्यादा उपयुक्त हो
  • “Type O Contributor”: जिसकी एकमात्र contribution सिर्फ मामूली spelling और grammar fixes हों

    • यह achievement नहीं हो सकता। क्योंकि इसे revert करके छीना जा सकता है
    • मैं भी कभी-कभी ऐसा करता रहा हूँ, क्या ऐसी contributions स्वागतयोग्य नहीं हैं?
    • “Typo-O donor” अच्छा रहेगा