एक सफल InnerSource प्रोग्राम का प्रबंधन कैसे करें

पूरा किया

यहां, हम चर्चा करते हैं कि आप किसी भी सॉफ्टवेयर डेवलपमेंट संगठन के भीतर ओपन-सोर्स पैटर्न का सर्वोत्तम आनंद लेने के लिए इनरसोर्स प्रोग्राम कैसे डिज़ाइन कर सकते हैं।

इनरसोर्स क्या है?

कोई भी ओपन-सोर्स सॉफ़्टवेयर का स्वतंत्र रूप से उपयोग, संशोधन और साझा कर सकता है। ओपन-सोर्स सॉफ़्टवेयर का उपयोग करके, कोई भी किसी भी उद्देश्य के लिए एक परियोजना को देख, संशोधित और वितरित कर सकता है, इस विचार के साथ कि कोड साझा करने से बेहतर, अधिक विश्वसनीय सॉफ़्टवेयर होता है।

इनरसोर्स सीमित दर्शकों वाली परियोजनाओं के लिए ओपन-सोर्स पैटर्न लागू करने का अभ्यास है। उदाहरण के लिए, एक कंपनी एक इनरसोर्स प्रोग्राम स्थापित कर सकती है जो एक विशिष्ट ओपन-सोर्स प्रोजेक्ट की संरचना को प्रतिबिंबित करती है, सिवाय इसके कि यह केवल उस कंपनी के कर्मचारियों के लिए सुलभ है। वास्तव में, यह आपकी कंपनी के फ़ायरवॉल के पीछे एक ओपन-सोर्स प्रोग्राम है।

इनरसोर्स लाभ

एक इनरसोर्स प्रोग्राम पारंपरिक बंद-स्रोत मॉडल प्रदान करने से परे कई लाभ प्रदान कर सकता है।

सबसे पहले, वे आंतरिक दृश्यता का समर्थन करते हैं। अन्य कंपनी परियोजनाओं के स्रोत कोड तक पहुंच डेवलपर्स को अपनी परियोजनाओं पर काम करते समय अधिक उत्पादक होने में मदद कर सकती है। वे देख सकते हैं कि विभिन्न टीमें उन समस्याओं के समान समस्याओं को कैसे हल करती हैं जिनका वे सामना कर रहे हैं, और अक्सर कोड और अन्य संपत्तियां ढूंढते हैं जिनका वे पुन: उपयोग कर सकते हैं। टीम के मुद्दों, पुल अनुरोधों और परियोजना योजनाओं तक पहुंच भी उन्हें परियोजना के वेग और दिशा को समझने के लिए बेहतर डेटा प्रदान करती है।

इसके बाद, वे घर्षण को कमहैं। मान लीजिए कि एक उपभोक्ता टीम एक अलग टीम के स्वामित्व वाली परियोजना के लिए बग फिक्स या नई सुविधा पर निर्भर है। एक इनरसोर्स प्रोग्राम में, उनके पास एक चैनल होता है जिसके माध्यम से वे उन परिवर्तनों का प्रस्ताव कर सकते हैं जिनकी उन्हें आवश्यकता होती है। और अगर उन परिवर्तनों को किसी भी कारण से विलय नहीं किया जा सकता है, तो उपभोक्ता टीम के पास अपनी जरूरतों को पूरा करने के लिए परियोजना को फोर्क करने का विकल्प होता है।

अंत में, वे प्रथाओं को मानकीकृत करने मेंहैं। विकास संगठनों के सामने एक आम चुनौती यह है कि विभिन्न टीमें अक्सर अपने संचालन के तरीकों में भिन्न हो जाती हैं। इनरसोर्स प्रोग्राम का निर्माण मानक सम्मेलनों को अपनाने का एक शानदार अवसर है जिसका उपयोग हर विकास टीम में किया जा सकता है, भले ही वे समान प्रथाओं का पालन न करें। उदाहरण के लिए, दो टीमें योगदान स्वीकार करने के लिए अलग-अलग प्रक्रियाओं को प्राथमिकता दे सकती हैं। जिस तरह से वे अपनी विभिन्न प्रक्रियाओं को संप्रेषित करते हैं, उस पर उन्हें मानकीकृत करने से किसी के लिए भी योगदान करना बहुत आसान हो जाता है।

टिप

टीमों में इनरसोर्स सहयोग का समर्थन करने के लिए GitHub चर्चा और GitHub प्रोजेक्ट्स का उपयोग करने पर विचार करें।

ये उदाहरण इनरसोर्स कार्यक्रमों द्वारा प्राप्त लाभों में से कुछ हैं। अधिक जानने के लिए, InnerSourceका परिचय देखें.

GitHub पर एक InnerSource प्रोग्राम सेट करें

रिपॉजिटरी दृश्यता और अनुमतियां सेट करें

आप दृश्यता के तीन स्तरों के साथ GitHub रिपॉजिटरी को कॉन्फ़िगर कर सकते हैं। जो उपयोगकर्ता दृश्यता आवश्यकता को पूरा नहीं करते हैं, वे आपके रिपॉजिटरी तक पहुंचने का प्रयास करते समय "नहीं मिला" पृष्ठ देखते हैं। स्तर हैं:

• सार्वजनिक रिपॉजिटरी सभी को दिखाई देती हैं। इस दृश्यता का उपयोग उन प्रोजेक्ट्स के लिए करें जो वास्तव में ओपन सोर्स हैं और आपके संगठन के अंदर और बाहर के लोगों तक पहुँच प्रदान करते हैं।
• आंतरिक रिपॉजिटरी केवल उस उद्यम के सदस्यों को दिखाई देती है जो उनके मालिक हैं।

नोट

आंतरिक रिपॉजिटरी केवल GitHub Enterprise ग्राहकों के लिए उपलब्ध हैं। InnerSource प्रोजेक्ट्स के लिए इस दृश्यता का उपयोग करें।

• निजी रिपॉजिटरी केवल मालिक और उनके द्वारा जोड़ी गई किसी भी टीम या व्यक्तियों को दिखाई देती हैं। इस दृश्यता का उपयोग उन प्रोजेक्ट्स के लिए करें जिन पर केवल विशिष्ट उपयोगकर्ताओं और समूहों की पहुँच होनी चाहिए.

एक बार जब आप रिपॉजिटरी दृश्यता स्थापित कर लेते हैं, तो आप व्यक्तिगत या टीम के आधार पर अनुमतियों को कॉन्फ़िगर कर सकते हैं। अनुमति के पाँच स्तर हैं:

• गैर-कोड योगदानकर्ताओं के लिए स्तर पढ़ें की सिफारिश की जाती है जो परियोजना को देखना या चर्चा करना चाहते हैं।
• ट्राइएज स्तर उन योगदानकर्ताओं के लिए अनुशंसित है जिन्हें सक्रिय रूप से मुद्दों को प्रबंधित करने और लेखन पहुंच के बिना अनुरोधों को खींचने की आवश्यकता होती है।
• उन योगदानकर्ताओं के लिए स्तर लिखें जो सक्रिय रूप से परियोजना पर जोर देते हैं।
• परियोजना प्रबंधकों के लिए स्तर बनाए रखने की सिफारिश की जाती है, जिन्हें संवेदनशील या विनाशकारी कार्यों तक पहुंच के बिना भंडार का प्रबंधन करने की आवश्यकता होती है।
• व्यवस्थापक स्तर की अनुशंसा उन लोगों के लिए की जाती है, जिन्हें परियोजना तक पूर्ण पहुंच की आवश्यकता होती है, जिसमें सुरक्षा प्रबंधित करने या रिपॉजिटरी को हटाने जैसी संवेदनशील और विनाशकारी कार्रवाइयाँ शामिल हैं।

स्तर द्वारारिपॉजिटरी एक्सेस अनुमतियों के बारे में अधिक जानें।

खोज योग्य रिपॉजिटरी बनाएं

जैसे-जैसे इनरसोर्स प्रोग्राम बढ़ता है, रिपॉजिटरी की संख्या में काफी वृद्धि होती है। हालांकि संगठन के लिए इन सभी संपत्तियों का उपलब्ध होना बहुत अच्छा है, लेकिन सामग्री को कुशलता से ढूंढना एक चुनौती बन सकता है। इस समस्या को सक्रिय रूप से संबोधित करने के लिए, टीमों के लिए यह विचार करना सबसे अच्छा अभ्यास है कि वे दूसरों के लिए अपने रिपॉजिटरी को ढूंढना और काम करना आसान बनाने के लिए क्या कर सकते हैं।

कुछ सर्वोत्तम प्रथाओं में शामिल हैं:

• वर्णनात्मक भंडार नाम का उपयोग करें, जैसे warehouse-api या supply-chain-web.
• एक संक्षिप्त विवरण शामिल करें। संभावित उपयोगकर्ताओं के लिए एक या दो वाक्य यह जानने के लिए पर्याप्त होना चाहिए कि क्या परियोजना उनकी आवश्यकताओं के अनुरूप हो सकती है।
• अपने रिपॉजिटरी को लाइसेंस दें ताकि ग्राहक जान सकें कि वे सॉफ़्टवेयर का उपयोग, परिवर्तन और वितरण कैसे कर सकते हैं।
• रिपॉजिटरी में एक README.md फ़ाइल शामिल करें। GitHub इस फ़ाइल का उपयोग लैंडिंग पृष्ठ के रूप में करता है जब लोग रिपॉजिटरी पर जाते हैं।

एक README फ़ाइल जोड़ें

एक README फ़ाइल आपके प्रोजेक्ट के लिए अपेक्षाओं का संचार करती है और आपको योगदान प्रबंधित करने में मदद करती है। README फ़ाइलें कर सकती हैं:

• परियोजना के उद्देश्य और दृष्टि को स्पष्ट करें ताकि संभावित उपभोक्ता समझ सकें कि क्या यह उनकी आवश्यकताओं के अनुरूप है।
• कार्रवाई में परियोजना को चित्रित करने के लिए स्क्रीनशॉट या कोड नमूने जैसे दृश्य एड्स प्रदान करें।
• समीक्षा के लिए ऐप्लिकेशन के प्रोडक्शन या डेमो वर्शन के लिंक शामिल करें.
• पूर्वापेक्षाएँ और परिनियोजन प्रक्रियाओं के लिए अपेक्षाएँ निर्धारित करें।
• उन परियोजनाओं के संदर्भ शामिल करें जिन पर आप निर्भर हैं। ये संदर्भ दूसरों के काम को बढ़ावा देने का एक अच्छा तरीका है।
• ठीक से स्वरूपित सामग्री के माध्यम से पाठकों का मार्गदर्शन करने के लिए मार्कडाउन का उपयोग करें।

यदि आप अपनी README.md फ़ाइल को अपने रिपॉजिटरी की रूट डायरेक्टरी में, या हिडन .github या docs डायरेक्टरी में रखते हैं, तो GitHub आपके README को रिपॉजिटरी विज़िटर को पहचानता है और स्वचालित रूप से सामने लाता है। यदि किसी रिपॉजिटरी में एक से अधिक README फ़ाइल हैं, तो दिखाई गई फ़ाइल को निम्न क्रम में स्थानों से चुना जाता है:

1. .github निर्देशिका
2. रिपॉजिटरी की रूट डायरेक्टरी
3. docs निर्देशिका

कुछविस्मयकारी README उदाहरण देखें।

एक बार परियोजना शुरू होने के बाद, इसे बढ़ावा देने के लिए ईमेल और अन्य नेटवर्किंग चैनलों का उपयोग करें। उपयुक्त दर्शकों तक पहुंचने से परियोजना की भागीदारी में उल्लेखनीय वृद्धि हो सकती है।

GitHub दस्तावेज़ में README फ़ाइलों के बारे में अधिक जानें।

GitHub पर प्रोजेक्ट प्रबंधित करें

जैसे-जैसे परियोजनाएं कर्षण प्राप्त करती हैं, उपयोगकर्ताओं और योगदानों की आमद को प्रबंधित करने के लिए बहुत सारे काम की आवश्यकता हो सकती है। परियोजना के आधार पर, परियोजना प्रतिभागियों की अपेक्षाओं को प्रबंधित करने के लिए एक महत्वपूर्ण मात्रा में काम की आवश्यकता हो सकती है।

इस समस्या को सक्रिय रूप से हल करने के लिए, GitHub एक रिपॉजिटरी के रूट (या CONTRIBUTING.md या /docs) में एक /.github फ़ाइल की तलाश करता है। परियोजना के लिए योगदान नीति की व्याख्या करने के लिए इस फ़ाइल का उपयोग करें। सटीक विवरण भिन्न हो सकते हैं, लेकिन संभावित योगदानकर्ताओं को यह बताना एक अच्छा विचार है कि परियोजना किन सम्मेलनों का पालन करती है। उदाहरण के लिए, जहां टीम पुल अनुरोधों की तलाश कर रही है, बग रिपोर्ट के लिए क्या विवरण अनुरोध किए जाते हैं, और इसी तरह।

यदि कोई CONTRIBUTING.md मौजूद है, तो GitHub इसका लिंक तब प्रस्तुत करता है जब उपयोगकर्ता समस्याएँ बनाते हैं या उन्हें इसका पालन करने के लिए प्रोत्साहित करने के लिए अनुरोध करते हैं।

कुछ भयानक CONTRIBUTING.md उदाहरण देखें

इसके अतिरिक्त, कोड संशोधनों की समीक्षा करने के लिए जिम्मेदार व्यक्तियों या टीमों को परिभाषित करने के लिए रिपॉजिटरी में कोडओनर्स फ़ाइल जोड़ने पर विचार करें।

समस्या बनाएं और अनुरोध टेम्प्लेट खींचें

GitHub नए मुद्दों और पुल अनुरोधों के लिए स्टार्टर टेम्प्लेट का समर्थन करता है। किसी नई बनाई गई समस्या या पुल अनुरोध के लिए प्रारंभिक विवरण पाठ प्रदान करने के लिए इन टेम्पलेट्स का उपयोग करें।

उदाहरण के लिए, यदि आपकी परियोजना में .github/ISSUE_TEMPLATE.mdहै, तो जब भी कोई उपयोगकर्ता समस्या बनाने की प्रक्रिया शुरू करता है, तो वे इस सामग्री को देखते हैं। किसी CONTRIBUTING.mdसे आवश्यक विवरणों को लगातार संदर्भित करने के बजाय, वे टेम्पलेट टेक्स्ट का उपयोग करके एक फॉर्म की तरह समस्या को भरने में सक्षम हैं।

यह पुल अनुरोधों के लिए समान है, सिवाय इसके कि पथ .github/PULL_REQUEST_TEMPLATE.mdहै।

कुछ विस्मयकारी GitHub समस्या देखें & अनुरोध टेम्पलेट्सखींच लें।

वर्कफ़्लोज़ निर्धारित करें

उन प्रोजेक्ट्स के लिए जो बाह्य योगदान को प्रोत्साहित करते हैं, यह निर्दिष्ट करना सुनिश्चित करें कि प्रोजेक्ट किस वर्कफ़्लो का अनुसरण करता है. वर्कफ़्लो में इस बारे में विवरण शामिल होना चाहिए कि बग और सुविधाओं के लिए शाखाओं का उपयोग कहां और कैसे किया जाना चाहिए। इसमें यह भी शामिल होना चाहिए कि पुल अनुरोधों को कैसे खोला जाना चाहिए, और रिपॉजिटरी टीम के बाहर के लोगों को कोड पुश करने से पहले पता होना चाहिए। यदि आपके पास अभी तक वर्कफ़्लो को ध्यान में नहीं रखा गया है, तो आपको GitHub प्रवाह पर विचार करना चाहिए।

आपको रिलीज़ और परिनियोजन प्रबंधित करने के लिए एक रणनीति का संचार करना चाहिए। वर्कफ़्लो के ये भाग दिन-प्रतिदिन की शाखाओं में बँटने और विलय को प्रभावित करते हैं, इसलिए उन्हें योगदानकर्ताओं से संवाद करना महत्वपूर्ण है. इस बारे में अधिक जानें कि वे आपकी Git ब्रांचिंग रणनीति से कैसे संबंधित हैं.

कार्यक्रम की सफलता को मापना

इनरसोर्स में प्रवेश करने वाली किसी भी टीम को अपने कार्यक्रम की सफलता का आकलन करने के लिए उन मैट्रिक्स के प्रकारों के बारे में सोचना चाहिए जिन्हें वे ट्रैक करना चाहते हैं। जबकि "बाजार का समय" और "बग की रिपोर्ट" जैसे पारंपरिक मैट्रिक्स अभी भी लागू हैं, वे जरूरी नहीं कि इनरसोर्स के माध्यम से प्राप्त लाभों का वर्णन करें।

इसके बजाय, ऐसे मीट्रिक जोड़ने पर विचार करें, जो दिखाती हैं कि बाहरी भागीदारी ने प्रोजेक्ट गुणवत्ता को कैसे बेहतर बनाया. क्या रिपॉजिटरी बाहरी स्रोतों से पुल अनुरोध प्राप्त कर रही है जो बग को ठीक करती है और सुविधाओं को जोड़ती है? क्या परियोजना और उसके भविष्य के बारे में चर्चा में सक्रिय भागीदार हैं? क्या कार्यक्रम एक इनरसोर्स विस्तार को प्रेरित कर रहा है जो संगठन में कहीं और लाभ पहुंचाता है?

संक्षेप में, मेट्रिक्स कठिन हैं, खासकर जब व्यक्तिगत और टीम योगदान के मूल्य और प्रभाव को मापने की बात आती है। यदि दुरुपयोग किया जाता है, तो मैट्रिक्स संस्कृति, मौजूदा प्रक्रियाओं को नुकसान पहुंचा सकते हैं और संगठन या नेतृत्व टीम के प्रति सामूहिक भावना को कम कर सकते हैं। इनरसोर्स गोद लेने को मापने के बारे में सोचते समय, मैट्रिक्स पर निम्नलिखित मार्गदर्शन पर विचार करें:

• मापने की प्रक्रिया, आउटपुट नहीं
  • कोड समीक्षा टर्नअराउंड समय
  • अनुरोध का आकार खींचो
  • कार्य प्रगति पर है
  • खुलने का समय
• लक्ष्य के खिलाफ उपाय करें और निरपेक्षता नहीं
• टीमों को मापें न कि व्यक्तियों को
  • एक परियोजना के लिए अद्वितीय योगदानकर्ताओं की संख्या
  • कोड का पुन: उपयोग करने वाली परियोजनाओं की संख्या
  • क्रॉस-टीम @mentions की संख्या

इनरसोर्स केस स्टडीज इनमें दूसरों को मिली सफलताओं के बारे में जानें।