ओपन सोर्स में non-code योगदान

 (github.com/readme)
10 पॉइंट द्वारा GN⁺ 2024-02-15 | 6 टिप्पणियां | WhatsApp पर शेयर करें

non-code योगदान ओपन सोर्स की सफलता का राज़

  • गणित की शिक्षिका सारा रेन्सबर्गर ने स्वेच्छा से ओपन सोर्स contributor बनने की योजना नहीं बनाई थी, लेकिन अपनी choir website को फिर से बनाते समय उन्होंने JavaScript और web development सीखना शुरू किया।
  • frontend framework Astro का उपयोग करते हुए उन्होंने project में config file जैसे एक छोटे code snippet का योगदान किया, और community में भाग लेते हुए नए Astro users की मदद करने की भूमिका संभाली।
  • रेन्सबर्गर अब Astro के core maintainers group की सदस्य हैं, लेकिन codebase में बहुत गहराई से शामिल नहीं हैं; वे मुख्य रूप से documentation पर काम करती हैं और दूसरों को Astro सीखने में मदद करती हैं।

ओपन सोर्स project में महत्वपूर्ण non-code काम

  • ओपन सोर्स project में code लिखने के अलावा documentation, localization, marketing, graphic design, testing, community management, और release management जैसे काम भी ज़रूरी होते हैं।
  • non-code योगदान का महत्व बहुत बड़ा है, और project जितना अधिक complex होता है, उतनी ही अधिक documentation, tutorials, और support की ज़रूरत होती है, जो code को उपयोगी बनाते हैं।
  • graphic design, branding, और outreach project की सेहत और गंभीरता का संकेत देते हैं, जिससे दूसरे projects या companies उसे dependency के रूप में अपना सकते हैं।

non-code योगदान क्यों शुरू करना चाहिए

  • non-code योगदान उन लोगों को portfolio बनाने का अवसर देता है जो technical communication, graphic design, user experience design जैसी programming-रहित भूमिकाओं में रुचि रखते हैं।
  • programmers भी writing और communication skills को निखारने से लाभ पाते हैं, और इससे developer relations या product management जैसी भूमिकाओं में जाने में मदद मिल सकती है।
  • ओपन सोर्स projects में हर skill level के लोगों के लिए भागीदारी के अवसर होते हैं, और project की गहरी समझ के बिना अर्थपूर्ण code contribution करना कठिन होता है।

non-code contributors को ढूँढना और आभार व्यक्त करना

  • maintainers के लिए contributors ढूँढने का सबसे अच्छा तरीका है कि वे खास tasks के लिए स्पष्ट अनुरोध करें; community बनाना और "help wanted" तथा "good first issue" टैग वाले issues दर्ज करना भी मददगार होता है।
  • mentorship contributors को सफलता तक पहुँचाने के सर्वोत्तम तरीकों में से एक है, और non-code contributors की सराहना व पहचान करना मौजूदा contributors को प्रेरित करने और नए contributors को आकर्षित करने में मदद करता है।

GN⁺ की राय

  • यह महत्वपूर्ण है कि ओपन सोर्स project की सफलता के लिए सिर्फ code लिखना ही नहीं, बल्कि उससे कहीं अधिक विविध प्रकार के योगदानों की ज़रूरत होती है। यह project की sustainability और growth के लिए आवश्यक तत्व है।
  • non-code योगदान non-technical लोगों को भी ओपन सोर्स में भाग लेने का अवसर देता है, और तकनीकी क्षमताएँ विकसित करने में भी मदद कर सकता है।
  • यह लेख ओपन सोर्स community में रुचि रखने वाले लोगों को प्रेरित कर सकता है और अपनी skills का उपयोग करके community में योगदान देने के तरीके खोजने में मदद कर सकता है।

संबंधित पढ़ाई

6 टिप्पणियां

 
secret3056 2024-02-15

थोड़ी अलग बात है, लेकिन कुछ समय पहले किसी ने Express.js की README फ़ाइल पर PR करना एक ट्यूटोरियल के रूप में पोस्ट किया था, जिसके बाद सैकड़ों बेकार PR आने लगे।

Pull requests · expressjs/express
 
mdisprgm 2024-02-16

परेशानी... T_T
 
edunga1 2024-02-15

100 से ज़्यादा PR हैं, वाह।
 
sagee 2024-02-15

"barcode" से कैसे भाग लेना है, इस पर मुझे एक पल के लिए थोड़ा भ्रम हुआ था.. haha
विस्तृत documentation एक तरह से देखें तो दोधारी तलवार भी हो सकती है।
ऐसे cases भी आ सकते हैं जहाँ documentation और screenshots इतने ज़्यादा विस्तार से हो जाएँ कि developers को उन्हें update करने का भरोसा ही न रहे, और वे improvements develop करना छोड़ दें..
 
cosine20 2024-02-16

("गैर") कोड है)
 
GN⁺ 2024-02-15
Hacker News राय

  • एक छोटे लाइब्रेरी के लेखक/मेंटेनर के रूप में मैं यह पुष्टि कर सकता हूँ कि अगर बाहरी योगदान न होते, तो मैनुअल आज जितना अच्छा है उतना नहीं होता। मैनुअल प्रोजेक्ट की usability में बड़ा योगदान देता है.

    • libcurl के एक नए उपयोगकर्ता के रूप में, tutorial और API docs की मदद से मैं FTP upload को जल्दी implement कर सका और उसे एक खास use case के अनुसार ढाल सका.
    • documentation के माध्यम से मैं पुराने version में thread safety की कमी को पहचान सका और अपनी टीम को update करने की चेतावनी दे सका.
    • documentation, code और test suite जितनी ही महत्वपूर्ण है.

  • open source project के लिए इच्छाएँ:

    • बहुत सारे screenshots
    • बहुत लंबी और विस्तृत README.md
    • tutorial, reference docs, design docs, architecture diagrams
    • author के सोचने के तरीके को समझाने वाला mental model document

  • open source में documentation, assets आदि महत्वपूर्ण हैं, लेकिन non-developers को शक्ति देने से project बिगड़ भी सकता है.

    • जैसे हर release में UX को फिर से बनाना, जो stability, functionality और adoption को नुकसान पहुँचा सकता है.
    • इससे राजनीति में रुचि रखने वाले लोग आकर्षित हो सकते हैं, और ऐसे क्षेत्रों में जहाँ हर किसी को लगता है कि वह योगदान दे सकता है, 'bikeshedding' होना आसान है.

  • community बनाने के लिए Discord, Gitter, Slack जैसे chat platforms का उपयोग करना अच्छा है.

    • इससे लोग repository में सवाल पूछने से नहीं हिचकते.
    • GitHub पर सवाल पूछना या समस्या हल करने के लिए pull request बनाना अक्सर बेकार-सा महसूस होता है.
    • GitHub project creators के बीच "मैंने code public कर दिया, इसलिए उससे ज़्यादा मेरा कोई दायित्व नहीं है" वाला रवैया काफ़ी फैला हुआ है.

  • WordPress community में काम करने के अनुभव के आधार पर, मुझे लगता है कि शुरुआती documentation और Codex की मजबूत documentation ने WordPress की growth में बड़ा योगदान दिया.

    • उस समय जब Joomla, Drupal और WordPress installation base के मामले में लगभग समान थे, WordPress अपनी समृद्ध documentation की वजह से शुरू करना अधिक आसान था.

  • open source project के लिए सबसे बड़ी इच्छा यह है कि लोग उसे इस्तेमाल करें और अपने इस्तेमाल के बारे में किसी न किसी रूप में रिकॉर्ड छोड़ें.

    • project के Discord channel पर message छोड़ना, या tweet, छोटा message, screenshot, gist, public GitHub repository, YouTube या TikTok video—ये सभी project के लिए बहुत मूल्यवान योगदान हैं.

  • यह निश्चित नहीं है कि non-code contribution ही project की सफलता का राज़ है, लेकिन यह बहुत महत्वपूर्ण है—इस बात से सहमति है.

    • उदाहरण के लिए, Eclipse Foundation उपयोगकर्ताओं को याद दिलाता है कि bug report भी एक मूल्यवान contribution है.

  • open source project शुरू करने की प्रक्रिया में यह अपेक्षा होती है कि वास्तव में code लिखने वाले engineers की तुलना में software इस्तेमाल करने वाले engineers 10 गुना अधिक होंगे.

    • users को documentation बेहतर बनाने के तरीके से योगदान कर पाने में सक्षम होना चाहिए.
    • जब Hugo जैसे static site generator का उपयोग documentation (user manual) बनाने के लिए किया जाता है, तो users के पास ऐसा तरीका होना चाहिए जिससे वे GitHub issue बनाए बिना भी documentation के लिए fixes/updates submit कर सकें.

  • अगर non-technical लोग project को समझ पाते हैं और उसमें value पाते हैं, तो यह project की सफलता का एक अच्छा संकेत है.

  • जब product अनजान स्थिति से, जहाँ उसे fans इस्तेमाल कर रहे हों, अधिक users खोजने वाले चरण में जाता है, तब documentation महत्वपूर्ण हो जाती है.

    • अच्छी documentation के बिना इस चरण को पार करना मुश्किल है.
    • यह याद दिलाता है कि Neural Amp Modeller के लिए user guide लिखनी चाहिए.