diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md new file mode 100644 index 00000000000..db31c75bfe7 --- /dev/null +++ b/_articles/hi/best-practices.md @@ -0,0 +1,281 @@ +--- +lang: hi +title: मेंटेनर्स के लिए सर्वोत्तम प्रैक्टिस +description: आपके जीवन को आसान बनाने के तरीके, संग्रहणिक प्रक्रियाओं से लेकर आपकी समुदाय का उपयोग करने तक, एक ओपन सोर्स मेंटेनर के रूप में। +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## मेंटेनर का मतलब क्या है? + +अगर आप किसी खुले स्रोत परियोजना का पालन करते हैं जिसका बहुत सारे लोग उपयोग करते हैं, तो आपने देखा होगा कि आप कोडिंग कम और मुद्दों के जवाब देने ज्यादा कर रहे हैं। + +परियोजना के प्रारंभिक चरण में, आप नए विचारों की प्रायोगिकता कर रहे होते हैं और निर्णय वही लेते हैं जो आप चाहते हैं। जब आपकी परियोजना लोकप्रिय होने लगती है, तो आप अपने उपयोगकर्ताओं और सहयोगियों के साथ काम करने के बारे में अधिक सोचेंगे। + +परियोजना को संभालने के लिए कोड से ज्यादा की आवश्यकता होती है। ये कार्य अक्सर अप्रत्याशित होते हैं, लेकिन एक बढ़ती हुई परियोजना के लिए ये उतने ही महत्वपूर्ण होते हैं। हमने कुछ तरीके जुटाए हैं जो आपके जीवन को आसान बनाने में मदद करेंगे, प्रक्रियाओं की दस्तावेजीकरण से लेकर आपकी समुदाय का उपयोग करने तक। + +## प्रक्रियाओं की दस्तावेजीकरण + +चीजों को लिखना मेंटेनर के रूप में आपकी सबसे महत्वपूर्ण चीजों में से एक है। + +दस्तावेजीकरण न केवल आपके विचारों को स्पष्ट करता है, बल्कि यह दूसरे लोगों को समझने में मदद करता है कि आपकी क्या आवश्यकताएं हैं या आपकी क्या उम्मीदें हैं, उनसे पहले ही। + +चीजें लिखने से, कुछ आपके स्कोप में नहीं आने पर "नहीं" कहना आसान हो जाता है। यह लोगों को साथ में आने और मदद करने के लिए भी आसान बनाता है। आप कभी नहीं जान सकते कि कौन-सा व्यक्ति आपकी परियोजना को पढ़ रहा है या उसका उपयोग कर रहा है। + +चाहे आप पूरे पैराग्राफ ना भी उपयोग करें, बुलेट पॉइंट्स को लिखना बिना कुछ लिखे होने से बेहतर है। + +याद रखें कि आपकी दस्तावेजीकरण को अपडेट रखने की आवश्यकता है। अगर आप हमेशा इसे अपडेट नहीं कर पा रहे हैं, तो अपने पुराने दस्तावेजीकरण को हटा दें या इसे पुराना बताएं ताकि सहयोगी जानें कि अपडेट्स का स्वागत है। + +### अपनी परियोजना की दृष्टि लिखें + +परियोजना के लक्ष्यों को लिखने की शुरुआत करें। उन्हें अपने README में जोड़ें, या एक अलग फ़ाइल जिसे VISION के नाम से बुलाया जा सकता है, बनाएं। अगर कोई और आर्टिफैक्ट हो सकते हैं जो मदद कर सकते हैं, जैसे कि परियोजना का रोडमैप, तो उन्हें भी सार्वजनिक बनाएं। + +स्पष्ट, दस्तावेजीत दृष्टि आपको ध्यान में रखने में मदद करती है और आपको दूसरों के सहयोग से आने वाले "स्कोप क्रीप" से बचाती है। + +उदाहरण के लिए, @lord ने यह जानकर पाया कि परियोजना की दृष्टि रखने से उसने यह तय किया कि किन अनुरोधों पर समय खर्च करना चाहिए। एक नए मेंटेनर के रूप में, उसने खेद किया कि उसने अपनी परियोजना की दिशा को न अपनाकर अपने पहले विशेषता अनुरोध के लिए [Slate](https://github.com/lord/slate) को मान्यता दी। + + + +### आपकी उम्मीदाएँ संवाद करें + +नियम लिखने के लिए हो सकते हैं और समय-समय पर यह घबराने वाला होता है। कभी-कभी आपको ऐसा लग सकता है कि आप दूसरों के व्यवहार की पुलिसी बना रहे हैं या सब मज़ा खत्म कर रहे हैं। + +लेकिन यदि नियम स्पष्ट, लिखित और सावधानीपूर्वक पालन किए जाएं, तो यह मेंटेनर्स को सशक्त बनाते हैं। वे आपको उन कामों में नहीं फंसने से बचाते हैं जिन्हें आप करना नहीं चाहते। + +आपकी परियोजना के बारे में ज्यादातर लोग आपके बारे में कुछ भी नहीं जानते हैं या आपके परिस्थितियों के बारे में। वे मान सकते हैं कि आप इस पर काम करने के लिए पैसे प्राप्त करते हैं, विशेष रूप से अगर यह कुछ है जिसका वे नियमित रूप से उपयोग करते हैं और उस पर निर्भर करते हैं। शायद किसी समय आपने अपनी परियोजना में काफी समय लगाया था, लेकिन अब आप एक नई नौकरी या परिवार के सदस्य के साथ व्यस्त हैं। + +ये सब बिल्कुल ठीक है! बस यह सुनिश्चित करें कि अन्य लोग इसके बारे में जानते हैं। + +यदि आपकी परियोजना को पार्ट-टाइम या पूरी तरह से स्वयंसेवा में बनाए रखना है, तो यह स्पष्ट रूप से बताएं कि आपके पास कितना समय है। यह उस समय के समान नहीं है जिसकी परियोजना को आपकी आवश्यकता है, या उस समय के समान नहीं है जिसे दुसरों को आपके खर्च करने के लिए चाहिए। + +यहाँ कुछ नियम हैं जो लिखने योग्य हैं: + +* किसी योगदान की समीक्षा और स्वीकार कैसे की जाती है (_क्या उन्हें परीक्षण की आवश्यकता है? एक समस्या टेम्पलेट?_) +* योगदान के प्रकार जिन्हें आप स्वीकार करेंगे (_क्या आप केवल अपने कोड के एक निश्चित भाग के लिए सहायता चाहते हैं?_) +* जब फॉलो-अप करना उचित हो (_उदाहरण के लिए, "आप 7 दिनों के भीतर अनुरक्षक से प्रतिक्रिया की उम्मीद कर सकते हैं। यदि आपने तब तक कुछ नहीं सुना है, तो बेझिझक थ्रेड को पिंग करें।"_) +* आप प्रोजेक्ट पर कितना समय बिताते हैं (उदाहरण के लिए, "हम इस प्रोजेक्ट पर प्रति सप्ताह केवल 5 घंटे खर्च करते हैं"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) अनुरक्षकों और योगदानकर्ताओं के लिए बुनियादी नियमों वाली परियोजनाओं के कई उदाहरण हैं। + +### संवाद को सार्वजनिक रखें + +अपने संवादों को डॉक्युमेंट करना न भूलें। जहां भी संभव हो, अपनी परियोजना के बारे में होने वाले संवाद को सार्वजनिक रूप से रखें। यदि कोई किसी विशेषता अनुरोध या समर्थन की आवश्यकता के लिए आपसे निजी तौर पर संपर्क करने का प्रयास करता है, तो उन्हें सवालों की सार्वजनिक संवाद स्रोत, जैसे कि मेलिंग सूची या समस्या ट्रैकर, की ओर सभीष्ठता से प्रेषित करें। + +यदि आप अन्य संरक्षकों से मिलते हैं, या यदि आप निजी तौर पर महत्वपूर्ण निर्णय लेते हैं, तो इन संवादों को सार्वजनिक डॉक्युमेंट करें, चाहे आपके नोट पोस्ट करने के बारे में भी हो। + +इस तरह, जो भी आपकी समुदाय में शामिल होता है, वह उसी जानकारी तक पहुँच पाएगा जो सालों से वहाँ हैने वाले किसी के पास है। + +## ना कहना सीखना + +आपने बातें लिख दी हैं. आदर्श रूप से, हर कोई आपके दस्तावेज़ को पढ़ेगा, लेकिन वास्तव में, आपको दूसरों को याद दिलाना होगा कि यह ज्ञान मौजूद है। + +हालाँकि, सब कुछ लिखित होने से उन स्थितियों को वैयक्तिकृत करने में मदद मिलती है जब आपको अपने नियमों को लागू करने की आवश्यकता होती है। + +ना कहना मज़ेदार नहीं है, लेकिन _"आपका योगदान इस परियोजना के मानदंडों से मेल नहीं खाता"__"मुझे आपका योगदान पसंद नहीं है"_ की तुलना में कम व्यक्तिगत लगता है। + +ना कहना उन कई स्थितियों पर लागू होता है जिनका सामना आप एक अनुरक्षक के रूप में करेंगे: सुविधा अनुरोध जो दायरे में फिट नहीं होते हैं, कोई व्यक्ति चर्चा को पटरी से उतार रहा है, दूसरों के लिए अनावश्यक काम कर रहा है। + +### बातचीत मित्रवत रखें + +सबसे महत्वपूर्ण स्थानों में से एक जहां आप ना कहने का अभ्यास करेंगे, वह है आपके मुद्दे पर और अनुरोध कतार को खींचना। एक प्रोजेक्ट अनुरक्षक के रूप में, आपको अनिवार्य रूप से ऐसे सुझाव प्राप्त होंगे जिन्हें आप स्वीकार नहीं करना चाहते हैं। + +हो सकता है कि योगदान आपके प्रोजेक्ट का दायरा बदल दे या आपके दृष्टिकोण से मेल न खाए। हो सकता है कि विचार अच्छा हो, लेकिन कार्यान्वयन ख़राब हो। + +कारण चाहे जो भी हो, उन योगदानों को चतुराई से संभालना संभव है जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करते हैं। + +यदि आपको कोई योगदान मिलता है जिसे आप स्वीकार नहीं करना चाहते हैं, तो आपकी पहली प्रतिक्रिया इसे अनदेखा करना या दिखावा करना हो सकता है कि आपने इसे नहीं देखा है। ऐसा करने से दूसरे व्यक्ति की भावनाएं आहत हो सकती हैं और यहां तक ​​कि आपके समुदाय में अन्य संभावित योगदानकर्ता भी हतोत्साहित हो सकते हैं। + + + +अनचाहे योगदान को खुले छोडने का कारण यह नहीं होना चाहिए कि आपको आपत्ति महसूस हो रही हो या आप अच्छे बनना चाहते हों। समय के साथ, आपके बिना उत्तरित मुद्दे और पुल रिक्वेस्ट (PRs) से आपके प्रोजेक्ट पर काम करने में अधिक तनावपूर्ण और डरावनी भावना उत्पन्न हो सकती है। + +जिन योगदानों को आप जानते हैं कि आप स्वीकार नहीं करना चाहते, उन्हें तुरंत बंद कर देना बेहतर है। यदि आपका प्रोजेक्ट पहले से ही बड़े बैकलॉग से ग्रस्त है, @steveklabnik [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) के लिए सुझाव हैं . + +योगदान को नज़रअंदाज करना आपके समुदाय को नकारात्मक संकेत भेजता है। किसी प्रोजेक्ट में योगदान देना डराने वाला हो सकता है, खासकर अगर यह किसी के लिए पहली बार हो। भले ही आप उनके योगदान को स्वीकार न करें, इसके पीछे वाले व्यक्ति को स्वीकार करें और उनकी रुचि के लिए उन्हें धन्यवाद दें। यह एक बड़ी प्रशंसा है! + +यदि आप कोई योगदान स्वीकार नहीं करना चाहते हैं: + +* **उन्हें उनके योगदान के लिए धन्यवाद** +* **स्पष्ट करें कि यह परियोजना के दायरे में क्यों फिट नहीं बैठता**, और यदि आप सक्षम हैं तो सुधार के लिए स्पष्ट सुझाव दें। दयालु बनें, लेकिन दृढ़ रहें। +* **प्रासंगिक दस्तावेज का लिंक**, यदि आपके पास है। यदि आप उन चीज़ों के लिए बार-बार अनुरोध देखते हैं जिन्हें आप स्वीकार नहीं करना चाहते हैं, तो उन्हें दोहराने से बचने के लिए उन्हें अपने दस्तावेज़ में जोड़ें। +* **अनुरोध बंद करें** + +You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +यदि ना कहने का विचार आपको भयभीत करता है, तो आप अकेले नहीं हैं। जैसा @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): + +> मैंने कई अलग-अलग ओपन सोर्स प्रोजेक्ट्स, मेसोस, कुबेरनेट्स, क्रोमियम के अनुरक्षकों से बात की है, और वे सभी इस बात से सहमत हैं कि अनुरक्षक होने के सबसे कठिन हिस्सों में से एक उन पैच को "नहीं" कहना है जिन्हें आप नहीं चाहते हैं। + +किसी के योगदान को स्वीकार न करने को लेकर दोषी महसूस न करें। ओपन सोर्स का पहला नियम, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _" +नहीं अस्थायी है, हाँ हमेशा के लिए है।"_ जबकि किसी अन्य व्यक्ति के उत्साह के साथ सहानुभूति रखना अच्छी बात है, किसी योगदान को अस्वीकार करना उसके पीछे वाले व्यक्ति को अस्वीकार करने के समान नहीं है। + +अंततः, यदि कोई योगदान पर्याप्त नहीं है, तो आप इसे स्वीकार करने के लिए बाध्य नहीं हैं। जब लोग आपके प्रोजेक्ट में योगदान दें तो दयालु और उत्तरदायी बनें, लेकिन केवल उन बदलावों को स्वीकार करें जिनके बारे में आपको वास्तव में विश्वास है कि वे आपके प्रोजेक्ट को बेहतर बनाएंगे। आप जितनी बार ना कहने का अभ्यास करेंगे, यह उतना ही आसान हो जाएगा। वादा करना। + +### सक्रिय होना + +सबसे पहले अवांछित योगदान की मात्रा को कम करने के लिए, अपने योगदान मार्गदर्शिका में योगदान जमा करने और स्वीकार करने के लिए अपने प्रोजेक्ट की प्रक्रिया की व्याख्या करें। + +यदि आपको बहुत अधिक निम्न-गुणवत्ता वाले योगदान प्राप्त हो रहे हैं, तो आवश्यक है कि योगदानकर्ता पहले से ही थोड़ा काम करें, उदाहरण के लिए: + +* कोई अंक या पीआर टेम्पलेट/चेकलिस्ट भरें +* पीआर सबमिट करने से पहले एक मुद्दा खोलें + +यदि वे आपके नियमों का पालन नहीं करते हैं, तो समस्या को तुरंत बंद करें और अपने दस्तावेज़ की ओर इंगित करें। + +हालाँकि यह दृष्टिकोण पहली बार में निर्दयी लग सकता है, सक्रिय होना वास्तव में दोनों पक्षों के लिए अच्छा है। इससे इस बात की संभावना कम हो जाती है कि कोई व्यक्ति काम के कई घंटे बर्बाद करके ऐसे पुल अनुरोध में लगाएगा जिसे आप स्वीकार नहीं करेंगे। और यह आपके कार्यभार को प्रबंधित करना आसान बनाता है। + + + +कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [स्थिति को शांत करने के लिए कदम उठाएं](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें। + +### मार्गदर्शन को गले लगाओ + +हो सकता है कि आपके समुदाय में कोई व्यक्ति नियमित रूप से ऐसे योगदान सबमिट करता हो जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करता हो। बार-बार अस्वीकृतियों से गुजरना दोनों पक्षों के लिए निराशाजनक हो सकता है। + +यदि आप देखते हैं कि कोई आपके प्रोजेक्ट को लेकर उत्साहित है, लेकिन उसे थोड़ा निखारने की जरूरत है, तो धैर्य रखें। प्रत्येक स्थिति में स्पष्ट रूप से बताएं कि उनका योगदान परियोजना की अपेक्षाओं को पूरा क्यों नहीं करता है। उन्हें किसी आसान या कम अस्पष्ट कार्य की ओर इंगित करने का प्रयास करें, जैसे उनके पैरों को गीला करने के लिए _"अच्छा पहला अंक,"_ चिह्नित कोई मुद्दा। यदि आपके पास समय है, तो उनके पहले योगदान के माध्यम से उन्हें सलाह देने पर विचार करें, या अपने समुदाय में किसी और को ढूंढें जो उन्हें सलाह देने के लिए तैयार हो सकता है। + +## अपने समुदाय का लाभ उठाएं + +आपको सब कुछ खुद ही करने की ज़रूरत नहीं है. आपके प्रोजेक्ट का समुदाय किसी कारण से मौजूद है! भले ही आपके पास अभी तक कोई सक्रिय योगदानकर्ता समुदाय नहीं है, यदि आपके पास बहुत सारे उपयोगकर्ता हैं, तो उन्हें काम पर लगाएं। + +### कार्यभार साझा करें + +यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें। + +नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [ऐसे लेबल मुद्दे जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी। + +जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं। + +दूसरों को इसके लिए प्रोत्साहित करना [अपने प्रोजेक्ट का स्वामित्व साझा करें](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js). + + + +यदि आपको अपने प्रोजेक्ट से हटना है, या तो अंतराल पर या स्थायी रूप से, तो किसी और को आपकी जगह लेने के लिए कहने में कोई शर्म की बात नहीं है। + +यदि अन्य लोग इसकी दिशा को लेकर उत्साहित हैं, तो उन्हें प्रतिबद्ध पहुंच प्रदान करें या औपचारिक रूप से नियंत्रण किसी और को सौंप दें। यदि किसी ने आपके प्रोजेक्ट को फोर्क किया है और इसे कहीं और सक्रिय रूप से बनाए रख रहा है, तो अपने मूल प्रोजेक्ट से फोर्क को जोड़ने पर विचार करें। यह बहुत अच्छा है कि इतने सारे लोग चाहते हैं कि आपका प्रोजेक्ट चालू रहे! + +@progrium [ने पाया कि](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) अपने प्रोजेक्ट, [Dokku](https://github.com/dokku/dokku) के लिए विज़न का दस्तावेजीकरण करने से, प्रोजेक्ट से जाने के बाद भी उन लक्ष्यों को जीवित रखने में मदद मिली: + +> मैंने एक विकी पेज लिखा जिसमें बताया गया कि मैं क्या चाहता था और मैं यह क्यों चाहता था। किसी कारण से यह मेरे लिए आश्चर्य की बात थी कि अनुरक्षकों ने परियोजना को उस दिशा में आगे बढ़ाना शुरू कर दिया! क्या यह बिल्कुल वैसा ही हुआ जैसा मैंने इसे किया था? हमेशा नहीं। लेकिन फिर भी यह परियोजना को मैंने जो लिखा था उसके करीब ले आया। + +### दूसरों को वे समाधान बनाने दें जिनकी उन्हें आवश्यकता है + +यदि किसी संभावित योगदानकर्ता की इस बारे में अलग राय है कि आपके प्रोजेक्ट को क्या करना चाहिए, तो आप उन्हें धीरे-धीरे अपने स्वयं के कांटे पर काम करने के लिए प्रोत्साहित करना चाह सकते हैं। + +किसी प्रोजेक्ट को फोर्क करना कोई बुरी बात नहीं है। प्रोजेक्टों को कॉपी और संशोधित करने में सक्षम होना ओपन सोर्स के बारे में सबसे अच्छी चीजों में से एक है। अपने समुदाय के सदस्यों को अपने स्वयं के फ़ोर्क पर काम करने के लिए प्रोत्साहित करना, आपके प्रोजेक्ट के दृष्टिकोण के साथ टकराव किए बिना, उन्हें आवश्यक रचनात्मक आउटलेट प्रदान कर सकता है। + + + +यही बात उस उपयोगकर्ता पर लागू होती है जो वास्तव में एक ऐसा समाधान चाहता है जिसे बनाने के लिए आपके पास बैंडविड्थ नहीं है। एपीआई और अनुकूलन हुक की पेशकश दूसरों को स्रोत को सीधे संशोधित किए बिना, अपनी जरूरतों को पूरा करने में मदद कर सकती है। @orta [ने पाया कि](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) कोकोपोड्स के लिए प्लगइन्स को प्रोत्साहित करने से "कुछ सबसे दिलचस्प विचार" सामने आए: + +> यह लगभग अपरिहार्य है कि एक बार जब कोई परियोजना बड़ी हो जाती है, तो अनुरक्षकों को इस बारे में अधिक रूढ़िवादी बनना पड़ता है कि वे नए कोड कैसे पेश करते हैं। आप "नहीं" कहने में अच्छे हो जाते हैं, लेकिन बहुत से लोगों की ज़रूरतें वैध होती हैं। तो, इसके बजाय आप अपने टूल को एक प्लेटफ़ॉर्म में परिवर्तित कर देते हैं। + +## रोबोट लाओ + +जिस प्रकार ऐसे कार्य हैं जिनमें अन्य लोग आपकी सहायता कर सकते हैं, वैसे ही ऐसे कार्य भी हैं जिन्हें किसी भी मनुष्य को कभी नहीं करना चाहिए। रोबोट आपके मित्र हैं. एक अनुरक्षक के रूप में अपने जीवन को आसान बनाने के लिए उनका उपयोग करें। + +### आपके कोड की गुणवत्ता में सुधार के लिए परीक्षण और अन्य जांच की आवश्यकता है + +परीक्षण जोड़कर अपने प्रोजेक्ट को स्वचालित करने का सबसे महत्वपूर्ण तरीका है। + +परीक्षण योगदानकर्ताओं को यह विश्वास दिलाने में मदद करते हैं कि वे कुछ भी नहीं तोड़ेंगे। वे आपके लिए योगदान की शीघ्रता से समीक्षा करना और स्वीकार करना भी आसान बनाते हैं। आप जितने अधिक संवेदनशील होंगे, आपका समुदाय उतना ही अधिक सक्रिय हो सकता है। + +स्वचालित परीक्षण सेट करें जो आने वाले सभी योगदानों पर चलेंगे, और सुनिश्चित करें कि आपके परीक्षण योगदानकर्ताओं द्वारा स्थानीय स्तर पर आसानी से चलाए जा सकें। आवश्यक है कि सबमिट किए जाने से पहले सभी कोड योगदान आपके परीक्षणों में उत्तीर्ण हों। आप सभी प्रस्तुतियों के लिए गुणवत्ता का न्यूनतम मानक निर्धारित करने में मदद करेंगे। GitHub पर [आवश्यक स्थिति जांच](https://help.github.com/articles/about-required-status-checks/) यह सुनिश्चित करने में मदद कर सकता है कि आपके परीक्षण पास किए बिना कोई भी परिवर्तन मर्ज नहीं किया जाएगा। + +यदि आप परीक्षण जोड़ते हैं, तो यह बताना सुनिश्चित करें कि वे आपकी CONTRIBUTING फ़ाइल में कैसे काम करते हैं। + + + +### बुनियादी रखरखाव कार्यों को स्वचालित करने के लिए टूल का उपयोग करें + +एक लोकप्रिय परियोजना को बनाए रखने के बारे में अच्छी खबर यह है कि अन्य रखरखावकर्ताओं ने संभवतः इसी तरह के मुद्दों का सामना किया है और उनके लिए एक समाधान तैयार किया है। + +रखरखाव कार्य के कुछ पहलुओं को स्वचालित करने में मदद के लिए [विभिन्न प्रकार के उपकरण उपलब्ध हैं](https://github.com/showcases/tools-for-open-source) हैं। कुछ उदाहरण: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases +* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests +* [Danger](https://github.com/danger/danger) helps automate code review +* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information +* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds + +बग रिपोर्ट और अन्य सामान्य योगदानों के लिए, GitHub के पास [इश्यू टेम्प्लेट्स और पुल रिक्वेस्ट टेम्प्लेट्स](https://github.com/blog/2111-issue-and-pull-request-templates) हैं, जिन्हें आप संचार को सुव्यवस्थित करने के लिए बना सकते हैं आपको प्राप्त हुया। @TalAter ने आपके मुद्दे और पीआर टेम्प्लेट लिखने में आपकी मदद करने के लिए एक [अपनी खुद की एडवेंचर गाइड चुनें](https://www.talater.com/open-source-templates/#/) बनाई है। + +अपनी ईमेल सूचनाओं को प्रबंधित करने के लिए, आप प्राथमिकता के आधार पर व्यवस्थित करने के लिए [ईमेल फ़िल्टर](https://github.com/blog/2203-email-updates-about-your-own-activity) सेट कर सकते हैं। + +यदि आप थोड़ा और उन्नत होना चाहते हैं, तो स्टाइल गाइड और लिंटर परियोजना योगदान को मानकीकृत कर सकते हैं और उनकी समीक्षा करना और स्वीकार करना आसान बना सकते हैं। + +हालाँकि, यदि आपके मानक बहुत जटिल हैं, तो वे योगदान में बाधाएँ बढ़ा सकते हैं। सुनिश्चित करें कि आप सभी के जीवन को आसान बनाने के लिए केवल पर्याप्त नियम जोड़ रहे हैं। + +यदि आप निश्चित नहीं हैं कि कौन से टूल का उपयोग करना है, तो देखें कि अन्य लोकप्रिय प्रोजेक्ट क्या करते हैं, विशेष रूप से आपके पारिस्थितिकी तंत्र में। उदाहरण के लिए, अन्य नोड मॉड्यूल के लिए योगदान प्रक्रिया कैसी दिखती है? समान टूल और दृष्टिकोण का उपयोग करने से आपकी प्रक्रिया आपके लक्षित योगदानकर्ताओं के लिए अधिक परिचित हो जाएगी। + +## विराम देना ठीक है + +ओपन सोर्स का काम एक बार आपके लिए खुशी लेकर आया। शायद अब यह आपको टालने या दोषी महसूस कराने लगा है। + +जब आप अपनी परियोजनाओं के बारे में सोचते हैं तो शायद आप अभिभूत महसूस कर रहे हों या भय की भावना बढ़ रही हो। और इस बीच, मुद्दों और पुल अनुरोधों का ढेर लग जाता है। + +ओपन सोर्स कार्य में बर्नआउट एक वास्तविक और व्यापक मुद्दा है, विशेषकर अनुरक्षकों के बीच। एक अनुरक्षक के रूप में, किसी भी ओपन सोर्स प्रोजेक्ट के अस्तित्व के लिए आपकी खुशी एक गैर-परक्राम्य आवश्यकता है। + +हालाँकि यह बिना कहे चला जाना चाहिए, एक ब्रेक लें! आपको छुट्टी लेने के लिए तब तक इंतजार नहीं करना चाहिए जब तक आप थका हुआ महसूस न करें। @brettcannon, एक पायथन कोर डेवलपर, ने 14 साल के स्वयंसेवक OSS के बाद [एक महीने की छुट्टी](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) लेने का फैसला किया काम। + +किसी भी अन्य प्रकार के काम की तरह, नियमित ब्रेक लेने से आप अपने काम के प्रति तरोताजा, खुश और उत्साहित रहेंगे। + + + +कभी-कभी, जब ऐसा महसूस हो कि हर किसी को आपकी ज़रूरत है तो ओपन सोर्स कार्य से ब्रेक लेना कठिन हो सकता है। लोग आपको दूर जाने के लिए दोषी महसूस कराने का प्रयास भी कर सकते हैं। + +जब आप किसी प्रोजेक्ट से दूर हों तो अपने उपयोगकर्ताओं और समुदाय के लिए समर्थन पाने की पूरी कोशिश करें। यदि आपको आवश्यक सहायता नहीं मिल पा रही है, तो फिर भी एक ब्रेक ले लें। जब आप उपलब्ध न हों तो संवाद करना सुनिश्चित करें, ताकि लोग आपकी प्रतिक्रियाशीलता की कमी से भ्रमित न हों। + +ब्रेक लेना केवल छुट्टियों के अलावा और भी बहुत कुछ पर लागू होता है। यदि आप सप्ताहांत पर या काम के घंटों के दौरान ओपन सोर्स काम नहीं करना चाहते हैं, तो उन अपेक्षाओं को दूसरों को बताएं, ताकि वे जान सकें कि आपको परेशान नहीं करना है। + +## पहले अपना ख्याल रखें! + +किसी लोकप्रिय प्रोजेक्ट को बनाए रखने के लिए विकास के शुरुआती चरणों की तुलना में अलग कौशल की आवश्यकता होती है, लेकिन यह कम फायदेमंद नहीं है। एक अनुरक्षक के रूप में, आप नेतृत्व और व्यक्तिगत कौशल का उस स्तर पर अभ्यास करेंगे जिसका अनुभव बहुत कम लोगों को होता है। हालाँकि इसे प्रबंधित करना हमेशा आसान नहीं होता है, स्पष्ट सीमाएँ निर्धारित करना और केवल वही लेना जिसमें आप सहज हों, आपको खुश, तरोताज़ा और उत्पादक रहने में मदद करेगा। diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md new file mode 100644 index 00000000000..642194d3c0b --- /dev/null +++ b/_articles/hi/building-community.md @@ -0,0 +1,278 @@ +--- +lang: hi +title: स्वागत योग्य समुदायों का निर्माण +description: एक ऐसे समुदाय का निर्माण करना जो लोगों को आपके प्रोजेक्ट का उपयोग करने, उसमें योगदान करने और उसका प्रचार-प्रसार करने के लिए प्रोत्साहित करे। +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## सफलता के लिए अपना प्रोजेक्ट तैयार करना + +आपने अपना प्रोजेक्ट लॉन्च कर दिया है, आप इसका प्रचार-प्रसार कर रहे हैं और लोग इसकी जांच कर रहे हैं। बहुत बढ़िया! अब, आप उन्हें अपने साथ कैसे जोड़े रखेंगे? + +स्वागत करने वाला समुदाय आपके प्रोजेक्ट के भविष्य और प्रतिष्ठा में एक निवेश है। यदि आपका प्रोजेक्ट अभी अपना पहला योगदान देखना शुरू कर रहा है, तो शुरुआती योगदानकर्ताओं को एक सकारात्मक अनुभव देकर शुरुआत करें, और उनके लिए वापस आना आसान बनाएं। + +### लोगों को स्वागत का एहसास कराएं + +आपके प्रोजेक्ट के समुदाय के बारे में सोचने का एक तरीका यह है कि @MikeMcQuaid इसे [योगदानकर्ता फ़नल](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) कहता है: + +![योगदानकर्ता फ़नल](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +जैसे ही आप अपना समुदाय बनाते हैं, इस बात पर विचार करें कि फ़नल के शीर्ष पर कोई व्यक्ति (एक संभावित उपयोगकर्ता) सैद्धांतिक रूप से नीचे (एक सक्रिय अनुरक्षक) तक अपना रास्ता कैसे बना सकता है। आपका लक्ष्य योगदानकर्ता अनुभव के प्रत्येक चरण में घर्षण को कम करना है। जब लोगों को आसानी से जीत मिलती है, तो वे और अधिक करने के लिए प्रोत्साहित महसूस करेंगे। + +अपने दस्तावेज़ से प्रारंभ करें: + +* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-रीडमी-लिखना) +और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे। +* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#अपने-योगदान-संबंधी-दिशानिर्देश-लिखना) और अपने मुद्दों को अद्यतन रखते हुए। +* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं। + +[GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें। + +* **जब कोई नया व्यक्ति आपके प्रोजेक्ट पर आता है, तो उनकी रुचि के लिए उन्हें धन्यवाद दें!** किसी को वापस आने से रोकने के लिए केवल एक नकारात्मक अनुभव की आवश्यकता होती है। +* **उत्तरदायी बनें।** यदि आप एक महीने तक उनके मुद्दे पर प्रतिक्रिया नहीं देते हैं, तो संभावना है कि वे पहले ही आपके प्रोजेक्ट के बारे में भूल चुके होंगे। +* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। [योगदान करने के कई तरीके](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) हैं। लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें। +* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#ना-कहना-सीखना) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें। + + + +अधिकांश ओपन सोर्स योगदानकर्ता "आकस्मिक योगदानकर्ता" हैं: वे लोग जो कभी-कभार ही किसी परियोजना में योगदान करते हैं। एक आकस्मिक योगदानकर्ता के पास आपके प्रोजेक्ट को पूरी तरह से गति देने का समय नहीं हो सकता है, इसलिए आपका काम उनके लिए योगदान करना आसान बनाना है। + +अन्य योगदानकर्ताओं को प्रोत्साहित करना आपके लिए भी एक निवेश है। जब आप अपने सबसे बड़े प्रशंसकों को उस काम के लिए सशक्त बनाते हैं जिसके लिए वे उत्साहित हैं, तो सब कुछ स्वयं करने का दबाव कम होता है। + +### हर चीज़ का दस्तावेजीकरण करें + + + +जब आप कोई नया प्रोजेक्ट शुरू करते हैं, तो अपने काम को निजी रखना स्वाभाविक लग सकता है। लेकिन जब आप अपनी प्रक्रिया को सार्वजनिक रूप से दस्तावेज़ित करते हैं तो ओपन सोर्स प्रोजेक्ट फलते-फूलते हैं। + +जब आप चीज़ें लिखते हैं, तो हर कदम पर अधिक लोग भाग ले सकते हैं। आपको किसी ऐसी चीज़ पर मदद मिल सकती है जिसके बारे में आपको पता भी नहीं था कि आपको इसकी ज़रूरत है। + +चीज़ों को लिखने का अर्थ केवल तकनीकी दस्तावेज़ीकरण से कहीं अधिक है। जब भी आपको कुछ लिखने या अपने प्रोजेक्ट पर निजी तौर पर चर्चा करने की इच्छा महसूस हो, तो अपने आप से पूछें कि क्या आप इसे सार्वजनिक कर सकते हैं। + +अपने प्रोजेक्ट के रोडमैप, आप किस प्रकार के योगदान की तलाश कर रहे हैं, योगदान की समीक्षा कैसे की जाती है, या आपने कुछ निर्णय क्यों लिए, इस बारे में पारदर्शी रहें। + +यदि आप देखते हैं कि कई उपयोगकर्ता एक ही समस्या से जूझ रहे हैं, तो उत्तरों को README में दर्ज करें। + +बैठकों के लिए, किसी प्रासंगिक मुद्दे पर अपने नोट्स या निष्कर्ष प्रकाशित करने पर विचार करें। पारदर्शिता के इस स्तर से आपको जो फीडबैक मिलेगा वह आपको आश्चर्यचकित कर सकता है। + +हर चीज़ का दस्तावेज़ीकरण आपके द्वारा किए जाने वाले काम पर भी लागू होता है। यदि आप अपने प्रोजेक्ट में पर्याप्त अपडेट पर काम कर रहे हैं, तो इसे पुल अनुरोध में डालें और इसे कार्य प्रगति पर (डब्ल्यूआईपी) के रूप में चिह्नित करें। इस तरह, अन्य लोग शुरू से ही इस प्रक्रिया में शामिल महसूस कर सकते हैं। + +### उत्तरदायी बनें + +जैसे ही आप [अपने प्रोजेक्ट का प्रचार करें](../finding-users), लोगों के पास आपके लिए प्रतिक्रिया होगी. उनके मन में यह सवाल हो सकता है कि चीज़ें कैसे काम करती हैं, या उन्हें आरंभ करने में सहायता की आवश्यकता हो सकती है। + +जब कोई व्यक्ति कोई समस्या दर्ज करता है, पुल अनुरोध सबमिट करता है, या आपके प्रोजेक्ट के बारे में कोई प्रश्न पूछता है तो प्रतिक्रियाशील बनने का प्रयास करें। जब आप तुरंत प्रतिक्रिया देते हैं, तो लोगों को लगेगा कि वे एक संवाद का हिस्सा हैं, और वे भाग लेने के लिए अधिक उत्साहित होंगे। + +भले ही आप तुरंत अनुरोध की समीक्षा नहीं कर सकते, लेकिन इसे जल्दी स्वीकार करने से जुड़ाव बढ़ाने में मदद मिलती है। यहां बताया गया है कि @tdreyno ने [मिडिलमैन](https://github.com/middleman/middleman/pull/1466) पर पुल अनुरोध का जवाब कैसे दिया: + +![बिचौलिए का अनुरोध](/assets/images/building-community/middleman_pr.png) + +[मोज़िला के एक अध्ययन में यह पाया गया](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) जिन योगदानकर्ताओं को 48 घंटों के भीतर कोड समीक्षाएँ प्राप्त हुईं, उनकी वापसी और दोहराव योगदान की दर बहुत अधिक थी। + +आपके प्रोजेक्ट के बारे में बातचीत इंटरनेट पर स्टैक ओवरफ्लो, ट्विटर या रेडिट जैसे अन्य स्थानों पर भी हो सकती है। आप इनमें से कुछ स्थानों पर सूचनाएं सेट कर सकते हैं ताकि जब कोई आपके प्रोजेक्ट का उल्लेख करे तो आप सतर्क हो जाएं। + +### अपने समुदाय को एकत्र होने के लिए जगह दें + +अपने समुदाय को एकत्रित होने के लिए जगह देने के दो कारण हैं। + +पहला कारण उनके लिए है. लोगों को एक-दूसरे को जानने में मदद करें। समान रुचि वाले लोग अनिवार्य रूप से इसके बारे में बात करने के लिए जगह चाहेंगे। और जब संचार सार्वजनिक और सुलभ होता है, तो कोई भी गति प्राप्त करने और भाग लेने के लिए पिछले अभिलेखों को पढ़ सकता है। + +दूसरा कारण आपके लिए है. यदि आप लोगों को अपने प्रोजेक्ट के बारे में बात करने के लिए सार्वजनिक स्थान नहीं देते हैं, तो वे संभवतः आपसे सीधे संपर्क करेंगे। शुरुआत में, निजी संदेशों का "सिर्फ एक बार" जवाब देना काफी आसान लग सकता है। लेकिन समय के साथ, खासकर यदि आपका प्रोजेक्ट लोकप्रिय हो जाता है, तो आप थकावट महसूस करेंगे। अपने प्रोजेक्ट के बारे में लोगों से निजी तौर पर संवाद करने के प्रलोभन से बचें। इसके बजाय, उन्हें एक निर्दिष्ट सार्वजनिक चैनल पर निर्देशित करें। + +सार्वजनिक संचार उतना ही सरल हो सकता है जितना लोगों को आपको सीधे ईमेल करने या आपके ब्लॉग पर टिप्पणी करने के बजाय किसी मुद्दे को खोलने के लिए निर्देशित करना। आप अपने प्रोजेक्ट के बारे में लोगों से बात करने के लिए एक मेलिंग सूची भी सेट कर सकते हैं, या एक ट्विटर अकाउंट, स्लैक या आईआरसी चैनल बना सकते हैं। या उपरोक्त सभी प्रयास करें! +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) समुदाय के सदस्यों की सहायता के लिए हर दूसरे सप्ताह कार्यालय समय अलग रखें: + +> कोप्स के पास समुदाय को सहायता और मार्गदर्शन प्रदान करने के लिए हर दूसरे सप्ताह का समय भी निर्धारित होता है। कोप्स अनुरक्षकों ने नवागंतुकों के साथ काम करने, पीआर के साथ मदद करने और नई सुविधाओं पर चर्चा करने के लिए विशेष रूप से समर्पित समय निर्धारित करने पर सहमति व्यक्त की है। + +सार्वजनिक संचार के उल्लेखनीय अपवाद हैं: 1. सुरक्षा मुद्दे और 2. संवेदनशील आचार संहिता का उल्लंघन। आपके पास लोगों के लिए इन मुद्दों की निजी तौर पर रिपोर्ट करने का हमेशा एक तरीका होना चाहिए। यदि आप अपने व्यक्तिगत ईमेल का उपयोग नहीं करना चाहते हैं, तो एक समर्पित ईमेल पता सेट करें। + +## अपने समुदाय को बढ़ाना + +समुदाय अत्यंत शक्तिशाली हैं. वह शक्ति वरदान या अभिशाप हो सकती है, यह इस बात पर निर्भर करता है कि आप उसका उपयोग कैसे करते हैं। जैसे-जैसे आपके प्रोजेक्ट का समुदाय बढ़ता है, उसे विनाश की नहीं बल्कि निर्माण की शक्ति बनने में मदद करने के कई तरीके हैं। + +### बुरे अभिनेताओं को बर्दाश्त न करें + +कोई भी लोकप्रिय परियोजना अनिवार्य रूप से ऐसे लोगों को आकर्षित करेगी जो आपके समुदाय को मदद करने के बजाय नुकसान पहुंचाते हैं। वे अनावश्यक बहस शुरू कर सकते हैं, छोटी-छोटी बातों पर विवाद कर सकते हैं, या दूसरों को धमका सकते हैं। + +इस प्रकार के लोगों के प्रति शून्य-सहिष्णुता की नीति अपनाने की पूरी कोशिश करें। यदि अनियंत्रित छोड़ दिया जाए, तो नकारात्मक लोग आपके समुदाय के अन्य लोगों को असहज कर देंगे। वे चले भी सकते हैं. + + + +आपके प्रोजेक्ट के तुच्छ पहलुओं पर नियमित बहस आपके सहित दूसरों को महत्वपूर्ण कार्यों पर ध्यान केंद्रित करने से विचलित करती है। आपके प्रोजेक्ट में आने वाले नए लोग इन वार्तालापों को देख सकते हैं और भाग नहीं लेना चाहेंगे। + +जब आप अपने प्रोजेक्ट पर नकारात्मक व्यवहार होते देखें, तो उसे सार्वजनिक रूप से बताएं। दयालु लेकिन दृढ़ स्वर में बताएं कि उनका व्यवहार स्वीकार्य क्यों नहीं है। यदि समस्या बनी रहती है, तो आपको इसकी आवश्यकता हो सकती है [उन्हें जाने के लिए कहो](../code-of-conduct/#अपनी-आचार-संहिता-लागू-करना). आपके [आचार संहिता](../code-of-conduct/) इन वार्तालापों के लिए एक रचनात्मक मार्गदर्शक हो सकता है। + +### योगदानकर्ताओं से वहीं मिलें जहां वे हैं + +जैसे-जैसे आपका समुदाय बढ़ता है, अच्छा दस्तावेज़ीकरण और अधिक महत्वपूर्ण हो जाता है। आकस्मिक योगदानकर्ता, जो अन्यथा आपके प्रोजेक्ट से परिचित नहीं हो सकते हैं, उन्हें जिस संदर्भ की आवश्यकता है उसे तुरंत प्राप्त करने के लिए आपके दस्तावेज़ को पढ़ें। + +अपनी योगदान फ़ाइल में, नए योगदानकर्ताओं को स्पष्ट रूप से बताएं कि शुरुआत कैसे करें। आप इस उद्देश्य के लिए एक समर्पित अनुभाग भी बनाना चाह सकते हैं। उदाहरण के लिए, [Django](https://github.com/django/django) के पास नए योगदानकर्ताओं का स्वागत करने के लिए एक विशेष लैंडिंग पृष्ठ है। + +![Django नया योगदानकर्ता पृष्ठ](/assets/images/building-community/django_new_contributors.png) + +अपनी समस्या कतार में, ऐसे बग लेबल करें जो विभिन्न प्रकार के योगदानकर्ताओं के लिए उपयुक्त हों: उदाहरण के लिए, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) आपके प्रोजेक्ट में नए व्यक्ति के लिए आपके मुद्दों को तुरंत स्कैन करना और आरंभ करना आसान बनाएं। + +अंत में, लोगों को हर कदम पर स्वागत महसूस कराने के लिए अपने दस्तावेज़ का उपयोग करें। + +आप उन अधिकांश लोगों के साथ कभी बातचीत नहीं करेंगे जो आपके प्रोजेक्ट पर आते हैं। ऐसे योगदान भी हो सकते हैं जो आपको इसलिए नहीं मिले क्योंकि कोई व्यक्ति डरा हुआ महसूस कर रहा था या नहीं जानता था कि कहां से शुरुआत करें। यहां तक ​​कि कुछ दयालु शब्द भी किसी को हताशा में आपका प्रोजेक्ट छोड़ने से रोक सकते हैं। + +उदाहरण के लिए, यहां बताया गया है कि कैसे [Rubinius](https://github.com/rubinius/rubinius/) प्रारंभ होगा [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> हम रुबिनियस का उपयोग करने के लिए आपको धन्यवाद कहकर शुरुआत करना चाहते हैं। यह परियोजना प्यार का परिश्रम है, और हम उन सभी उपयोगकर्ताओं की सराहना करते हैं जो बग पकड़ते हैं, प्रदर्शन में सुधार करते हैं और दस्तावेज़ीकरण में मदद करते हैं। प्रत्येक योगदान सार्थक है, इसलिए भाग लेने के लिए धन्यवाद। जैसा कि कहा जा रहा है, यहां कुछ दिशानिर्देश दिए गए हैं जिनका पालन करने के लिए हम आपसे कहते हैं ताकि हम आपकी समस्या का सफलतापूर्वक समाधान कर सकें। + +### अपने प्रोजेक्ट का स्वामित्व साझा करें + + + +जब लोग स्वामित्व की भावना महसूस करते हैं तो वे परियोजनाओं में योगदान देने के लिए उत्साहित होते हैं। इसका मतलब यह नहीं है कि आपको अपने प्रोजेक्ट के दृष्टिकोण को बदलना होगा या उन योगदानों को स्वीकार करना होगा जो आप नहीं चाहते हैं। लेकिन जितना अधिक आप दूसरों को श्रेय देंगे, उतना ही अधिक वे आपके साथ बने रहेंगे। + +देखें कि क्या आप अपने समुदाय के साथ स्वामित्व को यथासंभव साझा करने के तरीके ढूंढ सकते हैं। यहाँ कुछ विचार हैं: + +* **आसान (गैर-महत्वपूर्ण) बग को ठीक करने का विरोध करें।** इसके बजाय, उन्हें नए योगदानकर्ताओं को भर्ती करने के अवसर के रूप में उपयोग करें, या किसी ऐसे व्यक्ति का मार्गदर्शन करें जो योगदान देना चाहता है। यह पहली बार में अस्वाभाविक लग सकता है, लेकिन आपका निवेश समय के साथ फल देगा। उदाहरण के लिए, @michaeljoseph ने एक योगदानकर्ता से इसे स्वयं ठीक करने के बजाय नीचे दिए गए [कुकीकटर](https://github.com/audreyr/cookiecutter) मुद्दे पर एक पुल अनुरोध सबमिट करने के लिए कहा। + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **अपने प्रोजेक्ट में एक योगदानकर्ता या लेखक फ़ाइल प्रारंभ करें** जिसमें आपके प्रोजेक्ट में योगदान देने वाले सभी लोगों की सूची हो, जैसे [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) +करता है. + +* यदि आपके पास एक बड़ा समुदाय है, तो **एक समाचार पत्र भेजें या एक ब्लॉग पोस्ट लिखें** योगदानकर्ताओं को धन्यवाद दें। जंग का [This Week in Rust](https://this-week-in-rust.org/) और हुडीज़ [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) दो अच्छे उदाहरण हैं. + +* **प्रत्येक योगदानकर्ता को पहुंच प्रदान करें** @felixge ने पाया कि इसने लोगों को बनाया है [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), और उन्हें उन परियोजनाओं के लिए नए अनुरक्षक भी मिल गए जिन पर उन्होंने कुछ समय से काम नहीं किया था। + +* यदि आपका प्रोजेक्ट GitHub पर है, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** और कम से कम एक बैकअप व्यवस्थापक जोड़ें. संगठन बाहरी सहयोगियों के साथ परियोजनाओं पर काम करना आसान बनाते हैं। + +हकीकत तो यही है [most projects only have](https://peerj.com/preprints/1233/) एक या दो अनुरक्षक जो अधिकांश कार्य करते हैं। आपका प्रोजेक्ट जितना बड़ा होगा, और आपका समुदाय जितना बड़ा होगा, सहायता पाना उतना ही आसान होगा। + +हालाँकि आपको कॉल का उत्तर देने के लिए हमेशा कोई नहीं मिल सकता है, लेकिन वहाँ सिग्नल लगाने से अन्य लोगों के कॉल करने की संभावना बढ़ जाती है। और आप जितनी जल्दी शुरुआत करेंगे, उतनी जल्दी लोग मदद कर सकते हैं। + + + +## विवादों का समाधान + +आपके प्रोजेक्ट के शुरुआती चरणों में, बड़े निर्णय लेना आसान होता है। जब आप कुछ करना चाहते हैं, तो आप बस उसे करते हैं। + +जैसे-जैसे आपका प्रोजेक्ट अधिक लोकप्रिय होगा, अधिक लोग आपके निर्णयों में रुचि लेंगे। भले ही आपके पास योगदानकर्ताओं का एक बड़ा समुदाय न हो, यदि आपके प्रोजेक्ट में बहुत सारे उपयोगकर्ता हैं, तो आप पाएंगे कि लोग निर्णयों पर विचार कर रहे हैं या अपने स्वयं के मुद्दे उठा रहे हैं। + +अधिकांश भाग के लिए, यदि आपने एक मैत्रीपूर्ण, सम्मानजनक समुदाय विकसित किया है और अपनी प्रक्रियाओं को खुले तौर पर प्रलेखित किया है, तो आपका समुदाय समाधान खोजने में सक्षम होना चाहिए। लेकिन कभी-कभी आप ऐसे मुद्दे में फंस जाते हैं जिसका समाधान करना थोड़ा कठिन होता है। + +### दयालुता का स्तर निर्धारित करें + +जब आपका समुदाय किसी कठिन मुद्दे से जूझ रहा हो, तो गुस्सा बढ़ सकता है। लोग क्रोधित या निराश हो सकते हैं और इसे एक-दूसरे पर या आप पर निकाल सकते हैं। + +एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [तुरंत कार्रवाई करें](../building-community/#बुरे-अभिनेताओं-को-बर्दाश्त-न-करें) +चर्चाओं को सभ्य और उत्पादक बनाए रखना। + + + +अन्य लोग मार्गदर्शन के लिए आपकी ओर देख रहे हैं। अच्छा उदाहरण स्थापित करो। आप अभी भी निराशा, नाखुशी या चिंता व्यक्त कर सकते हैं, लेकिन ऐसा शांति से करें। + +खुद को शांत रखना आसान नहीं है, लेकिन नेतृत्व प्रदर्शित करने से आपके समुदाय के स्वास्थ्य में सुधार होता है। इंटरनेट आपका धन्यवाद करता है. + +### अपने README को एक संविधान मानें + +आपका README है [निर्देशों के एक संग्रह से कहीं अधिक](../starting-a-project/#एक-रीडमी-लिखना). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं। + +### यात्रा पर ध्यान दें, मंजिल पर नहीं + +कुछ परियोजनाएँ प्रमुख निर्णय लेने के लिए मतदान प्रक्रिया का उपयोग करती हैं। पहली नज़र में समझदार होते हुए भी, मतदान एक-दूसरे की चिंताओं को सुनने और संबोधित करने के बजाय "उत्तर" पाने पर जोर देता है। + +मतदान राजनीतिक हो सकता है, जहां समुदाय के सदस्य एक-दूसरे का पक्ष लेने या एक निश्चित तरीके से मतदान करने के लिए दबाव महसूस करते हैं। चाहे वह कोई भी हो, हर कोई वोट नहीं देता [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) आपके समुदाय में, या वर्तमान उपयोगकर्ताओं को, जिन्हें नहीं पता था कि वोट हो रहा है। + +कभी-कभी, मतदान एक आवश्यक टाईब्रेकर होता है। हालाँकि, जितना आप सक्षम हैं, आम सहमति के बजाय ["आम सहमति की तलाश"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) पर जोर दें। + +सर्वसम्मति प्राप्त करने की प्रक्रिया के तहत, समुदाय के सदस्य प्रमुख चिंताओं पर तब तक चर्चा करते हैं जब तक उन्हें नहीं लगता कि उन्हें पर्याप्त रूप से सुना गया है। जब केवल छोटी-मोटी चिंताएँ बची रहती हैं, तो समुदाय आगे बढ़ता है। "आम सहमति की मांग" यह स्वीकार करती है कि एक समुदाय एक सटीक उत्तर तक पहुंचने में सक्षम नहीं हो सकता है। इसके बजाय, यह सुनने और चर्चा को प्राथमिकता देता है। + + + +भले ही आप वास्तव में सर्वसम्मति प्राप्त करने की प्रक्रिया नहीं अपनाते हों, एक परियोजना अनुरक्षक के रूप में, यह महत्वपूर्ण है कि लोग जानें कि आप सुन रहे हैं। अन्य लोगों को यह महसूस कराना कि उनकी बात सुनी जा रही है, और उनकी चिंताओं को हल करने के लिए प्रतिबद्ध होना, संवेदनशील स्थितियों को दूर करने में काफी मदद करता है। फिर, अपने शब्दों को कार्यों के साथ जारी रखें। + +किसी संकल्प के लिए निर्णय लेने में जल्दबाजी न करें। सुनिश्चित करें कि हर कोई यह महसूस करे कि समाधान की ओर बढ़ने से पहले सभी जानकारी सार्वजनिक कर दी गई है। + +### बातचीत को कार्रवाई पर केंद्रित रखें + +चर्चा महत्वपूर्ण है, लेकिन उत्पादक और अनुत्पादक बातचीत में अंतर है। + +चर्चा को तब तक प्रोत्साहित करें जब तक यह सक्रिय रूप से समाधान की ओर बढ़ रही हो। यदि यह स्पष्ट है कि बातचीत धीमी हो रही है या विषय से भटक रही है, तीखी नोकझोंक व्यक्तिगत होती जा रही है, या लोग छोटी-छोटी बातों को लेकर झगड़ रहे हैं, तो इसे बंद करने का समय आ गया है। + +इन वार्तालापों को जारी रखने की अनुमति देना न केवल मौजूदा मुद्दे के लिए बुरा है, बल्कि आपके समुदाय के स्वास्थ्य के लिए भी बुरा है। यह एक संदेश भेजता है कि इस प्रकार की बातचीत की अनुमति है या इसे प्रोत्साहित भी किया जाता है, और यह लोगों को भविष्य के मुद्दों को उठाने या हल करने से हतोत्साहित कर सकता है। + +आपके द्वारा या दूसरों द्वारा उठाए गए प्रत्येक बिंदु पर, अपने आप से पूछें, _"यह हमें किसी समाधान के करीब कैसे लाता है?"_ + +यदि बातचीत सुलझने लगी है, तो बातचीत पर फिर से ध्यान केंद्रित करने के लिए समूह से पूछें, _"हमें आगे कौन सा कदम उठाना चाहिए?"_ + +यदि बातचीत स्पष्ट रूप से कहीं नहीं जा रही है, कोई स्पष्ट कार्रवाई नहीं की जानी है, या उचित कार्रवाई पहले ही की जा चुकी है, तो मुद्दे को बंद करें और बताएं कि आपने इसे क्यों बंद किया। + + + +### अपनी लड़ाइयाँ बुद्धिमानी से चुनें + +प्रसंग महत्वपूर्ण है. विचार करें कि चर्चा में कौन शामिल है और वे शेष समुदाय का प्रतिनिधित्व कैसे करते हैं। + +क्या समुदाय में हर कोई इस मुद्दे से परेशान है, या इससे जुड़ा भी है? या एक अकेला उपद्रवी है? केवल सक्रिय आवाज़ों पर ही नहीं, बल्कि अपने मूक समुदाय के सदस्यों पर भी विचार करना न भूलें। + +यदि मुद्दा आपके समुदाय की व्यापक आवश्यकताओं का प्रतिनिधित्व नहीं करता है, तो आपको बस कुछ लोगों की चिंताओं को स्वीकार करने की आवश्यकता हो सकती है। यदि यह बिना किसी स्पष्ट समाधान के बार-बार आने वाला मुद्दा है, तो उन्हें विषय पर पिछली चर्चाओं की ओर इंगित करें और थ्रेड बंद कर दें। + +### एक सामुदायिक टाईब्रेकर की पहचान करें + +अच्छे रवैये और स्पष्ट संचार के साथ, अधिकांश कठिन परिस्थितियाँ हल हो सकती हैं। हालाँकि, एक सार्थक बातचीत में भी, कैसे आगे बढ़ना है, इस पर राय में अंतर हो सकता है। इन मामलों में, ऐसे व्यक्ति या लोगों के समूह की पहचान करें जो टाईब्रेकर के रूप में काम कर सकते हैं। + +एक टाईब्रेकर परियोजना का प्राथमिक अनुरक्षक हो सकता है, या यह लोगों का एक छोटा समूह हो सकता है जो मतदान के आधार पर निर्णय लेता है। आदर्श रूप से, आपने गवर्नेंस फ़ाइल का उपयोग करने से पहले उसमें एक टाईब्रेकर और संबंधित प्रक्रिया की पहचान कर ली है। + +आपका टाईब्रेकर अंतिम उपाय होना चाहिए। विभाजनकारी मुद्दे आपके समुदाय के लिए बढ़ने और सीखने का एक अवसर हैं। इन अवसरों को स्वीकार करें और जहां भी संभव हो समाधान की ओर बढ़ने के लिए सहयोगात्मक प्रक्रिया का उपयोग करें। + +## समुदाय खुले स्रोत का ❤️ है + +स्वस्थ, संपन्न समुदाय हर सप्ताह खुले स्रोत में खर्च किए गए हजारों घंटों को ऊर्जा प्रदान करते हैं। कई योगदानकर्ता खुले स्रोत पर काम करने - या काम न करने - का कारण अन्य लोगों को बताते हैं। रचनात्मक रूप से उस शक्ति का उपयोग करना सीखकर, आप किसी को अविस्मरणीय ओपन सोर्स अनुभव प्राप्त करने में मदद करेंगे। diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md new file mode 100644 index 00000000000..cf0d9f21042 --- /dev/null +++ b/_articles/hi/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: hi +title: आपकी आचार संहिता +description: आचार संहिता को अपनाकर और लागू करके स्वस्थ और रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाना। +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## मुझे आचार संहिता की आवश्यकता क्यों है? + +आचार संहिता एक दस्तावेज है जो आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार की अपेक्षाएं स्थापित करता है। आचार संहिता को अपनाने और लागू करने से आपके समुदाय के लिए एक सकारात्मक सामाजिक माहौल बनाने में मदद मिल सकती है। + +आचार संहिता न केवल आपके प्रतिभागियों को, बल्कि स्वयं को भी सुरक्षित रखने में मदद करती है। यदि आप किसी प्रोजेक्ट को बनाए रखते हैं, तो आप पा सकते हैं कि अन्य प्रतिभागियों का अनुत्पादक रवैया आपको समय के साथ अपने काम के बारे में थका हुआ या नाखुश महसूस करा सकता है। + +आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाने के लिए सशक्त बनाती है। सक्रिय रहने से यह संभावना कम हो जाती है कि आप या अन्य लोग अपने प्रोजेक्ट से थक जाएंगे, और जब कोई ऐसा कुछ करता है जिससे आप सहमत नहीं हैं तो आपको कार्रवाई करने में मदद मिलती है। + +## आचार संहिता स्थापित करना + +यथाशीघ्र एक आचार संहिता स्थापित करने का प्रयास करें: आदर्श रूप से, जब आप पहली बार अपना प्रोजेक्ट बनाते हैं। + +आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है: + +* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_ +* आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_ +* यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा +* कोई कैसे उल्लंघन की रिपोर्ट कर सकता है + +जहां भी आप कर सकें, पूर्व कला का उपयोग करें। [योगदानकर्ता अनुबंध](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग कुबेरनेट्स, रेल्स और स्विफ्ट सहित 40,000 से अधिक ओपन सोर्स परियोजनाओं द्वारा किया जाता है। + +The [Django आचार संहिता](https://www.djangoproject.com/conduct/) और यह [नागरिक आचार संहिता](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) आचार संहिता के दो अच्छे उदाहरण भी हैं। + +एक CODE_OF_CONDUCT फ़ाइल अपने प्रोजेक्ट की रूट डायरेक्टरी में फ़ाइल में रखें, और इसे अपने समुदाय से जोड़कर इसे अपने समुदाय के लिए दृश्यमान बनाएं CONTRIBUTING या README फ़ाइल. + +## यह निर्णय लेना कि आप अपनी आचार संहिता को कैसे लागू करेंगे + + + +उल्लंघन होने से **_पहले_** आपको स्पष्ट करना चाहिए कि आपकी आचार संहिता कैसे लागू की जाएगी। ऐसा करने के कई कारण हैं: + +* यह दर्शाता है कि आप जरूरत पड़ने पर कार्रवाई करने को लेकर गंभीर हैं। + +* आपका समुदाय अधिक आश्वस्त महसूस करेगा कि शिकायतों की वास्तव में समीक्षा की जाती है। + +* आप अपने समुदाय को आश्वस्त करेंगे कि समीक्षा प्रक्रिया निष्पक्ष और पारदर्शी है, क्या उन्हें कभी भी उल्लंघन के लिए जांच में पाया जाएगा। + +आपको लोगों को आचार संहिता के उल्लंघन की रिपोर्ट करने का एक निजी तरीका (जैसे ईमेल पता) देना चाहिए और यह बताना चाहिए कि वह रिपोर्ट कौन प्राप्त करता है। यह एक अनुरक्षक, अनुरक्षकों का समूह या आचार संहिता कार्य समूह हो सकता है। + +यह मत भूलिए कि हो सकता है कि कोई व्यक्ति उस व्यक्ति के बारे में उल्लंघन की रिपोर्ट करना चाहता हो जो उन रिपोर्टों को प्राप्त करता है। इस मामले में, उन्हें किसी अन्य को उल्लंघन की रिपोर्ट करने का विकल्प दें। उदाहरण के लिए,@ctb and @mr-c [उनके प्रोजेक्ट पर स्पष्टीकरण दें](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> अपमानजनक, परेशान करने वाले, या अन्यथा अस्वीकार्य व्यवहार के मामलों की रिपोर्ट **khmer-project@idyll.org** पर ईमेल करके की जा सकती है, जो केवल सी. टाइटस ब्राउन और माइकल आर. क्रूसो को जाती है। उनमें से किसी एक से जुड़े मुद्दे की रिपोर्ट करने के लिए कृपया विज्ञान और प्रौद्योगिकी के लिए एक एनएसएफ केंद्र, बीकॉन सेंटर फॉर द स्टडी ऑफ इवोल्यूशन इन एक्शन में विविधता निदेशक **जूडी ब्राउन क्लार्क, पीएच.डी.** को ईमेल करें।* + +प्रेरणा के लिए, Django का [प्रवर्तन मैनुअल](https://www.djangoproject.com/conduct/enforcement-manual/) देखें (हालाँकि, आपके प्रोजेक्ट के आकार के आधार पर, आपको इतनी व्यापक चीज़ की आवश्यकता नहीं हो सकती है). + +## अपनी आचार संहिता लागू करना + +कभी-कभी, आपके सर्वोत्तम प्रयासों के बावजूद, कोई ऐसा कार्य करेगा जो इस संहिता का उल्लंघन करता है। नकारात्मक या हानिकारक व्यवहार सामने आने पर उससे निपटने के कई तरीके हैं। + +### स्थिति के बारे में जानकारी इकट्ठा करें + +समुदाय के प्रत्येक सदस्य की आवाज़ को अपनी आवाज़ के समान महत्वपूर्ण मानें। यदि आपको कोई रिपोर्ट मिलती है कि किसी ने आचार संहिता का उल्लंघन किया है, तो इसे गंभीरता से लें और मामले की जांच करें, भले ही वह उस व्यक्ति के साथ आपके अपने अनुभव से मेल न खाता हो। ऐसा करना आपके समुदाय को संकेत देता है कि आप उनके दृष्टिकोण को महत्व देते हैं और उनके निर्णय पर भरोसा करते हैं। + +विचाराधीन समुदाय का सदस्य बार-बार अपराधी हो सकता है जो लगातार दूसरों को असहज महसूस कराता है, या हो सकता है कि उसने केवल एक बार ही कुछ कहा या किया हो। संदर्भ के आधार पर दोनों ही कार्रवाई करने के आधार हो सकते हैं। + +प्रतिक्रिया देने से पहले, स्वयं को यह समझने का समय दें कि क्या हुआ था। यह बेहतर ढंग से समझने के लिए कि वे कौन हैं और उन्होंने ऐसा व्यवहार क्यों किया होगा, उस व्यक्ति की पिछली टिप्पणियों और बातचीत को पढ़ें। इस व्यक्ति और उनके व्यवहार के बारे में अपने अलावा अन्य दृष्टिकोण इकट्ठा करने का प्रयास करें। + + + +### उचित कार्रवाई करें + +पर्याप्त जानकारी एकत्र करने और संसाधित करने के बाद, आपको यह निर्णय लेना होगा कि क्या करना है। जब आप अपने अगले कदमों पर विचार करें, तो याद रखें कि एक मॉडरेटर के रूप में आपका लक्ष्य एक सुरक्षित, सम्मानजनक और सहयोगात्मक वातावरण को बढ़ावा देना है। न केवल इस बात पर विचार करें कि संबंधित स्थिति से कैसे निपटा जाए, बल्कि यह भी कि आपकी प्रतिक्रिया आपके समुदाय के बाकी व्यवहार और अपेक्षाओं को कैसे प्रभावित करेगी। + +जब कोई आचार संहिता के उल्लंघन की रिपोर्ट करता है, तो इसे संभालना उनका नहीं, आपका काम है। कभी-कभी, रिपोर्टर अपने करियर, प्रतिष्ठा या शारीरिक सुरक्षा को बहुत जोखिम में डालकर जानकारी का खुलासा कर रहा है। उन्हें अपने उत्पीड़क का सामना करने के लिए मजबूर करना रिपोर्टर को समझौतावादी स्थिति में डाल सकता है। आपको संबंधित व्यक्ति के साथ सीधा संवाद संभालना चाहिए, जब तक कि रिपोर्टर स्पष्ट रूप से अन्यथा अनुरोध न करे। + +ऐसे कुछ तरीके हैं जिनसे आप आचार संहिता के उल्लंघन पर प्रतिक्रिया दे सकते हैं: + +* **संबंधित व्यक्ति को सार्वजनिक चेतावनी दें** और बताएं कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला, अधिमानतः उस चैनल में जहां यह हुआ। जहां संभव हो, सार्वजनिक संचार शेष समुदाय को बताता है कि आप आचार संहिता को गंभीरता से लेते हैं। दयालु बनें, लेकिन अपने संचार में दृढ़ रहें। + +* **व्यक्तिगत रूप से उस व्यक्ति तक पहुंचें**यह समझाने के लिए कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला। यदि स्थिति में संवेदनशील व्यक्तिगत जानकारी शामिल है तो आप निजी संचार चैनल का उपयोग करना चाह सकते हैं। यदि आप किसी के साथ निजी तौर पर संवाद करते हैं, तो उन लोगों को सीसी देना एक अच्छा विचार है जिन्होंने सबसे पहले स्थिति की सूचना दी थी, ताकि वे जान सकें कि आपने कार्रवाई की है। सीसी देने से पहले रिपोर्टिंग व्यक्ति से सहमति मांगें। + +कभी-कभी, किसी समाधान तक नहीं पहुंचा जा सकता. सामना किए जाने पर संबंधित व्यक्ति आक्रामक या शत्रुतापूर्ण हो सकता है या अपना व्यवहार नहीं बदलता है। इस स्थिति में, आप कड़ी कार्रवाई करने पर विचार कर सकते हैं। उदाहरण के लिए: + +* **परियोजना के किसी भी पहलू में भाग लेने पर अस्थायी प्रतिबंध के माध्यम से लागू, परियोजना से संबंधित व्यक्ति को निलंबित करें** + +* **प्रोजेक्ट से व्यक्ति को स्थायी रूप से प्रतिबंधित** करें + +सदस्यों पर प्रतिबंध लगाना हल्के में नहीं लिया जाना चाहिए और यह दृष्टिकोण में स्थायी और अपूरणीय अंतर का प्रतिनिधित्व करता है। आपको ये उपाय केवल तभी करना चाहिए जब यह स्पष्ट हो कि किसी समाधान पर नहीं पहुंचा जा सकता। + +## एक अनुरक्षक के रूप में आपकी जिम्मेदारियाँ + +आचार संहिता कोई ऐसा कानून नहीं है जिसे मनमाने ढंग से लागू किया जाए। आप आचार संहिता के प्रवर्तक हैं और आचार संहिता द्वारा स्थापित नियमों का पालन करना आपकी जिम्मेदारी है। + +एक अनुरक्षक के रूप में आप अपने समुदाय के लिए दिशानिर्देश स्थापित करते हैं और उन दिशानिर्देशों को अपनी आचार संहिता में निर्धारित नियमों के अनुसार लागू करते हैं। इसका अर्थ है आचार संहिता उल्लंघन की किसी भी रिपोर्ट को गंभीरता से लेना। रिपोर्टर को उनकी शिकायत की गहन और निष्पक्ष समीक्षा करनी चाहिए। यदि आप यह निर्धारित करते हैं कि जिस व्यवहार की उन्होंने रिपोर्ट की है वह उल्लंघन नहीं है, तो उन्हें स्पष्ट रूप से बताएं और बताएं कि आप इस पर कार्रवाई क्यों नहीं करने जा रहे हैं। वे इसके साथ क्या करते हैं यह उन पर निर्भर है: उस व्यवहार को सहन करें जिससे उन्हें कोई समस्या थी, या समुदाय में भाग लेना बंद कर दें। + +व्यवहार की एक रिपोर्ट जो तकनीकी रूप से आचार संहिता का उल्लंघन नहीं करती है, फिर भी यह संकेत दे सकती है कि आपके समुदाय में कोई समस्या है, और आपको इस संभावित समस्या की जांच करनी चाहिए और तदनुसार कार्य करना चाहिए। इसमें स्वीकार्य व्यवहार को स्पष्ट करने के लिए अपनी आचार संहिता को संशोधित करना और/या उस व्यक्ति से बात करना शामिल हो सकता है जिसके व्यवहार की रिपोर्ट की गई थी और उन्हें यह बताना कि हालांकि उन्होंने आचार संहिता का उल्लंघन नहीं किया है, वे जो अपेक्षित है उससे किनारा कर रहे हैं और निश्चित कर रहे हैं। प्रतिभागी असहज महसूस करते हैं। + +अंत में, एक अनुरक्षक के रूप में, आप स्वीकार्य व्यवहार के लिए मानक निर्धारित और लागू करते हैं। आपके पास परियोजना के सामुदायिक मूल्यों को आकार देने की क्षमता है, और प्रतिभागी आपसे उन मूल्यों को निष्पक्ष और समान तरीके से लागू करने की उम्मीद करते हैं। + +## उस व्यवहार को प्रोत्साहित करें जो आप दुनिया में देखना चाहते हैं 🌎 + +जब कोई परियोजना शत्रुतापूर्ण या अप्रिय लगती है, भले ही वह सिर्फ एक व्यक्ति हो जिसका व्यवहार दूसरों द्वारा सहन किया जाता है, तो आप कई और योगदानकर्ताओं को खोने का जोखिम उठाते हैं, जिनमें से कुछ से आप कभी भी नहीं मिल सकते हैं। आचार संहिता को अपनाना या लागू करना हमेशा आसान नहीं होता है, लेकिन स्वागत योग्य माहौल को बढ़ावा देने से आपके समुदाय को बढ़ने में मदद मिलेगी। diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md new file mode 100644 index 00000000000..94d36a15e3f --- /dev/null +++ b/_articles/hi/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: hi +title: अपने प्रोजेक्ट के लिए उपयोगकर्ता ढूँढना +description: अपने ओपन सोर्स प्रोजेक्ट को खुश उपयोगकर्ताओं के हाथों में पहुंचाकर उसे बढ़ने में मदद करें। +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## बातों का प्रसार + +ऐसा कोई नियम नहीं है जो कहता हो कि लॉन्च करते समय आपको एक ओपन सोर्स प्रोजेक्ट का प्रचार करना होगा। ओपन सोर्स में काम करने के कई संतोषजनक कारण हैं जिनका लोकप्रियता से कोई लेना-देना नहीं है। यह आशा करने के बजाय कि अन्य लोग आपके ओपन सोर्स प्रोजेक्ट को ढूंढेंगे और उसका उपयोग करेंगे, आपको अपनी कड़ी मेहनत के बारे में प्रचार करना होगा! + +## अपने संदेश का पता लगाएं + +इससे पहले कि आप अपने प्रोजेक्ट को बढ़ावा देने का वास्तविक काम शुरू करें, आपको यह समझाने में सक्षम होना चाहिए कि यह क्या करता है और यह क्यों मायने रखता है। + +आपके प्रोजेक्ट को क्या अलग या दिलचस्प बनाता है? आपने इसे क्यों बनाया? इन प्रश्नों का स्वयं उत्तर देने से आपको अपने प्रोजेक्ट के महत्व के बारे में बताने में मदद मिलेगी। + +याद रखें कि लोग उपयोगकर्ता के रूप में शामिल होते हैं, और अंततः योगदानकर्ता बन जाते हैं, क्योंकि आपका प्रोजेक्ट उनके लिए एक समस्या का समाधान करता है। जब आप अपने प्रोजेक्ट के संदेश और मूल्य के बारे में सोचते हैं, तो उन्हें इस नजरिए से देखने का प्रयास करें कि उपयोगकर्ता और योगदानकर्ता क्या चाहते हैं। + +उदाहरण के लिए, @robb अपने प्रोजेक्ट को स्पष्ट रूप से बताने के लिए कोड उदाहरणों का उपयोग करता है, [Cartography](https://github.com/robb/Cartography), उपयोगी है: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +मैसेजिंग के बारे में गहराई से जानने के लिए मोज़िला देखें ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) उपयोगकर्ता व्यक्तित्व विकसित करने के लिए व्यायाम। + +## अपने प्रोजेक्ट को ढूंढने और उसका अनुसरण करने में लोगों की सहायता करें + + + +लोगों को एक ही नामस्थान की ओर इंगित करके अपना प्रोजेक्ट ढूंढने और याद रखने में सहायता करें। + +**अपने काम को बढ़ावा देने के लिए एक स्पष्ट हैंडल रखें।** एक ट्विटर हैंडल, GitHub URL, या IRC चैनल लोगों को आपके प्रोजेक्ट की ओर इंगित करने का एक आसान तरीका है। ये आउटलेट आपके प्रोजेक्ट के बढ़ते समुदाय को एकत्रित होने की जगह भी देते हैं। + +यदि आप अभी तक अपने प्रोजेक्ट के लिए आउटलेट स्थापित नहीं करना चाहते हैं, तो अपने हर काम में अपने स्वयं के ट्विटर या GitHub हैंडल को बढ़ावा दें। आपके ट्विटर या GitHub हैंडल को बढ़ावा देने से लोगों को पता चलेगा कि आपसे कैसे संपर्क किया जाए या आपके काम का अनुसरण किया जाए। यदि आप किसी बैठक या कार्यक्रम में बोलते हैं, तो सुनिश्चित करें कि आपकी संपर्क जानकारी आपके बायो या स्लाइड में शामिल है। + + + +**अपने प्रोजेक्ट के लिए एक वेबसाइट बनाने पर विचार करें।** एक वेबसाइट आपके प्रोजेक्ट को मित्रवत और नेविगेट करने में आसान बनाती है, खासकर जब इसे स्पष्ट दस्तावेज़ीकरण और ट्यूटोरियल के साथ जोड़ा जाता है। एक वेबसाइट होने से यह भी पता चलता है कि आपका प्रोजेक्ट सक्रिय है जिससे आपके दर्शकों को इसका उपयोग करने में अधिक सहजता महसूस होगी। लोगों को अपने प्रोजेक्ट का उपयोग करने के तरीके के बारे में विचार देने के लिए उदाहरण प्रदान करें। + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django के सह-निर्माता ने कहा कि एक वेबसाइट _"प्रारंभिक दिनों में Django के साथ हमने जो किया वह अब तक का सबसे अच्छा काम था"_. + +यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, तो आप इसका उपयोग कर सकते हैं [GitHub Pages](https://pages.github.com/) आसानी से एक वेबसाइट बनाने के लिए. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), और [Middleman](https://middlemanapp.com/) हैं [a few examples](https://github.com/showcases/github-pages-examples) उत्कृष्ट, व्यापक वेबसाइटें। + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +अब जब भी आपके पास अपने प्रोजेक्ट के लिए एक संदेश है, और लोगों के लिए आपके प्रोजेक्ट को आकर्षित करने का एक आसान तरीका है, तो वहां आएं और अपने दर्शकों से बात करें! + +## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑनलाइन) + +ऑनलाइन आउटरीच बात को तेजी से साझा करने और फैलाने का एक शानदार तरीका है। ऑनलाइन चैनलों का उपयोग करके, आपके पास बहुत व्यापक दर्शकों तक पहुंचने की क्षमता है। + +अपने दर्शकों तक पहुंचने के लिए मौजूदा ऑनलाइन समुदायों और प्लेटफार्मों का लाभ उठाएं। यदि आपका ओपन सोर्स प्रोजेक्ट एक सॉफ्टवेयर प्रोजेक्ट है, तो आप संभवतः अपने दर्शकों को ढूंढ सकते हैं [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), या [Quora](https://www.quora.com/). वे चैनल ढूंढें जहां आपको लगता है कि लोगों को आपके काम से सबसे अधिक लाभ होगा या वे आपके काम के बारे में उत्साहित होंगे। + + + +देखें कि क्या आप अपने प्रोजेक्ट को प्रासंगिक तरीकों से साझा करने के तरीके ढूंढ सकते हैं: + +* **प्रासंगिक ओपन सोर्स प्रोजेक्ट्स और समुदायों को जानें।** कभी-कभी, आपको सीधे अपने प्रोजेक्ट का प्रचार करने की ज़रूरत नहीं होती है। यदि आपका प्रोजेक्ट पायथन का उपयोग करने वाले डेटा वैज्ञानिकों के लिए एकदम सही है, तो पायथन डेटा विज्ञान समुदाय को जानें। जैसे-जैसे लोग आपको जानने लगेंगे, आपके काम के बारे में बात करने और साझा करने के स्वाभाविक अवसर पैदा होंगे। +* **उन लोगों को ढूंढें जो उस समस्या का अनुभव कर रहे हैं जिसे आपका प्रोजेक्ट हल करता है।** उन लोगों के लिए संबंधित मंचों के माध्यम से खोजें जो आपके प्रोजेक्ट के लक्षित दर्शकों में आते हैं। उनके प्रश्न का उत्तर दें और समाधान के रूप में अपनी परियोजना का सुझाव देने के लिए, जब उचित हो, एक चतुराईपूर्ण तरीका खोजें। +* **प्रतिक्रिया के लिए पूछें।** ऐसे दर्शकों के सामने अपना और अपने काम का परिचय दें जिन्हें यह प्रासंगिक और दिलचस्प लगे। इस बारे में स्पष्ट रहें कि आपको क्या लगता है कि आपके प्रोजेक्ट से किसे लाभ होगा। वाक्य को पूरा करने का प्रयास करें: _"मुझे लगता है कि मेरा प्रोजेक्ट वास्तव में एक्स की मदद करेगा, जो Y_ करने की कोशिश कर रहे हैं"। केवल अपने काम का प्रचार करने के बजाय दूसरों की प्रतिक्रिया सुनें और उसका जवाब दें। + +सामान्यतया, बदले में चीज़ें मांगने से पहले दूसरों की मदद करने पर ध्यान केंद्रित करें। क्योंकि कोई भी किसी प्रोजेक्ट को आसानी से ऑनलाइन प्रमोट कर सकता है, इसलिए बहुत शोर होगा। भीड़ से अलग दिखने के लिए, लोगों को यह संदर्भ दें कि आप कौन हैं, न कि केवल वह जो आप चाहते हैं। + +यदि कोई आपकी आरंभिक पहुंच पर ध्यान नहीं देता है या प्रतिक्रिया नहीं देता है, तो निराश न हों! अधिकांश प्रोजेक्ट लॉन्च एक पुनरावृत्तीय प्रक्रिया है जिसमें महीनों या वर्षों का समय लग सकता है। यदि आपको पहली बार कोई प्रतिक्रिया नहीं मिलती है, तो एक अलग रणनीति आज़माएं, या पहले दूसरों के काम में मूल्य जोड़ने के तरीकों की तलाश करें। अपने प्रोजेक्ट को प्रचारित करने और लॉन्च करने में समय और समर्पण लगता है। + +## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑफ़लाइन) + +![सार्वजनिक रूप से बोलना](/assets/images/finding-users/public_speaking.jpg) + +ऑफ़लाइन कार्यक्रम दर्शकों के बीच नई परियोजनाओं को बढ़ावा देने का एक लोकप्रिय तरीका है। वे व्यस्त दर्शकों तक पहुंचने और गहरे मानवीय संबंध बनाने का एक शानदार तरीका हैं, खासकर यदि आप डेवलपर्स तक पहुंचने में रुचि रखते हैं। + +यदि आप [सार्वजनिक भाषण में नए](https://peaking.io/) हैं, तो एक स्थानीय बैठक ढूंढ़कर शुरुआत करें जो आपके प्रोजेक्ट की भाषा या पारिस्थितिकी तंत्र से संबंधित हो। + + + +यदि आपने पहले कभी किसी कार्यक्रम में बात नहीं की है, तो घबराहट महसूस होना बिल्कुल सामान्य है! याद रखें कि आपके दर्शक वहां हैं क्योंकि वे वास्तव में आपके काम के बारे में सुनना चाहते हैं। + +जब आप अपनी बात लिखते हैं, तो इस बात पर ध्यान केंद्रित करें कि आपके दर्शकों को क्या दिलचस्प लगेगा और उन्हें क्या लाभ मिलेगा। अपनी भाषा मित्रतापूर्ण एवं सुगम्य रखें। मुस्कुराएं, सांस लें और आनंद लें। + + + +जब आप तैयार महसूस करें, तो अपने प्रोजेक्ट को बढ़ावा देने के लिए एक सम्मेलन में बोलने पर विचार करें। सम्मेलन आपको अधिक लोगों तक पहुँचने में मदद कर सकते हैं, कभी-कभी दुनिया भर से। + +ऐसे सम्मेलनों की तलाश करें जो आपकी भाषा या पारिस्थितिकी तंत्र के लिए विशिष्ट हों। अपना भाषण प्रस्तुत करने से पहले, उपस्थित लोगों के लिए अपनी बात तैयार करने के लिए सम्मेलन पर शोध करें और सम्मेलन में बोलने के लिए स्वीकार किए जाने की संभावना बढ़ाएं। आप अक्सर सम्मेलन के वक्ताओं को देखकर अपने दर्शकों के बारे में अंदाजा लगा सकते हैं। + + + +## प्रतिष्ठा बनायें + +ऊपर उल्लिखित रणनीतियों के अलावा, लोगों को अपने प्रोजेक्ट में साझा करने और योगदान करने के लिए आमंत्रित करने का सबसे अच्छा तरीका उनकी परियोजनाओं को साझा करना और योगदान देना है। + +नए लोगों की मदद करना, संसाधन साझा करना और दूसरों की परियोजनाओं में विचारशील योगदान देना आपको सकारात्मक प्रतिष्ठा बनाने में मदद करेगा। ओपन सोर्स समुदाय में एक सक्रिय सदस्य होने से लोगों को आपके काम के संदर्भ में मदद मिलेगी और आपके प्रोजेक्ट पर ध्यान देने और साझा करने की अधिक संभावना होगी। अन्य ओपन सोर्स परियोजनाओं के साथ संबंध विकसित करने से आधिकारिक साझेदारी भी हो सकती है। + + + +अपनी प्रतिष्ठा बनाना शुरू करने के लिए कभी भी बहुत जल्दी या बहुत देर नहीं होती है। भले ही आपने अपना खुद का प्रोजेक्ट पहले ही लॉन्च कर दिया हो, दूसरों की मदद करने के तरीकों की तलाश जारी रखें। + +दर्शक वर्ग बनाने का कोई रातोरात समाधान नहीं है। दूसरों का विश्वास और सम्मान हासिल करने में समय लगता है, और आपकी प्रतिष्ठा बनाना कभी ख़त्म नहीं होता। + +## बने रहिए! + +लोगों को आपके ओपन सोर्स प्रोजेक्ट पर ध्यान देने में काफी समय लग सकता है। वह ठीक है! आज की कुछ सबसे लोकप्रिय परियोजनाओं को गतिविधि के उच्च स्तर तक पहुंचने में वर्षों लग गए। यह आशा करने के बजाय कि आपका प्रोजेक्ट अनायास लोकप्रियता हासिल कर लेगा, संबंध बनाने पर ध्यान केंद्रित करें। धैर्य रखें और अपना काम उन लोगों के साथ साझा करते रहें जो इसकी सराहना करते हैं। diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md new file mode 100644 index 00000000000..7cada6b50b1 --- /dev/null +++ b/_articles/hi/getting-paid.md @@ -0,0 +1,180 @@ +--- +lang: hi +title: ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना +description: अपने समय या अपने प्रोजेक्ट के लिए वित्तीय सहायता प्राप्त करके अपने काम को खुले स्रोत में बनाए रखें। +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## कुछ लोग वित्तीय सहायता क्यों चाहते हैं? + +ओपन सोर्स का अधिकांश कार्य स्वैच्छिक है। उदाहरण के लिए, हो सकता है कि किसी को अपने द्वारा उपयोग किए जा रहे किसी प्रोजेक्ट में बग का सामना करना पड़े और वह त्वरित समाधान सबमिट कर दे, या हो सकता है कि वे अपने खाली समय में किसी ओपन सोर्स प्रोजेक्ट के साथ छेड़छाड़ करने का आनंद लें। + + + +ऐसे कई कारण हैं जिनकी वजह से कोई व्यक्ति अपने ओपन सोर्स कार्य के लिए भुगतान नहीं करना चाहेगा। + +* **उनके पास पहले से ही एक पूर्णकालिक नौकरी हो सकती है जो उन्हें पसंद है,** जो उन्हें अपने खाली समय में ओपन सोर्स में योगदान करने में सक्षम बनाती है। +* **वे ओपन सोर्स को एक शौक** या रचनात्मक पलायन के रूप में सोचने का आनंद लेते हैं और अपनी परियोजनाओं पर काम करने के लिए वित्तीय रूप से बाध्य महसूस नहीं करना चाहते हैं। +* **उन्हें ओपन सोर्स में योगदान करने से अन्य लाभ मिलते हैं,** जैसे कि उनकी प्रतिष्ठा या पोर्टफोलियो बनाना, एक नया कौशल सीखना, या किसी समुदाय के करीब महसूस करना। + + + +दूसरों के लिए, विशेष रूप से जब योगदान जारी है या महत्वपूर्ण समय की आवश्यकता है, तो ओपन सोर्स में योगदान करने के लिए भुगतान प्राप्त करना ही एकमात्र तरीका है जिससे वे भाग ले सकते हैं, या तो क्योंकि परियोजना को इसकी आवश्यकता है, या व्यक्तिगत कारणों से। + +लोकप्रिय परियोजनाओं को बनाए रखना एक महत्वपूर्ण जिम्मेदारी हो सकती है, जिसमें प्रति माह कुछ घंटों के बजाय प्रति सप्ताह 10 या 20 घंटे लगते हैं। + + + +भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय। + + + +यदि आप वित्तीय सहायता की तलाश में हैं, तो विचार करने के लिए दो रास्ते हैं। आप एक योगदानकर्ता के रूप में अपने समय का वित्तपोषण कर सकते हैं, या आप परियोजना के लिए संगठनात्मक वित्तपोषण पा सकते हैं। + +## अपने समय का वित्तपोषण करना + +आज, कई लोगों को ओपन सोर्स पर अंशकालिक या पूर्णकालिक काम करने के लिए भुगतान मिलता है। अपने समय के लिए भुगतान पाने का सबसे आम तरीका अपने नियोक्ता से बात करना है। + +यदि आपका नियोक्ता वास्तव में परियोजना का उपयोग करता है, तो ओपन सोर्स कार्य के लिए मामला बनाना आसान है, लेकिन अपनी पिच के साथ रचनात्मक बनें। हो सकता है कि आपका नियोक्ता प्रोजेक्ट का उपयोग नहीं करता हो, लेकिन वे पायथन का उपयोग करते हैं, और एक लोकप्रिय पायथन प्रोजेक्ट को बनाए रखने से नए पायथन डेवलपर्स को आकर्षित करने में मदद मिलती है। शायद यह आपके नियोक्ता को सामान्य रूप से अधिक डेवलपर-अनुकूल बनाता है। + +यदि आपके पास कोई मौजूदा ओपन सोर्स प्रोजेक्ट नहीं है जिस पर आप काम करना चाहेंगे, बल्कि चाहेंगे कि आपका वर्तमान कार्य आउटपुट ओपन सोर्स हो, तो अपने नियोक्ता के लिए उनके कुछ आंतरिक सॉफ़्टवेयर को ओपन सोर्स करने का मामला बनाएं। + +कई कंपनियां अपना ब्रांड बनाने और गुणवत्तापूर्ण प्रतिभाओं की भर्ती के लिए ओपन सोर्स प्रोग्राम विकसित कर रही हैं। + +उदाहरण के लिए, @hueniverse ने पाया कि औचित्य सिद्ध करने के लिए वित्तीय कारण थे [ओपन सोर्स में वॉलमार्ट का निवेश](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). और @jamesgpearce ने पाया वह फेसबुक का ओपन सोर्स प्रोग्राम है [make a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) +भर्ती में: + +> यह हमारी हैकर संस्कृति और हमारे संगठन को कैसे समझा जाता है, के साथ निकटता से जुड़ा हुआ है। हमने अपने कर्मचारियों से पूछा, "क्या आप फेसबुक के ओपन सोर्स सॉफ़्टवेयर प्रोग्राम के बारे में जानते थे?" दो-तिहाई ने कहा "हाँ"। एक-आधे ने कहा कि कार्यक्रम ने हमारे लिए काम करने के उनके निर्णय में सकारात्मक योगदान दिया। ये सीमांत संख्याएं नहीं हैं, और मुझे आशा है कि यह प्रवृत्ति जारी रहेगी। + +यदि आपकी कंपनी इस मार्ग पर चलती है, तो समुदाय और कॉर्पोरेट गतिविधि के बीच की सीमाओं को स्पष्ट रखना महत्वपूर्ण है। अंततः, ओपन सोर्स दुनिया भर के लोगों के योगदान के माध्यम से खुद को कायम रखता है, और यह किसी एक कंपनी या स्थान से बड़ा है। + + + +यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए: + +* कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/) या [PayPal](https://paypal.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं। +* [Zalando](https://opensource.zalando.com) ने [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) उनके कर्मचारियों के लिए प्रकाशन किया। + +ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है। + +अपनी व्यक्तिगत परिस्थितियों के आधार पर, आप अपने ओपन सोर्स कार्य के वित्तपोषण के लिए स्वतंत्र रूप से धन जुटाने का प्रयास कर सकते हैं। उदाहरण के लिए: + +* @Homebrew (और [many other maintainers and organizations](https://github.com/sponsors/community)) [GitHub Sponsors](https://github.com/sponsors) के माध्यम से उनके काम को वित्तपोषित करें +* @gaearon उसके काम को वित्त पोषित किया [Redux](https://github.com/reactjs/redux) पर, और [Patreon crowdfunding campaign](https://redux.js.org/) के जरिए +* @andrewgodwin स्कीमा माइग्रेशन पर वित्त पोषित कार्य [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +अंत में, कभी-कभी ओपन सोर्स प्रोजेक्ट उन मुद्दों पर इनाम देते हैं जिनमें आप मदद करने पर विचार कर सकते हैं। + +* @ConnorChristie भुगतान पाने में सक्षम था [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). +* @mamiM ने इसके बाद @MetaMask का जापानी अनुवाद किया [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). + +## अपने प्रोजेक्ट के लिए फंडिंग ढूँढना + +व्यक्तिगत योगदानकर्ताओं के लिए व्यवस्था से परे, कभी-कभी परियोजनाएं चल रहे काम को निधि देने के लिए कंपनियों, व्यक्तियों या अन्य लोगों से धन जुटाती हैं। + +संगठनात्मक फंडिंग वर्तमान योगदानकर्ताओं को भुगतान करने, परियोजना चलाने की लागत (जैसे होस्टिंग शुल्क) को कवर करने, या नई सुविधाओं या विचारों में निवेश करने में जा सकती है। + +जैसे-जैसे ओपन सोर्स की लोकप्रियता बढ़ती है, परियोजनाओं के लिए फंडिंग ढूंढना अभी भी प्रयोगात्मक है, लेकिन कुछ सामान्य विकल्प उपलब्ध हैं। + +### क्राउडफंडिंग अभियानों या प्रायोजन के माध्यम से अपने काम के लिए धन जुटाएं + +यदि आपके पास पहले से ही एक मजबूत दर्शक वर्ग या प्रतिष्ठा है, या आपका प्रोजेक्ट बहुत लोकप्रिय है, तो प्रायोजन ढूँढना अच्छा काम करता है। +प्रायोजित परियोजनाओं के कुछ उदाहरणों में शामिल हैं: + +* **[webpack](https://github.com/webpack)** कंपनियों और व्यक्तियों से धन जुटाता है [through OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** एक गैर-लाभकारी संगठन जो काम के लिए भुगतान करता है [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects + +### एक राजस्व धारा बनाएँ + +आपके प्रोजेक्ट के आधार पर, आप व्यावसायिक सहायता, होस्ट किए गए विकल्पों या अतिरिक्त सुविधाओं के लिए शुल्क लेने में सक्षम हो सकते हैं। कुछ उदाहरणों में शामिल हैं: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** अतिरिक्त सहायता के लिए सशुल्क संस्करण प्रदान करता है +* **[Travis CI](https://github.com/travis-ci)** अपने उत्पाद के सशुल्क संस्करण प्रदान करता है +* **[Ghost](https://github.com/TryGhost/Ghost)** सशुल्क प्रबंधित सेवा वाला एक गैर-लाभकारी संगठन है + +कुछ लोकप्रिय परियोजनाएँ, जैसे [npm](https://github.com/npm/cli) और [Docker](https://github.com/docker/docker), यहां तक ​​कि अपने व्यवसाय के विकास को समर्थन देने के लिए उद्यम पूंजी भी जुटाते हैं। + +### अनुदान निधि के लिए आवेदन करें + +कुछ सॉफ़्टवेयर फ़ाउंडेशन और कंपनियाँ ओपन सोर्स कार्य के लिए अनुदान प्रदान करती हैं। कभी-कभी, परियोजना के लिए कानूनी इकाई स्थापित किए बिना व्यक्तियों को अनुदान का भुगतान किया जा सकता है। + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** को [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) से अनुदान प्राप्त हुआ। +* **[OpenMRS](https://github.com/openmrs)** कार्य द्वारा वित्त पोषित किया गया था [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** को [Sloan Foundation](https://sloan.org/programs/digital-technology) से अनुदान प्राप्त हुआ। +* **[Python Software Foundation](https://www.python.org/psf/grants/)** पायथन से संबंधित कार्यों के लिए अनुदान प्रदान करता है। + +अधिक विस्तृत विकल्पों और केस अध्ययन के लिए, @nayafia [एक गाइड लिखा](https://github.com/nayafia/lemonade-stand) +ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना। विभिन्न प्रकार की फंडिंग के लिए अलग-अलग कौशल की आवश्यकता होती है, इसलिए यह पता लगाने के लिए अपनी ताकत पर विचार करें कि कौन सा विकल्प आपके लिए सबसे अच्छा काम करता है। + +## वित्तीय सहायता के लिए मामला बनाना + +चाहे आपका प्रोजेक्ट एक नया विचार हो, या वर्षों से चला आ रहा हो, आपको अपने लक्षित फंडर की पहचान करने और एक सम्मोहक मामला बनाने में महत्वपूर्ण विचार करने की उम्मीद करनी चाहिए। + +चाहे आप अपने समय के लिए भुगतान करना चाह रहे हों, या किसी परियोजना के लिए धन जुटाना चाह रहे हों, आपको निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होना चाहिए। + +### प्रभाव + +यह प्रोजेक्ट उपयोगी क्यों है? आपके उपयोगकर्ता, या संभावित उपयोगकर्ता, इसे इतना पसंद क्यों करते हैं? पांच साल में यह कहां होगा? + +### संकर्षण + +सबूत इकट्ठा करने की कोशिश करें कि आपका प्रोजेक्ट मायने रखता है, चाहे वह मेट्रिक्स, उपाख्यान या प्रशंसापत्र हो। क्या अभी कोई कंपनी या उल्लेखनीय लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं? यदि नहीं, तो क्या किसी प्रमुख व्यक्ति ने इसका समर्थन किया है? + +### फंड देने वाले के लिए मूल्य + +फंडर्स, चाहे आपका नियोक्ता हो या अनुदान देने वाला फाउंडेशन, अक्सर अवसरों के साथ संपर्क किया जाता है। उन्हें किसी अन्य अवसर की अपेक्षा आपके प्रोजेक्ट का समर्थन क्यों करना चाहिए? वे व्यक्तिगत रूप से कैसे लाभान्वित होते हैं? + +### धन का उपयोग + +प्रस्तावित फंडिंग से आप वास्तव में क्या हासिल करेंगे? वेतन देने के बजाय परियोजना की उपलब्धियों या परिणामों पर ध्यान दें। + +### आपको धनराशि कैसे प्राप्त होगी + +क्या फंडर को संवितरण से संबंधित कोई आवश्यकता है? उदाहरण के लिए, आपको एक गैर-लाभकारी संस्था होने या एक गैर-लाभकारी वित्तीय प्रायोजक होने की आवश्यकता हो सकती है। या शायद धनराशि किसी संगठन के बजाय किसी व्यक्तिगत ठेकेदार को दी जानी चाहिए। ये आवश्यकताएं फंडर्स के बीच अलग-अलग होती हैं, इसलिए पहले से ही अपना शोध करना सुनिश्चित करें। + + + +## प्रयोग करो और हार मत मानो + +पैसा जुटाना आसान नहीं है, चाहे आप एक ओपन सोर्स प्रोजेक्ट हों, एक गैर-लाभकारी संस्था हों, या एक सॉफ्टवेयर स्टार्टअप हों, और ज्यादातर मामलों में आपको रचनात्मक होने की आवश्यकता होती है। यह पहचानना कि आप भुगतान कैसे प्राप्त करना चाहते हैं, अपना शोध करना, और अपने आप को अपने फंडर के स्थान पर रखना आपको फंडिंग के लिए एक ठोस मामला बनाने में मदद करेगा। diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md new file mode 100644 index 00000000000..b1b0c714789 --- /dev/null +++ b/_articles/hi/how-to-contribute.md @@ -0,0 +1,520 @@ +--- +lang: hi +title: ओपन सोर्स में कैसे योगदान करें +description: क्या आप ओपन सोर्स में योगदान देना चाहते हैं? पहली बार और अनुभवी लोगों के लिए ओपन सोर्स योगदान करने के लिए एक मार्गदर्शिका। +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Why contribute to open source? + + + +ओपन सोर्स में योगदान करना किसी भी ऐसे कौशल में सीखने, सिखाने और अनुभव बनाने का एक फायदेमंद तरीका हो सकता है जिसकी आप कल्पना कर सकते हैं। + +लोग ओपन सोर्स में योगदान क्यों देते हैं? बहुत सारे कारण! + +### जिस सॉफ़्टवेयर पर आप भरोसा करते हैं उसे सुधारें + +बहुत से ओपन सोर्स योगदानकर्ता उस सॉफ़्टवेयर के उपयोगकर्ता बनकर शुरुआत करते हैं जिसमें वे योगदान करते हैं। जब आप अपने द्वारा उपयोग किए जाने वाले ओपन सोर्स सॉफ़्टवेयर में कोई बग पाते हैं, तो आप यह देखने के लिए स्रोत को देखना चाहेंगे कि क्या आप इसे स्वयं ठीक कर सकते हैं। यदि ऐसा मामला है, तो पैच बैक में योगदान करना यह सुनिश्चित करने का सबसे अच्छा तरीका है कि आपके मित्र (और जब आप अगली रिलीज़ के लिए अपडेट करते हैं तो आप स्वयं) इससे लाभ उठा सकेंगे। + +### मौजूदा कौशल में सुधार करें + +चाहे वह कोडिंग हो, यूजर इंटरफ़ेस डिज़ाइन हो, ग्राफ़िक डिज़ाइन हो, लेखन हो, या आयोजन हो, यदि आप अभ्यास की तलाश में हैं, तो ओपन सोर्स प्रोजेक्ट पर आपके लिए एक कार्य है। + +### ऐसे लोगों से मिलें जो समान चीज़ों में रुचि रखते हैं + +गर्मजोशी से स्वागत करने वाले समुदायों के साथ ओपन सोर्स परियोजनाएं लोगों को वर्षों तक वापस लाती हैं। बहुत से लोग खुले स्रोत में अपनी भागीदारी के माध्यम से आजीवन मित्रता बनाते हैं, चाहे वह सम्मेलनों में एक-दूसरे से मिलना हो या बरिटो के बारे में देर रात तक ऑनलाइन चैट करना हो। + +### मार्गदर्शक खोजें और दूसरों को सिखाएं + +किसी साझा प्रोजेक्ट पर दूसरों के साथ काम करने का मतलब है कि आपको यह बताना होगा कि आप काम कैसे करते हैं, साथ ही अन्य लोगों से मदद भी मांगनी होगी। सीखने और सिखाने के कार्य इसमें शामिल सभी लोगों के लिए एक संतुष्टिदायक गतिविधि हो सकते हैं। + +### सार्वजनिक कलाकृतियों का निर्माण करें जो आपको प्रतिष्ठा (और करियर) बढ़ाने में मदद करें + +परिभाषा के अनुसार, आपके सभी ओपन सोर्स कार्य सार्वजनिक हैं, जिसका अर्थ है कि आप जो भी कर सकते हैं उसे प्रदर्शित करने के लिए आपको कहीं भी ले जाने के लिए निःशुल्क उदाहरण मिलते हैं। + +### लोगों के कौशल सीखें + +ओपन सोर्स नेतृत्व और प्रबंधन कौशल का अभ्यास करने के अवसर प्रदान करता है, जैसे संघर्षों को हल करना, लोगों की टीमों को संगठित करना और काम को प्राथमिकता देना। + +### परिवर्तन करने में सक्षम होना सशक्त है, यहां तक कि छोटे परिवर्तन भी + +ओपन सोर्स में भाग लेने का आनंद लेने के लिए आपको आजीवन योगदानकर्ता बनने की आवश्यकता नहीं है। क्या आपने कभी किसी वेबसाइट पर कोई टाइपो त्रुटि देखी है और सोचा है कि कोई इसे ठीक कर देगा? किसी ओपन सोर्स प्रोजेक्ट पर, आप बस यही कर सकते हैं। ओपन सोर्स लोगों को उनके जीवन और वे दुनिया का अनुभव कैसे करते हैं, इस पर एजेंसी महसूस करने में मदद करता है, और यह अपने आप में संतुष्टिदायक है। + +## योगदान देने का क्या मतलब है + +यदि आप एक नए ओपन सोर्स योगदानकर्ता हैं, तो प्रक्रिया डराने वाली हो सकती है। आपको सही प्रोजेक्ट कैसे मिलता है? यदि आप नहीं जानते कि कोडिंग कैसे की जाती है तो क्या होगा? क्या हो यदि कुछ गलत हो जाए? + +कोइ चिंता नहीं! किसी ओपन सोर्स प्रोजेक्ट में शामिल होने के सभी प्रकार के तरीके हैं, और कुछ युक्तियाँ आपको अपने अनुभव से अधिकतम लाभ उठाने में मदद करेंगी। + +### आपको कोड योगदान करने की आवश्यकता नहीं है + +ओपन सोर्स में योगदान देने के बारे में एक आम ग़लतफ़हमी यह है कि आपको कोड का योगदान करने की आवश्यकता है। वास्तव में, यह अक्सर किसी परियोजना के अन्य भाग होते हैं जिन्हें [सबसे अधिक उपेक्षित या अनदेखा](https://github.com/blog/2195-the-shape-of-open-source) किया जाता है। आप इस प्रकार के योगदान की पेशकश करके परियोजना पर बहुत बड़ा उपकार करेंगे! + + + +भले ही आपको कोड लिखना पसंद हो, अन्य प्रकार के योगदान किसी प्रोजेक्ट में शामिल होने और समुदाय के अन्य सदस्यों से मिलने का एक शानदार तरीका है। उन संबंधों के निर्माण से आपको परियोजना के अन्य हिस्सों पर काम करने का अवसर मिलेगा। + +### क्या आपको आयोजनों की योजना बनाना पसंद है? + +* परियोजना के बारे में कार्यशालाएँ या बैठकें आयोजित करें, [जैसे @fzamperin ने NodeSchool के लिए किया](https://github.com/nodeschool/organizers/issues/406) +* परियोजना का सम्मेलन आयोजित करें (यदि उनके पास एक है) +* समुदाय के सदस्यों को सही सम्मेलन ढूंढने और बोलने के लिए प्रस्ताव प्रस्तुत करने में सहायता करें + +### क्या आपको डिज़ाइन करना पसंद है? + +* परियोजना की उपयोगिता में सुधार के लिए लेआउट का पुनर्गठन करें +* प्रोजेक्ट के नेविगेशन या मेनू को पुनर्गठित और परिष्कृत करने के लिए उपयोगकर्ता अनुसंधान करें, [जैसा कि Drupal सुझाव देता है](https://www.drupal.org/community-initiatives/drupal-core/usability) +* प्रोजेक्ट को एक सुसंगत विज़ुअल डिज़ाइन बनाने में मदद करने के लिए एक स्टाइल गाइड साथ रखें +* टी-शर्ट या नए लोगो के लिए कला बनाएं, [जैसे hapi.js के योगदानकर्ताओं ने किया](https://github.com/hapijs/contrib/issues/68) + +### क्या आप लिखना पसंद करते हैं? + +* प्रोजेक्ट के दस्तावेज़ीकरण को लिखें और सुधारें +* प्रोजेक्ट का उपयोग कैसे किया जाता है, यह दर्शाने वाले उदाहरणों का एक फ़ोल्डर बनाएं +* प्रोजेक्ट के लिए एक न्यूज़लेटर शुरू करें, या मेलिंग सूची से हाइलाइट्स क्यूरेट करें +* प्रोजेक्ट के लिए ट्यूटोरियल लिखें, [जैसे PyPA के योगदानकर्ताओं ने किया](https://github.com/pypa/python-package-user-guide/issues/194) +* परियोजना के दस्तावेज़ीकरण के लिए एक अनुवाद लिखें + + + +### क्या आपको आयोजन करना पसंद है? + +* चीजों को व्यवस्थित रखने के लिए डुप्लिकेट मुद्दों से लिंक करें, और नए अंक लेबल का सुझाव दें +* खुले मुद्दों पर गौर करें और पुराने मुद्दों को बंद करने का सुझाव दें, [जैसे @nzakas ने ESLint के लिए किया](https://github.com/eslint/eslint/issues/6765) +* चर्चा को आगे बढ़ाने के लिए हाल ही में खुले मुद्दों पर स्पष्ट प्रश्न पूछें + +### क्या आपको कोड करना पसंद है? + +* निपटने के लिए एक खुला मुद्दा खोजें, [जैसे @dianjin ने कैटलॉग के लिए किया](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* पूछें कि क्या आप एक नई सुविधा लिखने में मदद कर सकते हैं +* स्वचालित प्रोजेक्ट सेटअप +* टूलींग और परीक्षण में सुधार करें + +### क्या आपको लोगों की मदद करना पसंद है? + +* प्रोजेक्ट के बारे में प्रश्नों के उत्तर दें, उदाहरण के लिए, स्टैक ओवरफ्लो ([इस पोस्टग्रेज उदाहरण की तरह](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) या रेडिट +* खुले मुद्दों पर लोगों के सवालों के जवाब दें +* चर्चा बोर्डों या वार्तालाप चैनलों को मॉडरेट करने में सहायता करें + +### क्या आपको दूसरों की कोड में मदद करना पसंद है? + +* अन्य लोगों के सबमिशन पर कोड की समीक्षा करें +* किसी प्रोजेक्ट का उपयोग कैसे किया जा सकता है, इसके लिए ट्यूटोरियल लिखें +* किसी अन्य योगदानकर्ता को सलाह देने की पेशकश, [जैसे @ereichert ने Rust पर @bronzdoc के लिए किया](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### आपको सिर्फ सॉफ्टवेयर प्रोजेक्ट पर काम नहीं करना है! + +जबकि "ओपन सोर्स" अक्सर सॉफ़्टवेयर को संदर्भित करता है, आप किसी भी चीज़ पर सहयोग कर सकते हैं। ऐसी किताबें, रेसिपी, सूचियाँ और कक्षाएं हैं जिन्हें ओपन सोर्स प्रोजेक्ट के रूप में विकसित किया जाता है। + +उदाहरण के लिए: + +* @sindresorhas एक ["भयानक" सूचियों की सूची तैयार करता है](https://github.com/sindresorhas/awesome) +* @h5bp फ्रंट-एंड डेवलपर उम्मीदवारों के लिए [संभावित साक्षात्कार प्रश्नों की सूची] (https://github.com/h5bp/Front-end-Developer-Interview-Questions) रखता है +* @stuartlynn और @nicole-a-tesla ने [पफिन्स के बारे में मजेदार तथ्यों का संग्रह](https://github.com/stuartlynn/puffin_facts) बनाया। + +भले ही आप एक सॉफ़्टवेयर डेवलपर हों, दस्तावेज़ीकरण प्रोजेक्ट पर काम करने से आपको ओपन सोर्स में शुरुआत करने में मदद मिल सकती है। उन परियोजनाओं पर काम करना अक्सर कम डराने वाला होता है जिनमें कोड शामिल नहीं होता है, और सहयोग की प्रक्रिया आपके आत्मविश्वास और अनुभव का निर्माण करेगी। + +## अपने आप को एक नई परियोजना की ओर उन्मुख करना + + + +टाइपो फिक्स से अधिक किसी भी चीज़ के लिए, ओपन सोर्स में योगदान करना किसी पार्टी में अजनबियों के समूह के पास जाने जैसा है। यदि आप लामाओं के बारे में बात करना शुरू करते हैं, जबकि वे सुनहरी मछली के बारे में गहन चर्चा में थे, तो वे शायद आपको थोड़ा अजीब तरीके से देखेंगे। + +अपने स्वयं के सुझावों पर आँख मूँद कर कूदने से पहले, कमरे को पढ़ना सीखना शुरू करें। ऐसा करने से संभावना बढ़ जाती है कि आपके विचारों पर ध्यान दिया जाएगा और सुना जाएगा। + +### एक ओपन सोर्स प्रोजेक्ट का एनाटॉमी + +प्रत्येक खुला स्रोत समुदाय अलग है। + +एक ओपन सोर्स प्रोजेक्ट पर वर्षों बिताने का मतलब है कि आपको एक ओपन सोर्स प्रोजेक्ट के बारे में पता चल गया है। एक अलग प्रोजेक्ट पर जाएँ, और आप पाएंगे कि शब्दावली, मानदंड और संचार शैलियाँ पूरी तरह से अलग हैं। + +जैसा कि कहा गया है, कई ओपन सोर्स प्रोजेक्ट समान संगठनात्मक संरचना का पालन करते हैं। विभिन्न सामुदायिक भूमिकाओं और समग्र प्रक्रिया को समझने से आपको किसी भी नई परियोजना के प्रति शीघ्रता से उन्मुख होने में मदद मिलेगी। + +एक विशिष्ट ओपन सोर्स प्रोजेक्ट में निम्नलिखित प्रकार के लोग होते हैं: + +* **लेखक:** वह व्यक्ति/संगठन जिसने प्रोजेक्ट बनाया है +* **स्वामी:** वह व्यक्ति/व्यक्ति जिनके पास संगठन या भंडार पर प्रशासनिक स्वामित्व है (हमेशा मूल लेखक के समान नहीं) +* **रखरखावकर्ता:** योगदानकर्ता जो परियोजना के दृष्टिकोण को आगे बढ़ाने और संगठनात्मक पहलुओं को प्रबंधित करने के लिए जिम्मेदार हैं (वे परियोजना के लेखक या मालिक भी हो सकते हैं।) +* **योगदानकर्ता:** हर कोई जिसने परियोजना में कुछ न कुछ योगदान दिया है +* **समुदाय सदस्य:** वे लोग जो परियोजना का उपयोग करते हैं। वे बातचीत में सक्रिय हो सकते हैं या परियोजना की दिशा पर अपनी राय व्यक्त कर सकते हैं + +बड़ी परियोजनाओं में उपसमितियां या कार्य समूह भी हो सकते हैं जो टूलींग, ट्राइएज, सामुदायिक मॉडरेशन और इवेंट आयोजन जैसे विभिन्न कार्यों पर केंद्रित हो सकते हैं। इस जानकारी को पाने के लिए किसी प्रोजेक्ट की वेबसाइट पर "टीम" पृष्ठ, या शासन दस्तावेज़ के भंडार में देखें। + +एक प्रोजेक्ट में दस्तावेज़ीकरण भी होता है. ये फ़ाइलें आमतौर पर रिपॉजिटरी के शीर्ष स्तर पर सूचीबद्ध होती हैं। + +* **लाइसेंस:** परिभाषा के अनुसार, प्रत्येक ओपन सोर्स प्रोजेक्ट के पास एक [ओपन सोर्स लाइसेंस](https://choosealicense.com) होना चाहिए। यदि प्रोजेक्ट के पास लाइसेंस नहीं है, तो यह खुला स्रोत नहीं है। +* **रीडमी:** रीडमी एक निर्देश पुस्तिका है जो परियोजना में नए समुदाय के सदस्यों का स्वागत करती है। यह बताता है कि परियोजना क्यों उपयोगी है और इसे कैसे शुरू किया जाए। +* **योगदान:** जबकि READMEs लोगों को परियोजना का उपयोग करने में मदद करते हैं, योगदान करने वाले दस्तावेज़ लोगों को परियोजना में योगदान देने में मदद करते हैं। यह बताता है कि किस प्रकार के योगदान की आवश्यकता है और प्रक्रिया कैसे काम करती है। हालाँकि हर परियोजना में योगदान फ़ाइल नहीं होती है, इसकी उपस्थिति संकेत देती है कि यह योगदान करने के लिए एक स्वागत योग्य परियोजना है। +* **आचार संहिता:** आचार संहिता प्रतिभागियों के व्यवहार से संबंधित बुनियादी नियम निर्धारित करती है और एक मैत्रीपूर्ण, स्वागत योग्य वातावरण बनाने में मदद करती है। हालाँकि हर परियोजना में एक Code_OF_CONDUCT फ़ाइल नहीं होती है, लेकिन इसकी उपस्थिति संकेत देती है कि यह योगदान देने के लिए एक स्वागत योग्य परियोजना है। +* **अन्य दस्तावेज़:** अतिरिक्त दस्तावेज़ हो सकते हैं, जैसे ट्यूटोरियल, वॉकथ्रू, या शासन नीतियां, विशेष रूप से बड़ी परियोजनाओं पर। + +अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है। + +* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं। +* **पुल रीकवेस्ट:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं। +* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं। +* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं। + +## योगदान देने के लिए एक परियोजना ढूँढना + +अब जब आपको पता चल गया है कि ओपन सोर्स प्रोजेक्ट कैसे काम करते हैं, तो योगदान देने के लिए एक प्रोजेक्ट ढूंढने का समय आ गया है! + +यदि आपने पहले कभी भी ओपन सोर्स में योगदान नहीं दिया है, तो अमेरिकी राष्ट्रपति जॉन एफ कैनेडी से कुछ सलाह लें, जिन्होंने एक बार कहा था, _"यह मत पूछो कि आपका देश आपके लिए क्या कर सकता है - यह पूछें कि आप अपने देश के लिए क्या कर सकते हैं।"_ + +ओपन सोर्स में योगदान सभी स्तरों पर, सभी परियोजनाओं में होता है। आपको यह ज़्यादा सोचने की ज़रूरत नहीं है कि वास्तव में आपका पहला योगदान क्या होगा, या यह कैसा दिखेगा। + +इसके बजाय, उन परियोजनाओं के बारे में सोचकर शुरुआत करें जिनका आप पहले से उपयोग कर रहे हैं, या जिनका उपयोग करना चाहते हैं। जिन परियोजनाओं में आप सक्रिय रूप से योगदान देंगे, उन्हीं परियोजनाओं में आप स्वयं को वापस आते हुए पाएंगे। + +उन परियोजनाओं के भीतर, जब भी आप खुद को यह सोचते हुए पाते हैं कि कुछ बेहतर या अलग हो सकता है, तो अपनी प्रवृत्ति पर कार्य करें। + +ओपन सोर्स कोई विशेष क्लब नहीं है; यह आप जैसे ही लोगों द्वारा बनाया गया है। "ओपन सोर्स" दुनिया की समस्याओं को ठीक करने योग्य मानने के लिए सिर्फ एक फैंसी शब्द है। + +आप README को स्कैन कर सकते हैं और एक टूटा हुआ लिंक या कोई टाइपो पा सकते हैं। या आप एक नए उपयोगकर्ता हैं और आपने देखा कि कुछ टूटा हुआ है, या कोई समस्या है जो आपको लगता है कि वास्तव में दस्तावेज़ में होनी चाहिए। इसे नज़रअंदाज़ करने और आगे बढ़ने, या किसी और से इसे ठीक करने के लिए कहने के बजाय, देखें कि क्या आप इसमें योगदान देकर मदद कर सकते हैं। खुले स्रोत का यही मतलब है! + +> [28% आकस्मिक योगदान](https://www.igor.pro.br/publica/papers/saner2016.pdf) ओपन सोर्स के लिए दस्तावेज हैं, जैसे टाइपो फिक्स, रिफॉर्मेटिंग, या अनुवाद लिखना। + +यदि आप मौजूदा मुद्दों की तलाश कर रहे हैं जिन्हें आप ठीक कर सकते हैं, तो प्रत्येक ओपन सोर्स प्रोजेक्ट में एक `/contribute` पेज होता है जो शुरुआती-अनुकूल मुद्दों पर प्रकाश डालता है जिनके साथ आप शुरुआत कर सकते हैं। GitHub पर रिपॉजिटरी के मुख्य पृष्ठ पर जाएँ, और URL के अंत में `/contribute` जोड़ें (उदाहरण के लिए [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +नई परियोजनाओं को खोजने और उनमें योगदान देने में सहायता के लिए आप निम्नलिखित संसाधनों में से किसी एक का भी उपयोग कर सकते हैं: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) + +### योगदान देने से पहले एक चेकलिस्ट + +जब आपको कोई ऐसा प्रोजेक्ट मिल जाए जिसमें आप योगदान करना चाहते हैं, तो यह सुनिश्चित करने के लिए त्वरित स्कैन करें कि प्रोजेक्ट योगदान स्वीकार करने के लिए उपयुक्त है। वरना आपकी मेहनत को कभी जवाब नहीं मिल पाएगा. + +यह मूल्यांकन करने के लिए एक आसान चेकलिस्ट है कि कोई प्रोजेक्ट नए योगदानकर्ताओं के लिए अच्छा है या नहीं। + +**ओपन सोर्स की परिभाषा को पूरा करता है** + +
+ + +
+ +**परियोजना सक्रिय रूप से योगदान स्वीकार करती है** + +Main branch पर commit प्रतिबद्ध को देखें। GitHub पर, आप इस जानकारी को रिपॉजिटरी के होमपेज पर देख सकते हैं। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +इसके बाद, परियोजना के मुद्दों को देखें। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +अब प्रोजेक्ट के पुल रीकवेस्ट के लिए भी ऐसा ही करें। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**परियोजना स्वागतयोग्य है** + +एक परियोजना जो मैत्रीपूर्ण और स्वागत योग्य है, यह संकेत देती है कि वे नए योगदानकर्ताओं के प्रति ग्रहणशील होंगे। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## योगदान कैसे जमा करें + +आपको अपनी पसंद का एक प्रोजेक्ट मिल गया है और आप योगदान देने के लिए तैयार हैं। अंत में! यहां बताया गया है कि अपना योगदान सही तरीके से कैसे प्राप्त करें। + +### प्रभावी ढंग से संचार करना + +चाहे आप एक बार के योगदानकर्ता हों या किसी समुदाय में शामिल होने का प्रयास कर रहे हों, दूसरों के साथ काम करना सबसे महत्वपूर्ण कौशलों में से एक है जिसे आप ओपन सोर्स में विकसित करेंगे। + + + +इससे पहले कि आप कोई मुद्दा खोलें या अनुरोध खींचें, या चैट में कोई प्रश्न पूछें, अपने विचारों को प्रभावी ढंग से सामने लाने में मदद के लिए इन बिंदुओं को ध्यान में रखें। + +**संदर्भ दें।** दूसरों को तेजी से आगे बढ़ने में मदद करें। यदि आप किसी त्रुटि का सामना कर रहे हैं, तो बताएं कि आप क्या करने का प्रयास कर रहे हैं और इसे कैसे पुन: उत्पन्न करना है। यदि आप कोई नया विचार सुझा रहे हैं, तो स्पष्ट करें कि आप क्यों सोचते हैं कि यह परियोजना के लिए उपयोगी होगा (केवल आपके लिए नहीं!)। + +> 😇 _"जब मैं यह करता हूं तो वह नहीं होता"_ +> +> 😢 _"यह टूट गया है! कृपया इसे ठीक करें।"_ + +**कृपया अपना होमवर्क पहले से कर लें।** चीजों को न जानना ठीक है, लेकिन दिखाएं कि आपने प्रयास किया। मदद मांगने से पहले, किसी प्रोजेक्ट की रीडमी, दस्तावेज़ीकरण, मुद्दे (खुले या बंद), मेलिंग सूची की जांच करना और उत्तर के लिए इंटरनेट पर खोजना सुनिश्चित करें। जब आप प्रदर्शित करेंगे कि आप सीखने का प्रयास कर रहे हैं तो लोग इसकी सराहना करेंगे। + +> 😇 _"मुझे नहीं पता कि ईस को कैसे लागू किया जाए। मैंने सहायता दस्तावेजों की जांच की और कोई उल्लेख नहीं मिला।"_ +> +> 😢 _"मैं कैसे यह करूं?"_ + +**अनुरोधों को संक्षिप्त और सीधा रखें।** ईमेल भेजने की तरह, हर योगदान, चाहे कितना भी सरल या उपयोगी क्यों न हो, किसी और की समीक्षा की आवश्यकता होती है। कई परियोजनाओं में मदद के लिए उपलब्ध लोगों की तुलना में अधिक अनुरोध आ रहे हैं। संक्षिप्त रखें। आपको इस बात की संभावना बढ़ जाएगी कि कोई आपकी मदद कर पाएगा। + +> 😇 _"मैं एक एपीआई ट्यूटोरियल लिखना चाहूंगा।"_ +> +> 😢 _"मैं पिछले दिन राजमार्ग पर गाड़ी चला रहा था और गैस के लिए रुका, और तभी मेरे मन में यह अद्भुत विचार आया कि हमें क्या करना चाहिए, लेकिन इससे पहले कि मैं यह समझाऊं, मैं आपको दिखाता हूं..."_ + +**सभी संचार सार्वजनिक रखें।** हालांकि यह आकर्षक है, जब तक आपको संवेदनशील जानकारी (जैसे कोई सुरक्षा मुद्दा या गंभीर आचरण उल्लंघन) साझा करने की आवश्यकता न हो, निजी तौर पर अनुरक्षकों तक न पहुंचें। जब आप बातचीत को सार्वजनिक रखते हैं, तो अधिक लोग आपके आदान-प्रदान से सीख सकते हैं और लाभ उठा सकते हैं। चर्चाएँ, अपने आप में, योगदान हो सकती हैं। + +> 😇 _(एक टिप्पणी के रूप में) "@-maintainer नमस्ते! हमें इस PR पर कैसे आगे बढ़ना चाहिए?"_ +> +> 😢_(एक ईमेल के रूप में) "अरे, ईमेल पर आपको परेशान करने के लिए खेद है, लेकिन मैं सोच रहा था कि क्या आपको मेरे PR की समीक्षा करने का मौका मिला है"_ + +**प्रश्न पूछना ठीक है (लेकिन धैर्य रखें!)** हर कोई किसी न किसी समय परियोजना में नया था, और यहां तक ​​कि अनुभवी योगदानकर्ताओं को भी जब वे किसी नई परियोजना को देखते हैं तो उन्हें तेजी लाने की जरूरत होती है। इसी तरह, लंबे समय तक अनुरक्षक भी हमेशा परियोजना के हर हिस्से से परिचित नहीं होते हैं। उन्हें वही धैर्य दिखाएं जो आप चाहते हैं कि वे आपके प्रति दिखाएं। + +> 😇 _"इस त्रुटि पर ध्यान देने के लिए धन्यवाद। मैंने आपके सुझावों का पालन किया। यहां आउटपुट है।"_ +> +> 😢 _"आप मेरी समस्या का समाधान क्यों नहीं कर सकते? क्या यह आपका प्रोजेक्ट नहीं है?"_ + +**सामुदायिक निर्णयों का सम्मान करें।** आपके विचार समुदाय की प्राथमिकताओं या दृष्टिकोण से भिन्न हो सकते हैं। वे प्रतिक्रिया दे सकते हैं या आपके विचार को आगे न बढ़ाने का निर्णय ले सकते हैं। जबकि आपको चर्चा करनी चाहिए और समझौते की तलाश करनी चाहिए, लेकिन अनुरक्षकों को आपके निर्णय के साथ आपकी इच्छा से अधिक समय तक रहना होगा। यदि आप उनकी दिशा से असहमत हैं, तो आप हमेशा अपने स्वयं के कांटे पर काम कर सकते हैं या अपना स्वयं का प्रोजेक्ट शुरू कर सकते हैं। + +> 😇 _"मुझे निराशा है कि आप मेरे उपयोग के मामले का समर्थन नहीं कर सकते, लेकिन जैसा कि आपने समझाया है कि यह केवल उपयोगकर्ताओं के एक छोटे हिस्से को प्रभावित करता है, मैं समझता हूं क्यों। सुनने के लिए धन्यवाद।"_ +> +> 😢 _"आप मेरे उपयोग के मामले का समर्थन क्यों नहीं करेंगे? यह अस्वीकार्य है!"_ + +**सबसे बढ़कर, इसे उत्तम दर्जे का रखें।** ओपन सोर्स दुनिया भर के सहयोगियों से बना है। भाषाओं, संस्कृतियों, भूगोलों और समय क्षेत्रों में संदर्भ खो जाता है। इसके अलावा, लिखित संचार से स्वर या मनोदशा को व्यक्त करना कठिन हो जाता है। इन वार्तालापों में अच्छे इरादे मानें। किसी विचार पर विनम्रतापूर्वक ज़ोर देना, अधिक संदर्भ मांगना, या अपनी स्थिति को और स्पष्ट करना ठीक है। बस इंटरनेट को उस समय से बेहतर जगह छोड़ने का प्रयास करें जब यह आपको मिला था। + +### संदर्भ एकत्रित करना + +कुछ भी करने से पहले, यह सुनिश्चित करने के लिए त्वरित जांच करें कि आपके विचार की चर्चा कहीं और नहीं की गई है। प्रोजेक्ट के README, मुद्दे (खुले और बंद), मेलिंग सूची और स्टैक ओवरफ़्लो को स्किम करें। आपको हर चीज़ को पढ़ने में घंटों खर्च करने की ज़रूरत नहीं है, लेकिन कुछ प्रमुख शब्दों की त्वरित खोज बहुत काम आती है। + +यदि आपको अपना विचार कहीं और नहीं मिल रहा है, तो आप एक कदम उठाने के लिए तैयार हैं। यदि प्रोजेक्ट GitHub पर है, तो आप संभवतः कोई समस्या खोलकर या अनुरोध खींचकर संवाद करेंगे: + +* **ईशूस** बातचीत या चर्चा शुरू करने जैसा है +* **पुल रीकवेस्ट** समाधान पर काम शुरू करने के लिए हैं +* **हल्के संचार के लिए,** जैसे कि स्पष्टीकरण या कैसे-कैसे प्रश्न करें, स्टैक ओवरफ़्लो, IRS, स्लैक, या अन्य चैट चैनलों पर पूछने का प्रयास करें, यदि प्रोजेक्ट में कोई है + +किसी मुद्दे को खोलने या अनुरोध खींचने से पहले, यह देखने के लिए कि क्या आपको कुछ विशिष्ट शामिल करने की आवश्यकता है, प्रोजेक्ट के योगदान दस्तावेज़ (आमतौर पर CONTRIBUTING या README में एक फ़ाइल) की जाँच करें। उदाहरण के लिए, वे आपसे एक टेम्पलेट का पालन करने के लिए कह सकते हैं, या आपसे परीक्षण का उपयोग करने के लिए कह सकते हैं। + +यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://help.github.com/articles/watching-repositories/) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है। + + + +### एक मुद्दा खुल रहा है + +आपको आमतौर पर निम्नलिखित स्थितियों में कोई मुद्दा खोलना चाहिए: + +* उस त्रुटि की रिपोर्ट करें जिसे आप स्वयं हल नहीं कर सकते +* किसी उच्च-स्तरीय विषय या विचार पर चर्चा करें (उदाहरण के लिए, समुदाय, दृष्टिकोण या नीतियां) +* एक नई सुविधा या अन्य परियोजना विचार का प्रस्ताव रखें + +मुद्दों पर संवाद करने के लिए युक्तियाँ: + +* **यदि आप कोई खुला मुद्दा देखते हैं जिससे आप निपटना चाहते हैं,** लोगों को यह बताने के लिए कि आप इस मुद्दे पर हैं, उस मुद्दे पर टिप्पणी करें। इस तरह, लोगों द्वारा आपके काम की नकल करने की संभावना कम होगी। +* **यदि कोई मुद्दा कुछ समय पहले खोला गया था,** यह संभव है कि इसे कहीं और संबोधित किया जा रहा है, या पहले ही हल किया जा चुका है, इसलिए काम शुरू करने से पहले पुष्टि के लिए टिप्पणी करें। +* **यदि आपने कोई मुद्दा खोला है, लेकिन बाद में आपको स्वयं उत्तर मिल गया है,** लोगों को बताने के लिए मुद्दे पर टिप्पणी करें, फिर मुद्दे को बंद कर दें। यहां तक कि उस परिणाम का दस्तावेज़ीकरण भी परियोजना में एक योगदान है। + +### पुल रीकवेस्ट खोलना + +आपको आमतौर पर निम्नलिखित स्थितियों में पुल अनुरोध खोलना चाहिए: + +* मामूली सुधार सबमिट करें (उदाहरण के लिए, एक टाइपो, एक टूटा हुआ लिंक या एक स्पष्ट त्रुटि) +* उस योगदान पर काम शुरू करें जो पहले से ही मांगा गया था, या जिस पर आप पहले ही किसी मुद्दे पर चर्चा कर चुके हैंn + +पुल अनुरोध को समाप्त कार्य का प्रतिनिधित्व करने की आवश्यकता नहीं है। आमतौर पर पुल अनुरोध को जल्दी खोलना बेहतर होता है, ताकि अन्य लोग आपकी प्रगति को देख सकें या उस पर प्रतिक्रिया दे सकें। बस इसे "ड्राफ्ट" के रूप में खोलें या विषय पंक्ति में "डब्ल्यूआईपी" (कार्य प्रगति पर) के रूप में चिह्नित करें। आप बाद में कभी भी और कमिट जोड़ सकते हैं। + +यदि प्रोजेक्ट GitHub पर है, तो पुल अनुरोध सबमिट करने का तरीका यहां दिया गया है: + +* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://help.github.com/articles/syncing-a-fork/).) +* **[एक ब्रेनच बनाएँ](https://guides.github.com/introduction/flow/)** आपके संपादनों के लिए. +* **अपने पीआर में किसी भी प्रासंगिक मुद्दे** या सहायक दस्तावेज़ का संदर्भ लें (उदाहरण के लिए, " #37 बंद होता है।") +* **यदि आपके परिवर्तनों में HTML/CSS में अंतर शामिल है तो पहले और बाद के स्क्रीनशॉट शामिल करें**। छवियों को अपने पुल अनुरोध के मुख्य भाग में खींचें और छोड़ें। +* **अपने परिवर्तनों का परीक्षण करें!** यदि कोई मौजूदा परीक्षण मौजूद है तो उसके विरुद्ध अपने परिवर्तन चलाएँ और आवश्यकता पड़ने पर नए बनाएँ। परीक्षण मौजूद हैं या नहीं, सुनिश्चित करें कि आपके परिवर्तन मौजूदा प्रोजेक्ट को बाधित नहीं करते हैं। +* **परियोजना की शैली में अपनी सर्वोत्तम क्षमता से योगदान दें**। इसका मतलब यह हो सकता है कि इंडेंट, सेमी-कोलन या टिप्पणियों का उपयोग आप अपने स्वयं के भंडार से अलग तरीके से करेंगे, लेकिन इससे अनुरक्षक के लिए विलय करना, दूसरों के लिए समझना और भविष्य में बनाए रखना आसान हो जाता है। + +यदि यह आपका पहला पुल अनुरोध है, तो [मेक अ पुल रिक्वेस्ट](http://makeapullrequest.com/) देखें, जिसे @kentcdodds ने वॉकथ्रू वीडियो ट्यूटोरियल के रूप में बनाया है। आप @Roshanjossey द्वारा बनाए गए [प्रथम योगदान](https://github.com/Roshanjossey/first-contributions) रिपॉजिटरी में पुल अनुरोध करने का अभ्यास भी कर सकते हैं। + +## आपके योगदान जमा करने के बाद क्या होता है + +तुमने यह किया! ओपन सोर्स योगदानकर्ता बनने पर बधाई। हमें उम्मीद है कि यह कई में से पहला है। + +आपके द्वारा योगदान जमा करने के बाद, निम्नलिखित में से एक होगा: + +### 😭 आपको कोई प्रतिक्रिया नहीं मिलती। + +उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#योगदान-देने-से-पहले-एक-चेकलिस्ट) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी। + +यदि आपको एक सप्ताह से अधिक समय में कोई प्रतिक्रिया नहीं मिली है, तो किसी से समीक्षा के लिए पूछते हुए, उसी थ्रेड में विनम्रतापूर्वक प्रतिक्रिया देना उचित है। यदि आप अपने योगदान की समीक्षा करने के लिए सही व्यक्ति का नाम जानते हैं, तो आप उस थ्रेड में उनका @-mention कर सकते हैं। + +**उस व्यक्ति तक निजी तौर पर संपर्क न करें; याद रखें कि ओपन सोर्स परियोजनाओं के लिए सार्वजनिक संचार महत्वपूर्ण है। + +यदि आप विनम्रतापूर्वक बात करते हैं और फिर भी कोई प्रतिक्रिया नहीं देता है, तो यह संभव है कि कोई भी कभी भी प्रतिक्रिया नहीं देगा। यह कोई बढ़िया एहसास नहीं है, लेकिन इससे आपको हतोत्साहित न होने दें। यह हर किसी के साथ हुआ है! आपको प्रतिक्रिया न मिलने के कई संभावित कारण हो सकते हैं, जिनमें व्यक्तिगत परिस्थितियाँ भी शामिल हैं जो आपके नियंत्रण से बाहर हो सकती हैं। योगदान देने के लिए कोई अन्य प्रोजेक्ट या तरीका खोजने का प्रयास करें। यदि कुछ भी हो, तो यह एक अच्छा कारण है कि समुदाय के अन्य सदस्यों के शामिल होने और प्रतिक्रिया देने से पहले योगदान देने में बहुत अधिक समय न लगाया जाए। + +### 🚧 कोई आपके योगदान में परिवर्तन का अनुरोध करता है। + +यह सामान्य बात है कि आपसे आपके योगदान में परिवर्तन करने के लिए कहा जाएगा, चाहे वह आपके विचार के दायरे पर प्रतिक्रिया हो, या आपके कोड में परिवर्तन हो। + +जब कोई परिवर्तन का अनुरोध करता है, तो उत्तरदायी बनें। उन्होंने आपके योगदान की समीक्षा करने के लिए समय लिया है। पीआर खोलना और चले जाना बुरी आदत है। यदि आप नहीं जानते कि परिवर्तन कैसे करें, तो समस्या पर शोध करें और यदि आपको सहायता की आवश्यकता हो तो सहायता माँगें। + +यदि आपके पास अब इस मुद्दे पर काम करने का समय नहीं है (उदाहरण के लिए, यदि बातचीत महीनों से चल रही है, और आपकी परिस्थितियाँ बदल गई हैं), तो अनुरक्षक को बताएं ताकि वे प्रतिक्रिया की उम्मीद न करें। कोई अन्य व्यक्ति कार्यभार संभालने में प्रसन्न हो सकता है। + +### 👎 आपका योगदान स्वीकार नहीं किया जाता। + +आपका योगदान अंततः स्वीकार किया भी जा सकता है और नहीं भी। उम्मीद है कि आपने पहले से ही इसमें बहुत अधिक काम नहीं किया होगा। यदि आप निश्चित नहीं हैं कि इसे क्यों स्वीकार नहीं किया गया, तो अनुरक्षक से फीडबैक और स्पष्टीकरण मांगना बिल्कुल उचित है। हालाँकि, अंततः, आपको इसका सम्मान करना होगा कि यह उनका निर्णय है। बहस न करें या शत्रुतापूर्ण न बनें। यदि आप असहमत हैं तो फोर्क और अपने संस्करण पर काम करने के लिए आपका हमेशा स्वागत है! + +### 🎉 आपका योगदान स्वीकार किया जाता है। + +हुर्रे! आपने सफलतापूर्वक ओपन सोर्स योगदान दे दिया है! + +## तुमने यह किया! + +चाहे आपने अभी अपना पहला ओपन सोर्स योगदान दिया हो, या आप योगदान करने के नए तरीकों की तलाश कर रहे हों, हमें उम्मीद है कि आप कार्रवाई करने के लिए प्रेरित होंगे। भले ही आपका योगदान स्वीकार नहीं किया गया हो, जब कोई अनुरक्षक आपकी मदद करने का प्रयास करे तो धन्यवाद कहना न भूलें। ओपन सोर्स आपके जैसे लोगों द्वारा बनाया गया है: एक समय में एक मुद्दा, पुल अनुरोध, टिप्पणी, या हाई-फाइव। diff --git a/_articles/hi/index.html b/_articles/hi/index.html new file mode 100644 index 00000000000..454d05a6705 --- /dev/null +++ b/_articles/hi/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: ओपन सोर्स गाइड +lang: hi +permalink: /hi/ +--- diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md new file mode 100644 index 00000000000..e680ef79544 --- /dev/null +++ b/_articles/hi/leadership-and-governance.md @@ -0,0 +1,157 @@ +--- +lang: hi +title: नेतृत्व और शासन +description: निर्णय लेने के लिए औपचारिक नियमों से बढ़ते ओपन सोर्स प्रोजेक्ट्स को फायदा हो सकता है। +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## अपने बढ़ते प्रोजेक्ट के लिए प्रशासन को समझना + +आपका प्रोजेक्ट बढ़ रहा है, लोग इसमें लगे हुए हैं और आप इस चीज़ को जारी रखने के लिए प्रतिबद्ध हैं। इस स्तर पर, आप सोच रहे होंगे कि नियमित परियोजना योगदानकर्ताओं को अपने वर्कफ़्लो में कैसे शामिल किया जाए, चाहे वह किसी को प्रतिबद्ध पहुंच प्रदान करना हो या सामुदायिक बहस को हल करना हो। यदि आपके कोई प्रश्न हैं, तो हमें उत्तर मिल गए हैं। + +## ओपन सोर्स प्रोजेक्ट्स में उपयोग की जाने वाली औपचारिक भूमिकाओं के उदाहरण क्या हैं? + +कई परियोजनाएँ योगदानकर्ता भूमिकाओं और मान्यता के लिए समान संरचना का पालन करती हैं। + +हालाँकि, इन भूमिकाओं का वास्तव में क्या मतलब है, यह पूरी तरह आप पर निर्भर है। यहां कुछ प्रकार की भूमिकाएं दी गई हैं जिन्हें आप पहचान सकते हैं: + +* **रखरखाव** +* **योगदान देने वाला** +* **कमिटर** + +**कुछ परियोजनाओं के लिए, "रखरखावकर्ता"** किसी परियोजना में प्रतिबद्ध पहुंच वाले एकमात्र लोग होते हैं। अन्य परियोजनाओं में, वे केवल वे लोग हैं जो रीडमी में अनुरक्षक के रूप में सूचीबद्ध हैं। + +एक अनुरक्षक आवश्यक रूप से ऐसा व्यक्ति नहीं है जो आपके प्रोजेक्ट के लिए कोड लिखता हो। यह कोई ऐसा व्यक्ति हो सकता है जिसने आपके प्रोजेक्ट को प्रचारित करने के लिए बहुत काम किया हो, या लिखित दस्तावेज़ीकरण किया हो जिसने प्रोजेक्ट को दूसरों के लिए अधिक सुलभ बना दिया हो। चाहे वे दिन-प्रतिदिन कुछ भी करें, एक अनुरक्षक संभवतः वह व्यक्ति होता है जो परियोजना की दिशा में ज़िम्मेदारी महसूस करता है और इसे सुधारने के लिए प्रतिबद्ध है। + +**एक "योगदानकर्ता" कोई भी हो सकता है** जो किसी मुद्दे या पुल अनुरोध पर टिप्पणी करता है, जो लोग परियोजना में मूल्य जोड़ते हैं (चाहे वह मुद्दों का परीक्षण करना हो, कोड लिखना हो, या घटनाओं का आयोजन करना हो), या मर्ज किए गए पुल अनुरोध वाला कोई भी व्यक्ति (शायद योगदानकर्ता की सबसे संकीर्ण परिभाषा।) + + + +**शब्द "कमिटर"** का उपयोग कमिट एक्सेस, जो एक विशिष्ट प्रकार की जिम्मेदारी है, को योगदान के अन्य रूपों से अलग करने के लिए किया जा सकता है। + +हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [व्यापक परिभाषाओं का उपयोग करने पर विचार करें](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों। + + + +## मैं इन नेतृत्व भूमिकाओं को कैसे औपचारिक बनाऊं? + +अपनी नेतृत्व भूमिकाओं को औपचारिक बनाने से लोगों को स्वामित्व महसूस करने में मदद मिलती है और समुदाय के अन्य सदस्यों को पता चलता है कि मदद के लिए किससे संपर्क करना चाहिए। + +एक छोटी परियोजना के लिए, नेताओं को नामित करना आपके README या CONTRIBUTORS टेक्स्ट फ़ाइल में उनके नाम जोड़ने जितना आसान हो सकता है। + +किसी बड़े प्रोजेक्ट के लिए, यदि आपके पास कोई वेबसाइट है, तो एक टीम पेज बनाएं या वहां अपने प्रोजेक्ट लीडरों की सूची बनाएं। उदाहरण के लिए, [Postgres](https://github.com/postgres/postgres/) के पास एक [comprehensive team page](https://www.postgresql.org/community/contributors/) प्रत्येक योगदानकर्ता के लिए संक्षिप्त प्रोफ़ाइल के साथ। + +यदि आपके प्रोजेक्ट में बहुत सक्रिय योगदानकर्ता समुदाय है, तो आप अनुरक्षकों की एक "कोर टीम" बना सकते हैं, या ऐसे लोगों की उपसमितियां भी बना सकते हैं जो विभिन्न मुद्दे क्षेत्रों (उदाहरण के लिए, सुरक्षा, समस्या निवारण, या सामुदायिक आचरण) का स्वामित्व लेते हैं। लोगों को वे भूमिकाएँ सौंपने के बजाय स्वयं संगठित होने दें और उनके लिए स्वेच्छा से काम करने दें जिनके बारे में वे सबसे अधिक उत्साहित हैं। + + + +नेतृत्व दल एक निर्दिष्ट चैनल बनाना चाह सकते हैं (जैसे आईआरसी पर) या परियोजना पर चर्चा करने के लिए नियमित रूप से मिलना चाहते हैं (जैसे गिटर या गूगल हैंगआउट पर)। आप उन बैठकों को सार्वजनिक भी कर सकते हैं ताकि अन्य लोग सुन सकें। [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), उदाहरण के लिए, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +एक बार जब आप नेतृत्व की भूमिकाएँ स्थापित कर लें, तो यह दस्तावेज करना न भूलें कि लोग उन्हें कैसे प्राप्त कर सकते हैं! कोई आपके प्रोजेक्ट में अनुरक्षक कैसे बन सकता है या उपसमिति में कैसे शामिल हो सकता है, इसके लिए एक स्पष्ट प्रक्रिया स्थापित करें और इसे अपने में लिखें GOVERNANCE.md. + +उपकरण जैसे [Vossibility](https://github.com/icecrime/vossibility-stack) आपको सार्वजनिक रूप से ट्रैक करने में मदद मिल सकती है कि प्रोजेक्ट में कौन योगदान दे रहा है (या नहीं दे रहा है)। इस जानकारी का दस्तावेजीकरण करने से समुदाय की इस धारणा से बचा जा सकता है कि रखरखाव करने वाले एक समूह हैं जो निजी तौर पर अपने निर्णय लेते हैं। + +अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें). + +## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए? + +कुछ लोग सोचते हैं कि आपको योगदान देने वाले हर व्यक्ति को प्रतिबद्ध पहुंच देनी चाहिए। ऐसा करने से अधिक लोग आपके प्रोजेक्ट पर स्वामित्व महसूस करने के लिए प्रोत्साहित हो सकते हैं। + +दूसरी ओर, विशेष रूप से बड़ी, अधिक जटिल परियोजनाओं के लिए, आप केवल उन लोगों को प्रतिबद्ध पहुंच देना चाह सकते हैं जिन्होंने अपनी प्रतिबद्धता प्रदर्शित की है। इसे करने का कोई एक सही तरीका नहीं है - वही करें जो आपको सबसे अधिक आरामदायक लगे! + +यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://help.github.com/articles/about-protected-branches/) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में। + + + +## ओपन सोर्स परियोजनाओं के लिए कुछ सामान्य शासन संरचनाएँ क्या हैं? + +ओपन सोर्स परियोजनाओं से जुड़ी तीन सामान्य शासन संरचनाएँ हैं। + +* **बीडीएफएल:** बीडीएफएल का अर्थ है "जीवन के लिए परोपकारी तानाशाह"। इस संरचना के तहत, सभी प्रमुख परियोजना निर्णयों पर एक व्यक्ति (आमतौर पर परियोजना का प्रारंभिक लेखक) का अंतिम अधिकार होता है। [Python](https://github.com/python) एक उत्कृष्ट उदाहरण है. छोटी परियोजनाएँ संभवतः डिफ़ॉल्ट रूप से बीडीएफएल हैं, क्योंकि केवल एक या दो अनुरक्षक होते हैं। किसी कंपनी में शुरू हुआ प्रोजेक्ट भी बीडीएफएल श्रेणी में आ सकता है। + +* **मेरिटोक्रेसी:** **(नोट: शब्द "मेरिटोक्रेसी" कुछ समुदायों के लिए नकारात्मक अर्थ रखता है और इसका एक नकारात्मक प्रभाव है[complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** योग्यतातंत्र के तहत, सक्रिय परियोजना योगदानकर्ताओं (जो "योग्यता" प्रदर्शित करते हैं) को औपचारिक निर्णय लेने की भूमिका दी जाती है। निर्णय आम तौर पर शुद्ध मतदान सर्वसम्मति के आधार पर किए जाते हैं। योग्यतातंत्र की अवधारणा का सूत्रपात किसके द्वारा किया गया था? [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) +योग्यतातंत्र हैं. योगदान केवल अपना प्रतिनिधित्व करने वाले व्यक्तियों द्वारा ही किया जा सकता है, किसी कंपनी द्वारा नहीं। + +* **उदार योगदान:** उदार योगदान मॉडल के तहत, जो लोग सबसे अधिक काम करते हैं उन्हें सबसे प्रभावशाली माना जाता है, लेकिन यह वर्तमान कार्य पर आधारित है न कि ऐतिहासिक योगदान पर। प्रमुख परियोजना निर्णय शुद्ध वोट के बजाय सर्वसम्मति प्राप्त करने की प्रक्रिया (प्रमुख शिकायतों पर चर्चा) के आधार पर किए जाते हैं, और यथासंभव अधिक से अधिक सामुदायिक दृष्टिकोणों को शामिल करने का प्रयास किया जाता है। उदार योगदान मॉडल का उपयोग करने वाली परियोजनाओं के लोकप्रिय उदाहरणों में शामिल हैं [Node.js](https://foundation.nodejs.org/) और [Rust](https://www.rust-lang.org/). + +आपको किसका उपयोग करना चाहिए? यह आप पर निर्भर करता है! हर मॉडल के फायदे और फायदे हैं। और यद्यपि वे पहली बार में काफी भिन्न लग सकते हैं, तीनों मॉडलों में जितना वे दिखते हैं उससे कहीं अधिक समानता है। यदि आप इनमें से किसी एक मॉडल को अपनाने में रुचि रखते हैं, तो इन टेम्पलेट्स को देखें: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## क्या मुझे अपना प्रोजेक्ट लॉन्च करते समय शासन दस्तावेज़ों की आवश्यकता होगी? + +आपके प्रोजेक्ट के प्रशासन को लिखने का कोई सही समय नहीं है, लेकिन एक बार जब आप अपने समुदाय की गतिशीलता को देख लेंगे तो इसे परिभाषित करना बहुत आसान हो जाएगा। ओपन सोर्स गवर्नेंस के बारे में सबसे अच्छी (और सबसे कठिन) बात यह है कि इसे समुदाय द्वारा आकार दिया जाता है! + +हालाँकि, कुछ शुरुआती दस्तावेज़ अनिवार्य रूप से आपके प्रोजेक्ट के प्रशासन में योगदान देंगे, इसलिए आप जो कर सकते हैं उसे लिखना शुरू कर दें। उदाहरण के लिए, आप व्यवहार के लिए स्पष्ट अपेक्षाओं को परिभाषित कर सकते हैं, या आपके प्रोजेक्ट के लॉन्च पर भी आपकी योगदानकर्ता प्रक्रिया कैसे काम करती है। + +यदि आप एक ओपन सोर्स प्रोजेक्ट लॉन्च करने वाली कंपनी का हिस्सा हैं, तो लॉन्च से पहले इस बारे में आंतरिक चर्चा करना उचित है कि आपकी कंपनी प्रोजेक्ट को आगे बढ़ाने के बारे में कैसे बनाए रखने और निर्णय लेने की उम्मीद करती है। हो सकता है कि आप सार्वजनिक रूप से यह स्पष्ट करना चाहें कि आपकी कंपनी इस परियोजना में कैसे शामिल होगी (या नहीं करेगी!)। + + + +## यदि कॉर्पोरेट कर्मचारी अंशदान जमा करना शुरू कर दें तो क्या होगा? + +सफल ओपन सोर्स परियोजनाओं का उपयोग कई लोगों और कंपनियों द्वारा किया जाता है, और कुछ कंपनियों के पास अंततः राजस्व धाराएं परियोजना से जुड़ी हो सकती हैं। उदाहरण के लिए, कोई कंपनी किसी वाणिज्यिक सेवा पेशकश में परियोजना के कोड को एक घटक के रूप में उपयोग कर सकती है। + +जैसे-जैसे परियोजना अधिक व्यापक रूप से उपयोग की जाती है, इसमें विशेषज्ञता रखने वाले लोगों की मांग अधिक हो जाती है - आप उनमें से एक हो सकते हैं! - और कभी-कभी उन्हें प्रोजेक्ट में किए गए काम के लिए भुगतान मिलेगा। + +व्यावसायिक गतिविधि को सामान्य और विकास ऊर्जा के एक अन्य स्रोत के रूप में मानना ​​महत्वपूर्ण है। निःसंदेह, भुगतान किए गए डेवलपर्स को अवैतनिक डेवलपर्स की तुलना में विशेष व्यवहार नहीं मिलना चाहिए; प्रत्येक योगदान का मूल्यांकन उसकी तकनीकी खूबियों के आधार पर किया जाना चाहिए। हालाँकि, लोगों को व्यावसायिक गतिविधि में शामिल होने में सहज महसूस करना चाहिए, और किसी विशेष वृद्धि या सुविधा के पक्ष में बहस करते समय अपने उपयोग के मामलों को बताने में सहज महसूस करना चाहिए। + +"वाणिज्यिक" "ओपन सोर्स" के साथ पूरी तरह से संगत है। "वाणिज्यिक" का सीधा सा मतलब है कि इसमें कहीं न कहीं पैसा शामिल है - कि सॉफ्टवेयर का उपयोग वाणिज्य में किया जाता है, जो कि एक परियोजना के अपनाने के रूप में तेजी से संभव है। (जब ओपन सोर्स सॉफ़्टवेयर का उपयोग गैर-ओपन-सोर्स उत्पाद के हिस्से के रूप में किया जाता है, तो समग्र उत्पाद अभी भी "मालिकाना" सॉफ़्टवेयर होता है, हालांकि, ओपन सोर्स की तरह, इसका उपयोग वाणिज्यिक या गैर-व्यावसायिक उद्देश्यों के लिए किया जा सकता है।) + +किसी भी अन्य की तरह, व्यावसायिक रूप से प्रेरित डेवलपर्स अपने योगदान की गुणवत्ता और मात्रा के माध्यम से परियोजना में प्रभाव प्राप्त करते हैं। जाहिर है, एक डेवलपर जिसे उसके समय के लिए भुगतान किया जाता है, वह उस व्यक्ति से अधिक काम करने में सक्षम हो सकता है जिसे भुगतान नहीं किया जाता है, लेकिन यह ठीक है: भुगतान कई संभावित कारकों में से एक है जो किसी के काम को प्रभावित कर सकता है। अपनी परियोजना चर्चाओं को योगदानों पर केंद्रित रखें, न कि उन बाहरी कारकों पर जो लोगों को योगदान देने में सक्षम बनाते हैं। + +## क्या मुझे अपने प्रोजेक्ट का समर्थन करने के लिए एक कानूनी इकाई की आवश्यकता है? + +जब तक आप पैसे का प्रबंधन नहीं कर रहे हों, आपको अपने ओपन सोर्स प्रोजेक्ट का समर्थन करने के लिए किसी कानूनी इकाई की आवश्यकता नहीं है। + +उदाहरण के लिए, यदि आप एक वाणिज्यिक व्यवसाय बनाना चाहते हैं, तो आप एक सी कॉर्प या एलएलसी स्थापित करना चाहेंगे (यदि आप अमेरिका में स्थित हैं)। यदि आप केवल अपने ओपन सोर्स प्रोजेक्ट से संबंधित अनुबंध कार्य कर रहे हैं, तो आप एकमात्र मालिक के रूप में धन स्वीकार कर सकते हैं, या एलएलसी स्थापित कर सकते हैं (यदि आप अमेरिका में स्थित हैं)। + +यदि आप अपने ओपन सोर्स प्रोजेक्ट के लिए दान स्वीकार करना चाहते हैं, तो आप एक दान बटन सेट कर सकते हैं (उदाहरण के लिए पेपैल या स्ट्राइप का उपयोग करके), लेकिन पैसा तब तक कर-कटौती योग्य नहीं होगा जब तक कि आप एक योग्य गैर-लाभकारी संस्था (501c3, यदि आप अमेरिका में हैं)। + +कई परियोजनाएँ एक गैर-लाभकारी संस्था स्थापित करने की परेशानी से गुज़रना नहीं चाहती हैं, इसलिए वे इसके बजाय एक गैर-लाभकारी राजकोषीय प्रायोजक ढूंढती हैं। एक राजकोषीय प्रायोजक आपकी ओर से दान स्वीकार करता है, आमतौर पर दान के एक प्रतिशत के बदले में। [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) ओर [Open Collective](https://opencollective.com/opensource) ऐसे संगठनों के उदाहरण हैं जो ओपन सोर्स परियोजनाओं के लिए वित्तीय प्रायोजक के रूप में काम करते हैं। + + + +यदि आपका प्रोजेक्ट किसी निश्चित भाषा या पारिस्थितिकी तंत्र से निकटता से जुड़ा हुआ है, तो एक संबंधित सॉफ़्टवेयर फ़ाउंडेशन भी हो सकता है जिसके साथ आप काम कर सकते हैं। उदाहरण के लिए, [Python Software Foundation](https://www.python.org/psf/) मदद करता है [PyPI](https://pypi.org/), पायथन पैकेज मैनेजर का, और [Node.js Foundation](https://foundation.nodejs.org/) मदद करता है [Express.js](https://expressjs.com/) का, एक नोड-आधारित ढांचा। diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md new file mode 100644 index 00000000000..aae22fa1d16 --- /dev/null +++ b/_articles/hi/legal.md @@ -0,0 +1,162 @@ +--- +lang: hi +title: ओपन सोर्स का कानूनी पक्ष +description: ओपन सोर्स के कानूनी पक्ष के बारे में आपने जो कुछ भी सोचा है, और कुछ चीजें जो आपने नहीं सोची हैं। +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## ओपन सोर्स के कानूनी निहितार्थ को समझना + +अपने रचनात्मक कार्य को दुनिया के साथ साझा करना एक रोमांचक और पुरस्कृत अनुभव हो सकता है। इसका मतलब यह भी हो सकता है कि कई कानूनी चीजें जिनके बारे में आप नहीं जानते कि आपको चिंता करने की ज़रूरत है। शुक्र है, आपको शून्य से शुरुआत करने की ज़रूरत नहीं है। हमने आपकी कानूनी ज़रूरतें पूरी कर ली हैं। (इससे पहले कि आप गहराई से जानें, हमारा पढ़ना सुनिश्चित करें [disclaimer](/notices/).) + +## लोग ओपन सोर्स के कानूनी पक्ष की इतनी परवाह क्यों करते हैं? + +ख़ुशी है कि आपने पूछा! जब आप कोई रचनात्मक कार्य (जैसे लेखन, ग्राफ़िक्स, या कोड) करते हैं, तो वह कार्य डिफ़ॉल्ट रूप से विशेष कॉपीराइट के अंतर्गत होता है। यानी, कानून मानता है कि आपके काम के लेखक के रूप में, आपको यह कहने का अधिकार है कि दूसरे इसके साथ क्या कर सकते हैं। + +सामान्य तौर पर, इसका मतलब यह है कि कोई भी अन्य व्यक्ति टेक-डाउन, शेक-डाउन या मुकदमेबाजी के जोखिम के बिना आपके काम का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है। + +हालाँकि, ओपन सोर्स एक असामान्य परिस्थिति है, क्योंकि लेखक को उम्मीद है कि अन्य लोग काम का उपयोग, संशोधन और साझा करेंगे। लेकिन चूँकि कानूनी डिफ़ॉल्ट अभी भी अनन्य कॉपीराइट है, इसलिए आपको एक ऐसे लाइसेंस की आवश्यकता है जो इन अनुमतियों को स्पष्ट रूप से बताता हो। + +यदि आप ओपन सोर्स लाइसेंस लागू नहीं करते हैं, तो आपके प्रोजेक्ट में योगदान देने वाला प्रत्येक व्यक्ति भी अपने काम का विशेष कॉपीराइट धारक बन जाता है। इसका मतलब है कि कोई भी उनके योगदान का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है - और उस "कोई भी" में आप शामिल नहीं हैं। + +अंततः, आपके प्रोजेक्ट में लाइसेंस आवश्यकताओं वाली निर्भरताएँ हो सकती हैं जिनके बारे में आपको जानकारी नहीं थी। आपके प्रोजेक्ट के समुदाय, या आपके नियोक्ता की नीतियों के लिए, आपके प्रोजेक्ट को विशिष्ट ओपन सोर्स लाइसेंस का उपयोग करने की भी आवश्यकता हो सकती है। हम नीचे इन स्थितियों को कवर करेंगे। + +## क्या सार्वजनिक GitHub परियोजनाएँ खुला स्रोत हैं? + +जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://help.github.com/articles/creating-a-new-repository/), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है। + +![Create repository](/assets/images/legal/repo-create-name.png) + +**अपने GitHub प्रोजेक्ट को सार्वजनिक बनाना आपके प्रोजेक्ट को लाइसेंस देने के समान नहीं है।** सार्वजनिक परियोजनाएँ इसके अंतर्गत आती हैं [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है। + +यदि आप चाहते हैं कि अन्य लोग आपके प्रोजेक्ट का उपयोग, वितरण, संशोधन या योगदान करें, तो आपको एक ओपन सोर्स लाइसेंस शामिल करना होगा। उदाहरण के लिए, कोई व्यक्ति आपके GitHub प्रोजेक्ट के किसी भी हिस्से को अपने कोड में कानूनी रूप से उपयोग नहीं कर सकता, भले ही वह सार्वजनिक हो, जब तक कि आप स्पष्ट रूप से उन्हें ऐसा करने का अधिकार नहीं देते। + +## बस मुझे टीएल;डीआर दें कि मुझे अपने प्रोजेक्ट की सुरक्षा के लिए क्या चाहिए। + +आप भाग्यशाली हैं, क्योंकि आज, ओपन सोर्स लाइसेंस मानकीकृत और उपयोग में आसान हैं। आप किसी मौजूदा लाइसेंस को सीधे अपने प्रोजेक्ट में कॉपी-पेस्ट कर सकते हैं। + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) +सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन चुनने के लिए अन्य विकल्प भी हैं। आप इन लाइसेंसों का पूरा पाठ और उनका उपयोग करने के तरीके के बारे में निर्देश यहां पा सकते हैं[choosealicense.com](https://choosealicense.com/). + +जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://help.github.com/articles/open-source-licensing/). + + + +## मेरे प्रोजेक्ट के लिए कौन सा ओपन सोर्स लाइसेंस उपयुक्त है? + +यदि आप कोरी स्लेट से शुरुआत कर रहे हैं, तो इसमें गलत होना कठिन है [MIT License](https://choosealicense.com/licenses/mit/). यह संक्षिप्त है, समझने में बहुत आसान है, और किसी को भी कुछ भी करने की अनुमति देता है जब तक कि वे आपके कॉपीराइट नोटिस सहित लाइसेंस की एक प्रति अपने पास रखते हैं। यदि आपको कभी आवश्यकता होगी तो आप प्रोजेक्ट को एक अलग लाइसेंस के तहत जारी करने में सक्षम होंगे। + +अन्यथा, आपके प्रोजेक्ट के लिए सही ओपन सोर्स लाइसेंस चुनना आपके उद्देश्यों पर निर्भर करता है। + +आपके प्रोजेक्ट की बहुत संभावना है (या होगी) **dependencies**. उदाहरण के लिए, यदि आप Node.js प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं, तो आप संभवतः नोड पैकेज मैनेजर (npm) से लाइब्रेरी का उपयोग करेंगे। आप जिन पुस्तकालयों पर निर्भर हैं उनमें से प्रत्येक के पास अपना स्वयं का ओपन सोर्स लाइसेंस होगा। यदि उनका प्रत्येक लाइसेंस "अनुमोदनात्मक" है (डाउनस्ट्रीम लाइसेंसिंग के लिए बिना किसी शर्त के जनता को उपयोग, संशोधन और साझा करने की अनुमति देता है), तो आप अपने इच्छित किसी भी लाइसेंस का उपयोग कर सकते हैं। सामान्य अनुमेय लाइसेंस में एमआईटी, अपाचे 2.0, आईएससी और बीएसडी शामिल हैं। + +दूसरी ओर, यदि आपकी किसी निर्भरता का लाइसेंस "मजबूत कॉपीलेफ्ट" है (सार्वजनिक रूप से समान अनुमतियाँ देता है, समान लाइसेंस डाउनस्ट्रीम का उपयोग करने की शर्त के अधीन), तो आपके प्रोजेक्ट को उसी लाइसेंस का उपयोग करना होगा। सामान्य मजबूत कॉपीलेफ़्ट लाइसेंस में GPLv2, GPLv3, और AGPLv3 शामिल हैं। + +आप शायद उन **communities** पर भी विचार करना चाहेंगे जिनका आप उपयोग करेंगे और आपके प्रोजेक्ट में योगदान देंगे: + +* **क्या आप चाहते हैं कि आपकी परियोजना का उपयोग अन्य परियोजनाओं द्वारा निर्भरता के रूप में किया जाए?** संभवतः आपके प्रासंगिक समुदाय में सबसे लोकप्रिय लाइसेंस का उपयोग करना सबसे अच्छा है। उदाहरण के लिए, [MIT](https://choosealicense.com/licenses/mit/) +के लिए सबसे लोकप्रिय लाइसेंस है [npm libraries](https://libraries.io/search?platforms=NPM). +* **क्या आप चाहते हैं कि आपका प्रोजेक्ट बड़े व्यवसायों को पसंद आए?** एक बड़ा व्यवसाय संभवतः सभी योगदानकर्ताओं से एक एक्सप्रेस पेटेंट लाइसेंस चाहेगा। इस मामले में, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **क्या आप चाहते हैं कि आपका प्रोजेक्ट उन योगदानकर्ताओं को आकर्षित करे जो नहीं चाहते कि उनके योगदान का उपयोग बंद स्रोत सॉफ़्टवेयर में किया जाए?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) या (यदि वे भी बंद स्रोत सेवाओं में योगदान नहीं करना चाहते हैं) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) +अच्छा चलेगा। + +आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#what-does-my-companys-legal-team-need-to-know) से बातें करें। + +जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/). + +## यदि मैं अपने प्रोजेक्ट का लाइसेंस बदलना चाहूँ तो क्या होगा? + +अधिकांश परियोजनाओं को कभी भी लाइसेंस बदलने की आवश्यकता नहीं होती है। लेकिन कभी-कभी हालात बदल जाते हैं. + +उदाहरण के लिए, जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, इसमें निर्भरताएँ या उपयोगकर्ता जुड़ते हैं, या आपकी कंपनी रणनीतियाँ बदलती है, जिनमें से किसी को भी अलग लाइसेंस की आवश्यकता हो सकती है या चाहिए। साथ ही, यदि आपने शुरू से ही अपने प्रोजेक्ट को लाइसेंस देने की उपेक्षा की है, तो लाइसेंस जोड़ना प्रभावी रूप से लाइसेंस बदलने के समान है। अपने प्रोजेक्ट का लाइसेंस जोड़ते या बदलते समय विचार करने योग्य तीन मूलभूत बातें हैं: + +**यह जटिल है।** लाइसेंस अनुकूलता और अनुपालन का निर्धारण करना और कॉपीराइट किसके पास है, यह बहुत जल्दी जटिल और भ्रमित करने वाला हो सकता है। नई रिलीज़ और योगदान के लिए नए लेकिन संगत लाइसेंस पर स्विच करना सभी मौजूदा योगदानों को दोबारा लाइसेंस देने से अलग है। लाइसेंस बदलने की इच्छा के पहले संकेत पर अपनी कानूनी टीम को शामिल करें। भले ही आपके पास लाइसेंस परिवर्तन के लिए अपने प्रोजेक्ट के कॉपीराइट धारकों से अनुमति है या आप प्राप्त कर सकते हैं, फिर भी अपने प्रोजेक्ट के अन्य उपयोगकर्ताओं और योगदानकर्ताओं पर परिवर्तन के प्रभाव पर विचार करें। अपने प्रोजेक्ट के लिए लाइसेंस परिवर्तन को एक "गवर्नेंस इवेंट" के रूप में सोचें, जो आपके प्रोजेक्ट के हितधारकों के साथ स्पष्ट संचार और परामर्श के साथ आसानी से चलेगा। शुरुआत से ही अपने प्रोजेक्ट के लिए उपयुक्त लाइसेंस चुनने और उसका उपयोग करने का और भी अधिक कारण! + +**आपके प्रोजेक्ट का मौजूदा लाइसेंस।** यदि आपके प्रोजेक्ट का मौजूदा लाइसेंस उस लाइसेंस के अनुकूल है जिसे आप बदलना चाहते हैं, तो आप नए लाइसेंस का उपयोग शुरू कर सकते हैं। ऐसा इसलिए है क्योंकि यदि लाइसेंस ए लाइसेंस बी के साथ संगत है, तो आप बी की शर्तों का अनुपालन करते समय ए की शर्तों का अनुपालन करेंगे (लेकिन जरूरी नहीं कि इसका विपरीत भी हो)। इसलिए यदि आप वर्तमान में एक अनुमेय लाइसेंस (उदाहरण के लिए, एमआईटी) का उपयोग कर रहे हैं, तो आप अधिक शर्तों वाले लाइसेंस में बदल सकते हैं, जब तक कि आप एमआईटी लाइसेंस और किसी भी संबंधित कॉपीराइट नोटिस की एक प्रति अपने पास रखते हैं (यानी, इसका अनुपालन करना जारी रखते हैं। एमआईटी लाइसेंस की न्यूनतम शर्तें)। लेकिन यदि आपका वर्तमान लाइसेंस अनुमेय नहीं है (उदाहरण के लिए, कॉपीलेफ्ट, या आपके पास लाइसेंस नहीं है) और आप एकमात्र कॉपीराइट धारक नहीं हैं, तो आप अपने प्रोजेक्ट के लाइसेंस को एमआईटी में नहीं बदल सकते। मूलतः, अनुमेय लाइसेंस के साथ परियोजना के कॉपीराइट धारकों ने लाइसेंस बदलने की अग्रिम अनुमति दे दी है। + +**आपके प्रोजेक्ट के मौजूदा कॉपीराइट धारक।** यदि आप अपने प्रोजेक्ट में एकमात्र योगदानकर्ता हैं तो या तो आप या आपकी कंपनी प्रोजेक्ट के एकमात्र कॉपीराइट धारक हैं। आप या आपकी कंपनी जो भी लाइसेंस जोड़ना या बदलना चाहती है, आप उसे जोड़ या बदल सकते हैं। अन्यथा ऐसे अन्य कॉपीराइट धारक भी हो सकते हैं जिनसे लाइसेंस बदलने के लिए आपको सहमति की आवश्यकता होगी। कौन हैं वे? जिन लोगों की आपके प्रोजेक्ट में प्रतिबद्धता है, वे शुरुआत करने के लिए एक अच्छी जगह हैं। लेकिन कुछ मामलों में कॉपीराइट उन लोगों के नियोक्ताओं के पास होगा। कुछ मामलों में लोगों ने केवल न्यूनतम योगदान दिया होगा, लेकिन ऐसा कोई सख्त नियम नहीं है कि कोड की कुछ पंक्तियों के तहत योगदान कॉपीराइट के अधीन नहीं है। क्या करें? निर्भर करता है। अपेक्षाकृत छोटी और युवा परियोजना के लिए, सभी मौजूदा योगदानकर्ताओं को किसी मुद्दे या पुल अनुरोध में लाइसेंस परिवर्तन के लिए सहमत करना संभव हो सकता है। बड़ी और लंबे समय तक चलने वाली परियोजनाओं के लिए, आपको कई योगदानकर्ताओं और यहां तक ​​कि उनके उत्तराधिकारियों की तलाश करनी पड़ सकती है। मोज़िला को फ़ायरफ़ॉक्स, थंडरबर्ड और संबंधित सॉफ़्टवेयर को पुनः लाइसेंस देने में वर्षों (2001-2006) लग गए। + +वैकल्पिक रूप से, आप अपने मौजूदा ओपन सोर्स लाइसेंस द्वारा अनुमत शर्तों से परे, कुछ शर्तों के तहत कुछ लाइसेंस परिवर्तनों के लिए योगदानकर्ताओं को पहले से सहमत कर सकते हैं (एक अतिरिक्त योगदानकर्ता समझौते के माध्यम से - नीचे देखें)। इससे लाइसेंस बदलने की जटिलता कुछ हद तक बदल जाती है। आपको पहले से ही अपने वकीलों से अधिक सहायता की आवश्यकता होगी, और लाइसेंस परिवर्तन निष्पादित करते समय आप अभी भी अपने प्रोजेक्ट के हितधारकों के साथ स्पष्ट रूप से संवाद करना चाहेंगे। + +## क्या मेरे प्रोजेक्ट को अतिरिक्त योगदानकर्ता समझौते की आवश्यकता है? + +शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +एक अतिरिक्त योगदानकर्ता समझौता - जिसे अक्सर Contributor License Agreement (CLA) कहा जाता है - परियोजना अनुरक्षकों के लिए प्रशासनिक कार्य बना सकता है। एक समझौता कितना काम जोड़ता है यह परियोजना और कार्यान्वयन पर निर्भर करता है। एक साधारण समझौते के लिए आवश्यक हो सकता है कि योगदानकर्ता एक क्लिक के साथ पुष्टि करें कि उनके पास प्रोजेक्ट ओपन सोर्स लाइसेंस के तहत योगदान करने के लिए आवश्यक अधिकार हैं। अधिक जटिल समझौते के लिए कानूनी समीक्षा और योगदानकर्ताओं के नियोक्ताओं से हस्ताक्षर की आवश्यकता हो सकती है। + +साथ ही, "कागजी कार्रवाई" जोड़कर, जो कुछ लोगों का मानना ​​है कि अनावश्यक, समझने में कठिन या अनुचित है (जब समझौते के प्राप्तकर्ता को परियोजना के ओपन सोर्स लाइसेंस के माध्यम से योगदानकर्ताओं या जनता की तुलना में अधिक अधिकार मिलते हैं), एक अतिरिक्त योगदानकर्ता समझौते को अमित्र माना जा सकता है परियोजना के समुदाय के लिए। + + + +कुछ स्थितियाँ जहाँ आप अपने प्रोजेक्ट के लिए अतिरिक्त योगदानकर्ता समझौते पर विचार करना चाह सकते हैं उनमें शामिल हैं: + +* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) हल्के अतिरिक्त योगदानकर्ता समझौते का एक अच्छा उदाहरण है। +* आप या आपके वकील चाहते हैं कि डेवलपर्स यह प्रतिनिधित्व करें कि उनकी प्रत्येक प्रतिबद्धता अधिकृत है. [Developer Certificate of Origin](https://developercertificate.org/) आवश्यकता यह है कि कितनी परियोजनाएँ इसे प्राप्त करती हैं। उदाहरण के लिए, Node.js समुदाय [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) उनके पूर्व CLI का। आपके भंडार पर डीसीओ के प्रवर्तन को स्वचालित करने का एक सरल विकल्प है [DCO Probot](https://github.com/probot/dco). +*आपका प्रोजेक्ट एक ओपन सोर्स लाइसेंस का उपयोग करता है जिसमें एक्सप्रेस पेटेंट अनुदान (जैसे एमआईटी) शामिल नहीं है, और आपको सभी योगदानकर्ताओं से पेटेंट अनुदान की आवश्यकता है, जिनमें से कुछ बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के लिए काम कर सकते हैं जिनका उपयोग आपको लक्षित करने के लिए किया जा सकता है या परियोजना के अन्य योगदानकर्ता और उपयोगकर्ता। The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) आमतौर पर इस्तेमाल किया जाने वाला अतिरिक्त योगदानकर्ता समझौता है जिसमें अपाचे लाइसेंस 2.0 में पाए गए पेटेंट अनुदान को प्रतिबिंबित किया गया है। +* आपका प्रोजेक्ट कॉपीलेफ्ट लाइसेंस के अंतर्गत है, लेकिन आपको प्रोजेक्ट का मालिकाना संस्करण भी वितरित करने की आवश्यकता है। आपको प्रत्येक योगदानकर्ता से आपको कॉपीराइट सौंपने या आपको (लेकिन जनता को नहीं) अनुमेय लाइसेंस देने की आवश्यकता होगी। [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) इस प्रकार के समझौते का एक उदाहरण है. +* आपको लगता है कि आपके प्रोजेक्ट को अपने जीवनकाल में लाइसेंस बदलने की आवश्यकता हो सकती है और आप चाहते हैं कि योगदानकर्ता ऐसे परिवर्तनों के लिए पहले से सहमत हों। + +यदि आपको अपने प्रोजेक्ट के साथ एक अतिरिक्त योगदानकर्ता समझौते का उपयोग करने की आवश्यकता है, तो एक एकीकरण का उपयोग करने पर विचार करें [CLA assistant](https://github.com/cla-assistant/cla-assistant) योगदानकर्ता व्याकुलता को कम करने के लिए। + +## मेरी कंपनी की कानूनी टीम को क्या जानना आवश्यक है? + +यदि आप एक कंपनी कर्मचारी के रूप में एक ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो सबसे पहले, आपकी कानूनी टीम को पता होना चाहिए कि आप एक प्रोजेक्ट को ओपन सोर्स कर रहे हैं। + +बेहतर या बदतर के लिए, उन्हें बताने पर विचार करें, भले ही यह एक व्यक्तिगत परियोजना हो। संभवत: आपके पास अपनी कंपनी के साथ एक "कर्मचारी आईपी समझौता" है जो उन्हें आपकी परियोजनाओं पर कुछ नियंत्रण देता है, खासकर यदि वे कंपनी के व्यवसाय से संबंधित हैं या आप परियोजना को विकसित करने के लिए किसी कंपनी के संसाधनों का उपयोग करते हैं। आपकी कंपनी को आपको आसानी से अनुमति देनी चाहिए, और शायद पहले से ही एक कर्मचारी-अनुकूल आईपी समझौते या कंपनी नीति के माध्यम से अनुमति दे दी है। यदि नहीं, तो आप बातचीत कर सकते हैं (उदाहरण के लिए, समझाएं कि आपका प्रोजेक्ट आपके लिए कंपनी के पेशेवर शिक्षण और विकास उद्देश्यों को पूरा करता है), या जब तक आपको एक बेहतर कंपनी नहीं मिल जाती, तब तक अपने प्रोजेक्ट पर काम करने से बचें। + +**यदि आप अपनी कंपनी के लिए किसी प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं,** तो उन्हें अवश्य बताएं। आपकी कानूनी टीम के पास संभवतः पहले से ही नीतियां हैं कि कंपनी की व्यावसायिक आवश्यकताओं और विशेषज्ञता के आधार पर किस ओपन सोर्स लाइसेंस (और शायद अतिरिक्त योगदानकर्ता समझौते) का उपयोग किया जाए ताकि यह सुनिश्चित हो सके कि आपका प्रोजेक्ट उसकी निर्भरता के लाइसेंस का अनुपालन करता है। यदि नहीं, तो आप और वे भाग्यशाली हैं! आपकी कानूनी टीम को इस चीज़ का पता लगाने के लिए आपके साथ काम करने के लिए उत्सुक होना चाहिए। सोचने लायक कुछ बातें: + +* **तृतीय पक्ष सामग्री:** क्या आपके प्रोजेक्ट में दूसरों द्वारा बनाई गई निर्भरताएँ हैं या अन्यथा दूसरों के कोड को शामिल या उपयोग करते हैं? यदि ये ओपन सोर्स हैं, तो आपको सामग्रियों के ओपन सोर्स लाइसेंस का अनुपालन करना होगा। इसकी शुरुआत एक ऐसे लाइसेंस को चुनने से होती है जो तीसरे पक्ष के ओपन सोर्स लाइसेंस के साथ काम करता है (ऊपर देखें)। यदि आपका प्रोजेक्ट तृतीय पक्ष ओपन सोर्स सामग्री को संशोधित या वितरित करता है, तो आपकी कानूनी टीम यह भी जानना चाहेगी कि आप तृतीय पक्ष ओपन सोर्स लाइसेंस की अन्य शर्तों को पूरा कर रहे हैं जैसे कि कॉपीराइट नोटिस बनाए रखना। यदि आपका प्रोजेक्ट दूसरों के कोड का उपयोग करता है जिसके पास ओपन सोर्स लाइसेंस नहीं है, तो आपको संभवतः तीसरे पक्ष के अनुरक्षकों से पूछना होगा [एक ओपन सोर्स लाइसेंस जोड़ें](https://choosealicense.com/no-license/#for-users), और यदि आपको कोई नहीं मिल सकता है, तो अपने प्रोजेक्ट में उनके कोड का उपयोग करना बंद कर दें। + +* **व्यापार रहस्य:** विचार करें कि क्या परियोजना में ऐसा कुछ है जिसे कंपनी आम जनता के लिए उपलब्ध नहीं कराना चाहती है। यदि ऐसा है, तो जिस सामग्री को आप निजी रखना चाहते हैं, उसे निकालने के बाद आप अपने प्रोजेक्ट के बाकी हिस्से को ओपन सोर्स कर सकते हैं। + +* **पेटेंट:** क्या आपकी कंपनी किसी ऐसे पेटेंट के लिए आवेदन कर रही है जिसके ओपन सोर्सिंग से आपका प्रोजेक्ट [सार्वजनिक प्रकटीकरण](https://en.wikipedia.org/wiki/Public_disclosure) बनेगा? अफसोस की बात है, आपको प्रतीक्षा करने के लिए कहा जा सकता है (या हो सकता है कि कंपनी आवेदन की समझदारी पर पुनर्विचार करेगी)। यदि आप बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के कर्मचारियों से अपने प्रोजेक्ट में योगदान की उम्मीद कर रहे हैं, तो आपकी कानूनी टीम चाहती है कि आप योगदानकर्ताओं (जैसे अपाचे 2.0 या जीपीएलवी 3) से एक्सप्रेस पेटेंट अनुदान के साथ लाइसेंस का उपयोग करें, या एक अतिरिक्त योगदानकर्ता अनुबंध ( ऊपर देखें)। + +* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#नाम-टकराव-से-बचना)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है। + +* **गोपनीयता:** क्या आपका प्रोजेक्ट उपयोगकर्ताओं पर डेटा एकत्र करता है? कंपनी सर्वर के लिए "फ़ोन होम"? आपकी कानूनी टीम कंपनी की नीतियों और बाहरी नियमों का अनुपालन करने में आपकी सहायता कर सकती है। + +यदि आप अपनी कंपनी का पहला ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो उपरोक्त पूरा करने के लिए पर्याप्त से अधिक है (लेकिन चिंता न करें, अधिकांश परियोजनाओं को कोई बड़ी चिंता नहीं उठानी चाहिए)। + +लंबी अवधि में, आपकी कानूनी टीम कंपनी को ओपन सोर्स में अपनी भागीदारी से अधिक लाभ प्राप्त करने और सुरक्षित रहने में मदद करने के लिए और अधिक प्रयास कर सकती है: + +* **कर्मचारी योगदान नीतियां:** एक कॉर्पोरेट नीति विकसित करने पर विचार करें जो निर्दिष्ट करती है कि आपके कर्मचारी ओपन सोर्स परियोजनाओं में कैसे योगदान करते हैं। एक स्पष्ट नीति आपके कर्मचारियों के बीच भ्रम को कम करेगी और उन्हें कंपनी के सर्वोत्तम हित में ओपन सोर्स परियोजनाओं में योगदान करने में मदद करेगी, चाहे वह उनकी नौकरी के हिस्से के रूप में हो या उनके खाली समय में। एक अच्छा उदाहरण रैकस्पेस की [मॉडल आईपी और ओपन सोर्स योगदान नीति](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) है। + + + +* **क्या जारी करें:** [(लगभग) सब कुछ?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) यदि आपकी कानूनी टीम समझती है और है यदि आपने अपनी कंपनी की ओपन सोर्स रणनीति में निवेश किया है, तो वे आपके प्रयासों में बाधा डालने के बजाय मदद करने में सर्वोत्तम रूप से सक्षम होंगे। +* **अनुपालन:** भले ही आपकी कंपनी कोई ओपन सोर्स प्रोजेक्ट जारी नहीं करती है, यह दूसरों के ओपन सोर्स सॉफ़्टवेयर का उपयोग करती है। [जागरूकता और प्रक्रिया](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) सिरदर्द, उत्पाद में देरी और मुकदमों को रोक सकती है . + + + +* **पेटेंट:** आपकी कंपनी प्रमुख ओपन सोर्स परियोजनाओं के सदस्यों के उपयोग की सुरक्षा के लिए एक साझा रक्षात्मक पेटेंट पूल [ओपन इन्वेंशन नेटवर्क](https://www.openinventionnetwork.com/) में शामिल होना चाह सकती है, या अन्वेषण कर सकती है अन्य [वैकल्पिक पेटेंट लाइसेंसिंग](https://www.eff.org/document/hacking-patent-system-2016). + +* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#क्या-मुझे-अपने-प्रोजेक्ट-का-समर्थन-करने-के-लिए-एक-कानूनी-इकाई-की-आवश्यकता-है). diff --git a/_articles/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..4282247015b --- /dev/null +++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,221 @@ +--- +lang: hi +untranslated: true +title: ओपन सोर्स अनुरक्षकों के लिए संतुलन बनाए रखना +description: एक अनुचर के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ। +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +जैसे-जैसे एक ओपन सोर्स प्रोजेक्ट की लोकप्रियता बढ़ती है, आपको लंबे समय तक तरोताजा और उत्पादक बने रहने के लिए संतुलन बनाए रखने में मदद करने के लिए स्पष्ट सीमाएँ निर्धारित करना महत्वपूर्ण हो जाता है। + +संतुलन खोजने के लिए अनुरक्षकों के अनुभवों और उनकी रणनीतियों के बारे में जानकारी प्राप्त करने के लिए, हमने मेंटेनर समुदाय के 40 सदस्यों के साथ एक कार्यशाला चलाई, जिससे हमें अनुमति मिली खुले स्रोत में बर्नआउट के साथ उनके प्रत्यक्ष अनुभवों और उन प्रथाओं से सीखना जिन्होंने उन्हें अपने काम में संतुलन बनाए रखने में मदद की है। यहीं पर व्यक्तिगत पारिस्थितिकी की अवधारणा काम आती है। + +तो, व्यक्तिगत पारिस्थितिकी क्या है? जैसा रॉकवुड लीडरशिप इंस्टीट्यूट द्वारा वर्णित, इसमें "संतुलन बनाए रखना, गति बनाए रखना और शामिल है जीवन भर हमारी ऊर्जा को बनाए रखने की दक्षता।" इसने हमारी बातचीत को तैयार किया, जिससे अनुरक्षकों को समय के साथ विकसित होने वाले एक बड़े पारिस्थितिकी तंत्र के हिस्से के रूप में अपने कार्यों और योगदान को पहचानने में मदद मिली। बर्नआउट, क्रोनिक कार्यस्थल तनाव से उत्पन्न एक सिंड्रोम जैसा कि [डब्ल्यूएचओ द्वारा परिभाषित](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), अनुरक्षकों के बीच असामान्य नहीं है। इससे अक्सर प्रेरणा की हानि, ध्यान केंद्रित करने में असमर्थता और उन योगदानकर्ताओं और समुदाय के लिए सहानुभूति की कमी हो जाती है जिनके साथ आप काम करते हैं। + + + +व्यक्तिगत पारिस्थितिकी की अवधारणा को अपनाकर, अनुरक्षक सक्रिय रूप से बर्नआउट से बच सकते हैं, आत्म-देखभाल को प्राथमिकता दे सकते हैं और अपना सर्वश्रेष्ठ कार्य करने के लिए संतुलन की भावना बनाए रख सकते हैं। + +## एक अनुरक्षक के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ: + +### ओपन सोर्स में काम करने के लिए अपनी प्रेरणाओं को पहचानें + +इस बात पर विचार करने के लिए समय निकालें कि ओपन सोर्स रखरखाव के कौन से हिस्से आपको ऊर्जावान बनाते हैं। अपनी प्रेरणाओं को समझने से आपको काम को इस तरह से प्राथमिकता देने में मदद मिल सकती है जिससे आप व्यस्त रहेंगे और नई चुनौतियों के लिए तैयार रहेंगे। चाहे वह उपयोगकर्ताओं से सकारात्मक प्रतिक्रिया हो, समुदाय के साथ सहयोग और मेलजोल की खुशी हो, या कोड में गोता लगाने की संतुष्टि हो, अपनी प्रेरणाओं को पहचानने से आपका ध्यान केंद्रित करने में मदद मिल सकती है। + +### इस बात पर विचार करें कि किन कारणों से आप असंतुलित हो जाते हैं और तनावग्रस्त हो जाते हैं + +यह समझना महत्वपूर्ण है कि किन कारणों से हम थक जाते हैं। यहां कुछ सामान्य विषय हैं जो हमने ओपन सोर्स अनुरक्षकों के बीच देखे हैं: + +* **सकारात्मक प्रतिक्रिया का अभाव:** उपयोगकर्ताओं के पास शिकायत होने पर संपर्क करने की बहुत अधिक संभावना होती है। यदि सब कुछ बढ़िया चलता है, तो वे चुप रहना पसंद करते हैं। सकारात्मक प्रतिक्रिया के बिना मुद्दों की बढ़ती सूची को देखना हतोत्साहित करने वाला हो सकता है, जिसमें दिखाया गया हो कि आपके योगदान से कैसे फर्क पड़ रहा है। + + + +* **'नहीं' नहीं कहना:** किसी ओपन सोर्स प्रोजेक्ट पर अपनी अपेक्षा से अधिक ज़िम्मेदारियाँ लेना आसान हो सकता है। चाहे यह उपयोगकर्ताओं, योगदानकर्ताओं, या अन्य अनुरक्षकों से हो - हम हमेशा उनकी अपेक्षाओं पर खरे नहीं उतर सकते। + + + +* **अकेले काम करना:** एक अनुरक्षक बनना अविश्वसनीय रूप से अकेला हो सकता है। भले ही आप अनुरक्षकों के एक समूह के साथ काम करते हैं, पिछले कुछ वर्षों में वितरित टीमों को व्यक्तिगत रूप से बुलाना कठिन रहा है। + + + +* **पर्याप्त समय या संसाधन नहीं:** यह स्वयंसेवक अनुरक्षकों के लिए विशेष रूप से सच है, जिन्हें किसी परियोजना पर काम करने के लिए अपने खाली समय का त्याग करना पड़ता है। + + + +* **परस्पर विरोधी मांगें:** खुला स्रोत विभिन्न प्रेरणाओं वाले समूहों से भरा है, जिन्हें नेविगेट करना मुश्किल हो सकता है। यदि आपको ओपन सोर्स करने के लिए भुगतान किया जाता है, तो आपके नियोक्ता के हित कभी-कभी समुदाय के विपरीत हो सकते हैं। + + + +### बर्नआउट के लक्षणों से सावधान रहें + +क्या आप 10 सप्ताह तक अपनी गति बनाए रख सकते हैं? दस महीने? 10 वर्ष? + +उपकरण जैसे [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) [@shaunagm](https://github.com/shaunagm) से और मोज़िला का [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं। + + + +### आपको अपना और अपने समुदाय का भरण-पोषण जारी रखने के लिए क्या चाहिए होगा? + +यह प्रत्येक अनुरक्षक के लिए अलग दिखेगा, और आपके जीवन के चरण और अन्य बाहरी कारकों के आधार पर बदल जाएगा। लेकिन यहां कुछ विषय हैं जो हमने सुने हैं: + +* **समुदाय पर निर्भर रहें:** प्रतिनिधिमंडल और योगदानकर्ताओं को ढूंढने से काम का बोझ कम हो सकता है। किसी प्रोजेक्ट के लिए संपर्क के कई बिंदु होने से आपको बिना किसी चिंता के ब्रेक लेने में मदद मिल सकती है। [मेंटेनर कम्युनिटी](http://maintainers.github.com/) जैसे समूहों में अन्य अनुरक्षकों और व्यापक समुदाय से जुड़ें। साथियों के समर्थन और सीखने के लिए यह एक बेहतरीन संसाधन हो सकता है। + + आप उपयोगकर्ता समुदाय के साथ जुड़ने के तरीकों की भी तलाश कर सकते हैं, ताकि आप नियमित रूप से फीडबैक सुन सकें और अपने ओपन सोर्स कार्य के प्रभाव को समझ सकें। + +* **फंडिंग का अन्वेषण करें:** चाहे आप कुछ पिज़्ज़ा मनी की तलाश में हों, या पूर्णकालिक ओपन सोर्स पर जाने की कोशिश कर रहे हों, मदद के लिए कई संसाधन मौजूद हैं! पहले कदम के रूप में, दूसरों को आपके ओपन सोर्स कार्य को प्रायोजित करने की अनुमति देने के लिए [GitHub प्रायोजक](https://github.com/sponsors) को चालू करने पर विचार करें। यदि आप पूर्णकालिक बनने के बारे में सोच रहे हैं, तो [GitHub Accelerator](http://accelerator.github.com/) के अगले दौर के लिए आवेदन करें। + + + +* **टूल्स का उपयोग करें:** सांसारिक कार्यों को स्वचालित करने के लिए [GitHub Copilot](https://github.com/features/copilot/) और [GitHub Actions](https://github.com/features/actions) जैसे टूल खोजें कार्य करें और अधिक सार्थक योगदान के लिए अपना समय खाली करें। + + + +* **आराम करें और रिचार्ज करें:** ओपन सोर्स के बाहर अपने शौक और रुचियों के लिए समय निकालें। आराम करने और तरोताजा होने के लिए सप्ताहांत की छुट्टी लें-और अपना काम शुरू करें [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) आपकी उपलब्धता दर्शाने के लिए! एक अच्छी रात की नींद आपके प्रयासों को लंबे समय तक जारी रखने की आपकी क्षमता में बड़ा अंतर ला सकती है। + + यदि आपको अपने प्रोजेक्ट के कुछ पहलू विशेष रूप से आनंददायक लगते हैं, तो अपने काम को इस प्रकार व्यवस्थित करने का प्रयास करें ताकि आप इसे पूरे दिन अनुभव कर सकें। + + + +* **सीमाएँ निर्धारित करें:** आप हर अनुरोध के लिए हाँ नहीं कह सकते। यह कहने जितना सरल हो सकता है, "मैं अभी उस तक नहीं पहुंच सकता और भविष्य में मेरी कोई योजना नहीं है," या README में यह सूचीबद्ध करना कि आप क्या करने में रुचि रखते हैं और क्या नहीं करने में। उदाहरण के लिए, आप कह सकते हैं: "मैं केवल उन पीआर का विलय करता हूं जिनमें स्पष्ट रूप से उन कारणों को सूचीबद्ध किया गया है कि उन्हें क्यों बनाया गया है," या, "मैं केवल वैकल्पिक गुरुवार को शाम 6 से 7 बजे तक मुद्दों की समीक्षा करता हूं।" यह दूसरों के लिए अपेक्षाएं निर्धारित करता है, और आपको कुछ देता है अपने समय पर योगदानकर्ताओं या उपयोगकर्ताओं की मांगों को कम करने में मदद करने के लिए अन्य समय पर इंगित करना। + + + + विषाक्त व्यवहार और नकारात्मक बातचीत को बंद करने में दृढ़ रहना सीखें। उन चीज़ों को ऊर्जा न देना ठीक है जिनकी आपको परवाह नहीं है। + + + + + +याद रखें, व्यक्तिगत पारिस्थितिकी एक सतत अभ्यास है जो आपकी ओपन सोर्स यात्रा में प्रगति के साथ विकसित होगी। आत्म-देखभाल को प्राथमिकता देकर और संतुलन की भावना बनाए रखकर, आप प्रभावी ढंग से और स्थायी रूप से ओपन सोर्स समुदाय में योगदान कर सकते हैं, जिससे आपकी भलाई और लंबे समय तक आपकी परियोजनाओं की सफलता दोनों सुनिश्चित हो सकती है। + +## अतिरिक्त संसाधन + +* [मेंटेनर समुदाय](http://maintainers.github.com/) +* [ओपन सोर्स का सामाजिक अनुबंध](https://snarky.ca/the-social-contract-of-open-source/), ब्रेट कैनन +* [अनकर्लड](https://daniel.haxx.se/uncurled/), डेनियल स्टेनबर्ग +* [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs), जीना हाउजगे +* [सस्टेनओएसएस](https://sustainoss.org/) +* [व्यक्तिगत पारिस्थितिकी स्व-मूल्यांकन किट](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), मोज़िला +* [नेतृत्व की रॉकवुड कला](https://rockwoodleadership.org/art-of-leadership/) +* [नहीं कहना](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), माइक मैकक्यूएड +* [गवर्निंग ओपन](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* कार्यशाला के एजेंडे को रीमिक्स किया गया था [घर से मोज़िला की मूवमेंट बिल्डिंग](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) शृंखला + +## योगदानकर्ताओं + +इस गाइड के लिए अपने अनुभव और सुझाव हमारे साथ साझा करने वाले सभी अनुरक्षकों को बहुत धन्यवाद! + +यह मार्गदर्शिका [@abbycabs](https://github.com/abbycabs) द्वारा इनके योगदान के साथ लिखी गई थी: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md new file mode 100644 index 00000000000..5f4de85f9ba --- /dev/null +++ b/_articles/hi/metrics.md @@ -0,0 +1,128 @@ +--- +lang: hi +title: ओपन सोर्स मेट्रिक्स +description: अपने ओपन सोर्स प्रोजेक्ट की सफलता को मापने और ट्रैक करके उसे फलने-फूलने में मदद करने के लिए सोच-समझकर निर्णय लें। +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## किसी भी चीज़ को क्यों मापें? + +डेटा, जब बुद्धिमानी से उपयोग किया जाता है, तो आपको ओपन सोर्स अनुरक्षक के रूप में बेहतर निर्णय लेने में मदद मिल सकती है। + +अधिक जानकारी के साथ, आप यह कर सकते हैं: + +* समझें कि उपयोगकर्ता किसी नई सुविधा पर कैसे प्रतिक्रिया देते हैं +* पता लगाएं कि नए उपयोगकर्ता कहां से आते हैं +* बाहरी उपयोग के मामले या कार्यक्षमता को पहचानें और निर्णय लें कि इसका समर्थन करना है या नहीं +* अपने प्रोजेक्ट की लोकप्रियता का आकलन करें +* समझें कि आपके प्रोजेक्ट का उपयोग कैसे किया जाता है +* प्रायोजन और अनुदान के माध्यम से धन जुटाएं + +उदाहरण के लिए, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) ने पाया कि Google Analytics उन्हें काम को प्राथमिकता देने में मदद करता है: + +> होमब्रू निःशुल्क प्रदान किया जाता है और इसे पूरी तरह से स्वयंसेवकों द्वारा अपने खाली समय में चलाया जाता है। परिणामस्वरूप, हमारे पास भविष्य की सुविधाओं को सर्वोत्तम तरीके से डिज़ाइन करने और वर्तमान कार्य को प्राथमिकता देने के तरीके पर निर्णय लेने के लिए होमब्रू उपयोगकर्ताओं का विस्तृत उपयोगकर्ता अध्ययन करने के लिए संसाधन नहीं हैं। अनाम समग्र उपयोगकर्ता विश्लेषण हमें लोग होमब्रू का उपयोग कैसे, कहां और कब करते हैं, इसके आधार पर सुधारों और सुविधाओं को प्राथमिकता देने की अनुमति देते हैं। + +लोकप्रियता ही सब कुछ नहीं है. हर कोई अलग-अलग कारणों से खुले स्रोत में आ जाता है। यदि एक ओपन सोर्स अनुरक्षक के रूप में आपका लक्ष्य अपना काम दिखाना है, अपने कोड के बारे में पारदर्शी होना है, या सिर्फ मनोरंजन करना है, तो मेट्रिक्स आपके लिए महत्वपूर्ण नहीं हो सकते हैं। + +यदि आप अपने प्रोजेक्ट को गहराई से समझने में रुचि रखते हैं, तो अपने प्रोजेक्ट की गतिविधि का विश्लेषण करने के तरीकों के लिए आगे पढ़ें। + +## खोज + +इससे पहले कि कोई भी आपके प्रोजेक्ट का उपयोग कर सके या उसमें योगदान कर सके, उन्हें यह जानना होगा कि यह मौजूद है। अपने आप से पूछें: _क्या लोगों को यह प्रोजेक्ट मिल रहा है?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://help.github.com/articles/about-repository-graphs/#traffic) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं: + +* **कुल पृष्ठ दृश्य:** आपको बताता है कि आपका प्रोजेक्ट कितनी बार देखा गया + +* **कुल अद्वितीय विज़िटर:** आपको बताता है कि कितने लोगों ने आपका प्रोजेक्ट देखा + +* **रेफ़रिंग साइटें:** आपको बताती हैं कि विज़िटर कहाँ से आए। यह मीट्रिक आपको यह पता लगाने में मदद कर सकता है कि आपको अपने दर्शकों तक कहां पहुंचना है और क्या आपके प्रचार प्रयास काम कर रहे हैं। + +* **लोकप्रिय सामग्री:** आपको बताती है कि विज़िटर आपके प्रोजेक्ट पर कहां जाते हैं, पृष्ठ दृश्य और अद्वितीय विज़िटर के आधार पर। + +[गिटहब सितारे](https://help.github.com/articles/about-stars/) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं। + +आप भी चाहते होंगे [tविशिष्ट स्थानों में रैक खोज योग्यता](https://opensource.com/business/16/6/pirate-metrics): उदाहरण के लिए, Google पेजरैंक, आपके प्रोजेक्ट की वेबसाइट से रेफरल ट्रैफ़िक, या अन्य ओपन सोर्स प्रोजेक्ट या वेबसाइट से रेफरल। + +## उपयोग + +लोग आपके प्रोजेक्ट को इस जंगली और पागलपन वाली चीज़ पर ढूंढ रहे हैं जिसे हम इंटरनेट कहते हैं। आदर्श रूप से, जब वे आपका प्रोजेक्ट देखेंगे, तो वे कुछ करने के लिए मजबूर महसूस करेंगे। दूसरा प्रश्न जो आप पूछना चाहेंगे वह है: _क्या लोग इस परियोजना का उपयोग कर रहे हैं?_ + +यदि आप अपने प्रोजेक्ट को वितरित करने के लिए npm या RubyGems.org जैसे पैकेज मैनेजर का उपयोग करते हैं, तो आप अपने प्रोजेक्ट के डाउनलोड को ट्रैक करने में सक्षम हो सकते हैं। + +प्रत्येक पैकेज प्रबंधक "डाउनलोड" की थोड़ी अलग परिभाषा का उपयोग कर सकता है, और डाउनलोड आवश्यक रूप से इंस्टॉल या उपयोग से संबंधित नहीं है, लेकिन यह तुलना के लिए कुछ आधार रेखा प्रदान करता है। कई लोकप्रिय पैकेज प्रबंधकों में उपयोग के आंकड़ों को ट्रैक करने के लिए [Libraries.io](https://libraries.io/) का उपयोग करने का प्रयास करें। + +यदि आपका प्रोजेक्ट GitHub पर है, तो "ट्रैफ़िक" पृष्ठ पर फिर से नेविगेट करें। आप यह देखने के लिए [क्लोन ग्राफ](https://github.com/blog/1873-clone-graphs) का उपयोग कर सकते हैं कि आपके प्रोजेक्ट को किसी दिए गए दिन में कितनी बार क्लोन किया गया है, कुल क्लोन और अद्वितीय क्लोनर्स द्वारा विभाजित किया गया है। + +![क्लोन ग्राफ़](/assets/images/metrics/clone_graph.png) + +यदि आपके प्रोजेक्ट को खोजने वाले लोगों की संख्या की तुलना में उपयोग कम है, तो विचार करने के लिए दो मुद्दे हैं। दोनों में से एक: + +* आपका प्रोजेक्ट आपके दर्शकों को सफलतापूर्वक परिवर्तित नहीं कर रहा है, या +* आप गलत दर्शकों को आकर्षित कर रहे हैं + +उदाहरण के लिए, यदि आपका प्रोजेक्ट हैकर न्यूज़ के पहले पन्ने पर आता है, तो आपको संभवतः खोज (ट्रैफ़िक) में वृद्धि दिखाई देगी, लेकिन रूपांतरण दर कम होगी, क्योंकि आप हैकर न्यूज़ पर सभी तक पहुंच रहे हैं। हालाँकि, यदि आपका रूबी प्रोजेक्ट रूबी सम्मेलन में प्रदर्शित किया गया है, तो आपको लक्षित दर्शकों से उच्च रूपांतरण दर देखने की अधिक संभावना है। + +यह पता लगाने का प्रयास करें कि आपके दर्शक कहां से आ रहे हैं और अपने प्रोजेक्ट पेज पर दूसरों से फीडबैक मांगें ताकि यह पता चल सके कि आप इन दोनों में से किस समस्या का सामना कर रहे हैं। + +एक बार जब आप जान जाते हैं कि लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं, तो आप यह पता लगाने की कोशिश करना चाहेंगे कि वे इसके साथ क्या कर रहे हैं। क्या वे आपके कोड को फोर्क करके और सुविधाएँ जोड़कर इस पर निर्माण कर रहे हैं? क्या वे इसका उपयोग विज्ञान या व्यवसाय के लिए कर रहे हैं? + +## अवधारण + +लोगों को आपका प्रोजेक्ट मिल रहा है और वे इसका उपयोग कर रहे हैं। अगला प्रश्न जो आप स्वयं से पूछना चाहेंगे वह है: _क्या लोग इस परियोजना में योगदान दे रहे हैं?_ + +योगदानकर्ताओं के बारे में सोचना शुरू करना कभी भी जल्दी नहीं है। अन्य लोगों के हस्तक्षेप के बिना, आप अपने आप को एक अस्वस्थ स्थिति में डालने का जोखिम उठाते हैं जहां आपका प्रोजेक्ट लोकप्रिय है (कई लोग इसका उपयोग करते हैं) लेकिन समर्थित नहीं है (मांग को पूरा करने के लिए रखरखाव के लिए पर्याप्त समय नहीं है)। + +प्रतिधारण के लिए [नए योगदानकर्ताओं की आमद](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), की भी आवश्यकता होती है, चूँकि पहले सक्रिय योगदानकर्ता अंततः अन्य चीज़ों की ओर बढ़ेंगे। + +सामुदायिक मेट्रिक्स के उदाहरण जिन्हें आप नियमित रूप से ट्रैक करना चाहते हैं उनमें शामिल हैं: + +* **कुल योगदानकर्ता संख्या और प्रति योगदानकर्ता प्रतिबद्धताओं की संख्या:** आपको बताता है कि आपके पास कितने योगदानकर्ता हैं, और कौन कम या ज्यादा सक्रिय है। GitHub पर, आप इसे "अंतर्दृष्टि" -> "योगदानकर्ता" के अंतर्गत देख सकते हैं। अभी, यह ग्राफ़ केवल उन योगदानकर्ताओं की गणना करता है जिन्होंने रिपॉजिटरी की डिफ़ॉल्ट शाखा के लिए प्रतिबद्ध किया है। + +![योगदानकर्ता ग्राफ](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **पहली बार, आकस्मिक और बार-बार योगदान देने वाले:** आपको यह ट्रैक करने में मदद करता है कि क्या आपको नए योगदानकर्ता मिल रहे हैं, और क्या वे वापस आते हैं। (आकस्मिक योगदानकर्ता कम संख्या में कमिट वाले योगदानकर्ता होते हैं। चाहे वह एक कमिट हो, पांच से कम कमिट हो, या कुछ और यह आप पर निर्भर है।) नए योगदानकर्ताओं के बिना, आपके प्रोजेक्ट का समुदाय स्थिर हो सकता है। + +* **खुले मुद्दों और खुले पुल अनुरोधों की संख्या:** यदि ये संख्या बहुत अधिक हो जाती है, तो आपको समस्या परीक्षण और कोड समीक्षा में मदद की आवश्यकता हो सकती है। + +* **_खुले हुए_ मुद्दों और _खुले_पुल अनुरोधों की संख्या:** खुले हुए मुद्दों का मतलब है कि किसी को आपके प्रोजेक्ट की इतनी परवाह है कि वह किसी मुद्दे को खोल सके। यदि वह संख्या समय के साथ बढ़ती है, तो यह दर्शाता है कि लोग आपके प्रोजेक्ट में रुचि रखते हैं। + +* **योगदान के प्रकार:** उदाहरण के लिए, कमिट करना, टाइपो या बग को ठीक करना, या किसी मुद्दे पर टिप्पणी करना। + + + +## अनुरक्षक गतिविधि + +अंत में, आप यह सुनिश्चित करके लूप को बंद करना चाहेंगे कि आपके प्रोजेक्ट के अनुरक्षक प्राप्त योगदान की मात्रा को संभालने में सक्षम हैं। आखिरी सवाल जो आप खुद से पूछना चाहेंगे वह है: _क्या मैं (या हम) अपने समुदाय को जवाब दे रहे हैं?_ + +अनुत्तरदायी अनुरक्षक खुले स्रोत परियोजनाओं के लिए एक बाधा बन जाते हैं। यदि कोई योगदान जमा करता है लेकिन रखरखावकर्ता से कभी जवाब नहीं मिलता है, तो वे निराश महसूस कर सकते हैं और छोड़ सकते हैं। + +[मोज़िला से अनुसंधान](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) सुझाव देता है कि बार-बार योगदान को प्रोत्साहित करने में अनुरक्षक प्रतिक्रिया एक महत्वपूर्ण कारक है। + +विचार करना [यह ट्रैक करना कि आपको (या किसी अन्य अनुरक्षक को) योगदान का जवाब देने में कितना समय लगता है](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), चाहे कोई समस्या हो या पुल अनुरोध। प्रतिक्रिया देने के लिए कार्रवाई की आवश्यकता नहीं है. यह कहने जितना सरल हो सकता है: _"आपके सबमिशन के लिए धन्यवाद! मैं अगले सप्ताह के भीतर इसकी समीक्षा करूंगा।"_ + +आप योगदान प्रक्रिया के चरणों के बीच लगने वाले समय को भी माप सकते हैं, जैसे: + +* किसी अंक के खुले रहने का औसत समय +* क्या मुद्दे पीआर द्वारा बंद कर दिए जाते हैं +* क्या बासी मुद्दे बंद हो जाते हैं +* पुल अनुरोध को मर्ज करने का औसत समय + +## लोगों के बारे में जानने के लिए 📊 का प्रयोग करें + +मेट्रिक्स को समझने से आपको एक सक्रिय, बढ़ता हुआ ओपन सोर्स प्रोजेक्ट बनाने में मदद मिलेगी। भले ही आप डैशबोर्ड पर प्रत्येक मीट्रिक को ट्रैक नहीं करते हैं, फिर भी अपना ध्यान उस प्रकार के व्यवहार पर केंद्रित करने के लिए उपरोक्त ढांचे का उपयोग करें जो आपके प्रोजेक्ट को आगे बढ़ाने में मदद करेगा। + +[CHAOSS](https://chaoss.community/) एक स्वागतयोग्य, खुला स्रोत समुदाय है जो सामुदायिक स्वास्थ्य के लिए एनालिटिक्स, मेट्रिक्स और सॉफ्टवेयर पर केंद्रित है। diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md new file mode 100644 index 00000000000..e1eb3ed63c0 --- /dev/null +++ b/_articles/hi/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: hi +title: एक ओपन सोर्स प्रोजेक्ट शुरू करना +description: ओपन सोर्स की दुनिया के बारे में और जानें और अपना खुद का प्रोजेक्ट लॉन्च करने के लिए तैयार हो जाएं। +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## खुले स्रोत का "क्या" और "क्यों"। + +तो क्या आप ओपन सोर्स के साथ शुरुआत करने के बारे में सोच रहे हैं? बधाई हो! दुनिया आपके योगदान की सराहना करती है. आइए बात करें कि ओपन सोर्स क्या है और लोग ऐसा क्यों करते हैं। + +### "ओपन सोर्स" का क्या मतलब है? + +जब कोई प्रोजेक्ट ओपन सोर्स होता है, तो इसका मतलब है कि **कोई भी किसी भी उद्देश्य के लिए आपके प्रोजेक्ट का उपयोग, अध्ययन, संशोधन और वितरण करने के लिए स्वतंत्र है।** ये अनुमतियाँ [एक ओपन सोर्स लाइसेंस](https://opensource.org/licenses) के माध्यम से लागू की जाती हैं। + +खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है। + +_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#does-open-source-mean-free-of-charge)। + +### लोग अपना काम ओपन सोर्स क्यों करते हैं? + + + +[इसके कई कारण हैं](https://ben.balter.com/2015/11/23/why-open-source/) कोई व्यक्ति या संगठन किसी प्रोजेक्ट को ओपन सोर्स क्यों करना चाहेगा। कुछ उदाहरणों में शामिल हैं: + +* **सहयोग:** ओपन सोर्स प्रोजेक्ट दुनिया में किसी से भी बदलाव स्वीकार कर सकते हैं। [व्यायाम](https://github.com/exercism/), उदाहरण के लिए, 350 से अधिक योगदानकर्ताओं वाला एक प्रोग्रामिंग अभ्यास मंच है। + +* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Transparency:** Anyone can inspect an open source project for errors or असंगतियाँ जैसी सरकारों के लिए पारदर्शिता मायने रखती है [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या[United States](https://sourcecode.cio.gov/), बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योग और सुरक्षा सॉफ्टवेयर जैसे [Let's Encrypt](https://github.com/letsencrypt). + +ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें। + +### क्या ओपन सोर्स का मतलब "निःशुल्क" है? + +ओपन सोर्स का सबसे बड़ा आकर्षण यह है कि इसमें पैसा खर्च नहीं होता है। हालाँकि, "निःशुल्क", खुले स्रोत के समग्र मूल्य का एक उपोत्पाद है। + +क्योंकि [एक ओपन सोर्स लाइसेंस के लिए आवश्यक है](https://opensource.org/osd-annotated) कि कोई भी आपके प्रोजेक्ट को लगभग किसी भी उद्देश्य के लिए उपयोग, संशोधित और साझा कर सकता है, प्रोजेक्ट स्वयं निःशुल्क होते हैं। यदि प्रोजेक्ट के उपयोग में पैसे खर्च होते हैं, तो कोई भी कानूनी तौर पर इसकी प्रतिलिपि बना सकता है और इसके बजाय मुफ़्त संस्करण का उपयोग कर सकता है। + +परिणामस्वरूप, अधिकांश ओपन सोर्स प्रोजेक्ट मुफ़्त हैं, लेकिन "निःशुल्क" ओपन सोर्स परिभाषा का हिस्सा नहीं है। ओपन सोर्स की आधिकारिक परिभाषा का अनुपालन करते हुए, दोहरे लाइसेंसिंग या सीमित सुविधाओं के माध्यम से अप्रत्यक्ष रूप से ओपन सोर्स परियोजनाओं के लिए शुल्क लेने के कई तरीके हैं। + +## क्या मुझे अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना चाहिए? + +संक्षिप्त उत्तर हां है, क्योंकि परिणाम चाहे जो भी हो, अपना खुद का प्रोजेक्ट लॉन्च करना यह सीखने का एक शानदार तरीका है कि ओपन सोर्स कैसे काम करता है। + +यदि आपने पहले कभी कोई प्रोजेक्ट ओपन सोर्स नहीं किया है, तो आप इस बात से घबरा सकते हैं कि लोग क्या कहेंगे, या कोई नोटिस करेगा या नहीं। यदि यह आपके जैसा लगता है, तो आप अकेले नहीं हैं! + +ओपन सोर्स कार्य किसी भी अन्य रचनात्मक गतिविधि की तरह है, चाहे वह लेखन हो या पेंटिंग। अपने काम को दुनिया के साथ साझा करना डरावना लग सकता है, लेकिन बेहतर होने का एकमात्र तरीका अभ्यास करना है - भले ही आपके पास दर्शक न हों। + +यदि आप अभी तक आश्वस्त नहीं हैं, तो एक क्षण रुककर सोचें कि आपके लक्ष्य क्या हो सकते हैं। + +### अपने लक्ष्य निर्धारित करना + +लक्ष्य आपको यह पता लगाने में मदद कर सकते हैं कि किस पर काम करना है, किस चीज़ को ना कहना है और आपको कहाँ दूसरों से मदद की ज़रूरत है। अपने आप से यह पूछकर शुरुआत करें, _मैं इस प्रोजेक्ट का ओपन सोर्सिंग क्यों कर रहा हूँ?_ + +इस प्रश्न का कोई भी सही उत्तर नहीं है। आपके पास एक ही प्रोजेक्ट के लिए कई लक्ष्य हो सकते हैं, या अलग-अलग लक्ष्यों वाली अलग-अलग परियोजनाएँ हो सकती हैं। + +यदि आपका एकमात्र लक्ष्य अपना काम दिखाना है, तो हो सकता है कि आप योगदान भी न चाहें, और अपने README में ऐसा कहें भी नहीं। दूसरी ओर, यदि आप योगदानकर्ता चाहते हैं, तो आप स्पष्ट दस्तावेज़ीकरण और नए लोगों का स्वागत महसूस कराने में समय लगाएंगे। + + + +जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, आपके समुदाय को आपसे कोड के अलावा और भी बहुत कुछ की आवश्यकता हो सकती है। मुद्दों पर प्रतिक्रिया देना, कोड की समीक्षा करना और अपने प्रोजेक्ट का प्रचार-प्रसार करना एक ओपन सोर्स प्रोजेक्ट में सभी महत्वपूर्ण कार्य हैं। + +जबकि आप गैर-कोडिंग कार्यों पर कितना समय बिताएंगे, यह आपके प्रोजेक्ट के आकार और दायरे पर निर्भर करेगा, आपको उन्हें स्वयं संबोधित करने या आपकी सहायता के लिए किसी को ढूंढने के लिए एक अनुरक्षक के रूप में तैयार रहना चाहिए। + +**यदि आप किसी प्रोजेक्ट की ओपन सोर्सिंग करने वाली कंपनी का हिस्सा हैं,**सुनिश्चित करें कि आपके प्रोजेक्ट के पास आंतरिक संसाधन हैं जो उसे आगे बढ़ाने के लिए आवश्यक हैं। आप यह पहचानना चाहेंगे कि लॉन्च के बाद प्रोजेक्ट को बनाए रखने के लिए कौन ज़िम्मेदार है, और आप उन कार्यों को अपने समुदाय के साथ कैसे साझा करेंगे। + +यदि आपको परियोजना के प्रचार, संचालन और रखरखाव के लिए समर्पित बजट या स्टाफिंग की आवश्यकता है, तो बातचीत जल्दी शुरू करें। + + + +### अन्य परियोजनाओं में योगदान देना + +यदि आपका लक्ष्य यह सीखना है कि दूसरों के साथ कैसे सहयोग करें या यह समझें कि ओपन सोर्स कैसे काम करता है, तो किसी मौजूदा प्रोजेक्ट में योगदान देने पर विचार करें। उस प्रोजेक्ट से शुरुआत करें जिसे आप पहले से ही उपयोग करते हैं और पसंद करते हैं। किसी प्रोजेक्ट में योगदान देना टाइप की त्रुटियों को ठीक करने या दस्तावेज़ीकरण को अपडेट करने जितना आसान हो सकता है। + +यदि आप निश्चित नहीं हैं कि योगदानकर्ता के रूप में शुरुआत कैसे करें, तो हमारी जाँच करें [ओपन सोर्स गाइड में योगदान कैसे करें](../how-to-contribute/). + +## अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना + +अपने काम का स्रोत खोलने का कोई सही समय नहीं है। आप किसी विचार का स्रोत खोल सकते हैं, कोई कार्य प्रगति पर है, या वर्षों तक बंद स्रोत रहने के बाद। + +आम तौर पर कहें तो, आपको अपने प्रोजेक्ट को तब ओपन सोर्स करना चाहिए जब आप दूसरों को अपने काम को देखने और उस पर फीडबैक देने में सहज महसूस करें। + +इससे कोई फर्क नहीं पड़ता कि आप अपने प्रोजेक्ट को किस चरण में खोलने का निर्णय लेते हैं, प्रत्येक प्रोजेक्ट में निम्नलिखित दस्तावेज़ शामिल होने चाहिए: + +* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +एक अनुरक्षक के रूप में, ये घटक आपको अपेक्षाओं को संप्रेषित करने, योगदान प्रबंधित करने और सभी के कानूनी अधिकारों (आपके अपने अधिकारों सहित) की रक्षा करने में मदद करेंगे। वे आपके सकारात्मक अनुभव प्राप्त करने की संभावनाओं को उल्लेखनीय रूप से बढ़ा देते हैं। + +यदि आपका प्रोजेक्ट GitHub पर है, तो इन फ़ाइलों को अनुशंसित फ़ाइल नामों के साथ अपनी रूट निर्देशिका में डालने से GitHub को उन्हें पहचानने और स्वचालित रूप से आपके पाठकों के सामने लाने में मदद मिलेगी। + +### लाइसेंस चुनना + +एक ओपन सोर्स लाइसेंस यह गारंटी देता है कि अन्य लोग बिना किसी प्रभाव के आपके प्रोजेक्ट का उपयोग, प्रतिलिपि, संशोधन और योगदान कर सकते हैं। यह आपको जटिल कानूनी स्थितियों से भी बचाता है। **ओपन सोर्स प्रोजेक्ट लॉन्च करते समय आपको एक लाइसेंस शामिल करना होगा।** + +क़ानूनी काम कोई मज़ेदार नहीं है. अच्छी खबर यह है कि आप मौजूदा लाइसेंस को कॉपी करके अपने रिपॉजिटरी में पेस्ट कर सकते हैं। आपकी मेहनत की रक्षा करने में केवल एक मिनट लगेगा। + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), और [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन [अन्य विकल्प भी हैं](https://choosealicense.com). + +जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ओपन सोर्स लाइसेंस शामिल करने से आपका GitHub प्रोजेक्ट ओपन सोर्स बन जाएगा। + +![एक लाइसेंस चुनें](/assets/images/starting-a-project/repository-license-picker.png) + +यदि आपके पास ओपन सोर्स प्रोजेक्ट के प्रबंधन के कानूनी पहलुओं के बारे में अन्य प्रश्न या चिंताएं हैं, [हमने आपका ध्यान रखा है](../legal/). + +### एक रीडमी लिखना + +READMEs आपके प्रोजेक्ट का उपयोग कैसे करें यह समझाने के अलावा और भी बहुत कुछ करते हैं। वे यह भी बताते हैं कि आपका प्रोजेक्ट क्यों मायने रखता है, और आपके उपयोगकर्ता इसके साथ क्या कर सकते हैं। + +अपने README में निम्नलिखित प्रश्नों के उत्तर देने का प्रयास करें: + +* यह प्रोजेक्ट क्या करता है? +* यह प्रोजेक्ट उपयोगी क्यों है? +* मैं कैसे शुरू करूँ? +* यदि मुझे आवश्यकता हो तो मुझे और सहायता कहां से मिल सकती है? + +आप अपने README का उपयोग अन्य प्रश्नों के उत्तर देने के लिए कर सकते हैं, जैसे कि आप योगदान कैसे संभालते हैं, परियोजना के लक्ष्य क्या हैं, और लाइसेंस और एट्रिब्यूशन के बारे में जानकारी। यदि आप योगदान स्वीकार नहीं करना चाहते हैं, या आपका प्रोजेक्ट अभी तक उत्पादन के लिए तैयार नहीं है, तो इस जानकारी को लिख लें। + + + +कभी-कभी, लोग README लिखने से बचते हैं क्योंकि उन्हें लगता है कि परियोजना अधूरी है, या वे योगदान नहीं चाहते हैं। इसे लिखने के ये सभी बहुत अच्छे कारण हैं। + +अधिक प्रेरणा के लिए, @dguo's का ["एक README बनाएं" मार्गदर्शिका](https://www.makeareadme.com/) उपयोग करने का प्रयास करें या @PurpleBooth's [README टेम्पलेट](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) संपूर्ण README लिखने के लिए। + +जब आप रूट डायरेक्टरी में एक README फ़ाइल शामिल करते हैं, तो GitHub स्वचालित रूप से इसे रिपॉजिटरी होमपेज पर प्रदर्शित करेगा। + +### अपने योगदान संबंधी दिशानिर्देश लिखना + +एक योगदान फ़ाइल आपके दर्शकों को बताती है कि आपके प्रोजेक्ट में कैसे भाग लेना है। उदाहरण के लिए, आप निम्न पर जानकारी शामिल कर सकते हैं: + +* बग रिपोर्ट कैसे दर्ज करें ([इश्यू और पुल रिक्वेस्ट टेम्प्लेट्स का उपयोग](https://github.com/blog/2111-issue-and-pull-request-templates)) करने का प्रयास करें। +* नई सुविधा का सुझाव कैसे दें +* अपना वातावरण कैसे स्थापित करें और परीक्षण कैसे चलाएं + +तकनीकी विवरण के अलावा, योगदान फ़ाइल योगदान के लिए आपकी अपेक्षाओं को संप्रेषित करने का एक अवसर है, जैसे: + +* आप जिस प्रकार के योगदान की तलाश कर रहे हैं +* परियोजना के लिए आपका रोडमैप या विज़न +* योगदानकर्ताओं को आपसे कैसे संपर्क करना चाहिए (या नहीं करना चाहिए)। + +गर्मजोशीपूर्ण, मैत्रीपूर्ण लहजे का उपयोग करना और योगदान के लिए विशिष्ट सुझाव देना (जैसे दस्तावेज़ लिखना, या वेबसाइट बनाना) नवागंतुकों को भाग लेने के लिए स्वागत और उत्साहित महसूस कराने में काफी मदद कर सकता है। + +उदाहरण के लिए, [सक्रिय व्यवस्थापक](https://github.com/activeadmin/activeadmin/) प्रारंभ होता है [इसकी योगदान मार्गदर्शिका](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) के साथ: + +> सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं। + +आपके प्रोजेक्ट के शुरुआती चरणों में, आपकी CONTRIBUTING फ़ाइल सरल हो सकती है। योगदान देने के लिए आपको हमेशा यह समझाना चाहिए कि बग या फ़ाइल समस्याओं की रिपोर्ट कैसे करें, और कोई तकनीकी आवश्यकताएं (जैसे परीक्षण) कैसे करें। + +समय के साथ, आप अपनी योगदान फ़ाइल में अन्य अक्सर पूछे जाने वाले प्रश्न जोड़ सकते हैं। इस जानकारी को लिखने का मतलब है कि कम लोग आपसे वही प्रश्न बार-बार पूछेंगे। + +अपनी CONTRIBUTING फ़ाइल लिखने में अधिक सहायता के लिए, देखें @nayafia's [contributing गाइड टेम्पलेट](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) या @mozilla's ["CONTRIBUTING.md कैसे बनाएं।"](https://mozillascience.github.io/working-open-workshop/contributing/). + +अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा। + +![योगदान दिशानिर्देश](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### आचार संहिता की स्थापना + + + +अंत में, एक आचार संहिता आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार के लिए बुनियादी नियम निर्धारित करने में मदद करती है। यह विशेष रूप से मूल्यवान है यदि आप किसी समुदाय या कंपनी के लिए एक ओपन सोर्स प्रोजेक्ट लॉन्च कर रहे हैं। आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार की सुविधा प्रदान करने का अधिकार देती है, जो एक अनुरक्षक के रूप में आपके तनाव को कम करेगा। + +अधिक जानकारी के लिए, हमारी जाँच करें [आचार संहिता मार्गदर्शिका](../code-of-conduct/). + +यह बताने के अलावा कि आप प्रतिभागियों से कैसे व्यवहार करने की अपेक्षा करते हैं, आचार संहिता यह भी बताती है कि ये अपेक्षाएं किस पर लागू होती हैं, कब लागू होती हैं और उल्लंघन होने पर क्या करना चाहिए। + +ओपन सोर्स लाइसेंस की तरह, आचार संहिता के लिए भी उभरते मानक हैं, इसलिए आपको अपना खुद का लिखने की ज़रूरत नहीं है। [योगदानकर्ता वाचा](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग [40,000 से अधिक ओपन सोर्स प्रोजेक्ट्स](https://www.contributor-covenant.org/adopters) द्वारा किया जाता है। कुबेरनेट्स, रेल्स और स्विफ्ट सहित। इससे कोई फर्क नहीं पड़ता कि आप किस पाठ का उपयोग करते हैं, आपको आवश्यकता पड़ने पर अपनी आचार संहिता लागू करने के लिए तैयार रहना चाहिए। + +टेक्स्ट को सीधे अपने रिपॉजिटरी में एक Code_OF_CONDUCT फ़ाइल में पेस्ट करें। फ़ाइल को अपने प्रोजेक्ट की रूट डायरेक्टरी में रखें ताकि इसे ढूंढना आसान हो, और इसे अपने README से लिंक करें। + +## अपने प्रोजेक्ट का नामकरण और ब्रांडिंग करना + +ब्रांडिंग एक आकर्षक लोगो या आकर्षक प्रोजेक्ट नाम से कहीं अधिक है। यह इस बारे में है कि आप अपने प्रोजेक्ट के बारे में कैसे बात करते हैं, और आप अपना संदेश किस तक पहुंचाते हैं। + +### सही नाम चुनना + +ऐसा नाम चुनें जो याद रखने में आसान हो और, आदर्श रूप से, प्रोजेक्ट क्या करता है, इसका कुछ अंदाज़ा देता हो। उदाहरण के लिए: + +* [Sentry](https://github.com/getsentry/sentry) क्रैश रिपोर्टिंग के लिए ऐप्स पर नज़र रखता है +* [Thin](https://github.com/macournoyer/thin) एक तेज़ और सरल रूबी वेब सर्वर है + +यदि आप किसी मौजूदा प्रोजेक्ट पर निर्माण कर रहे हैं, तो उपसर्ग के रूप में उनके नाम का उपयोग करने से यह स्पष्ट करने में मदद मिल सकती है कि आपका प्रोजेक्ट क्या करता है (उदाहरण के लिए, [node-fetch](https://github.com/bitinn/node-fetch) window.fetch` को Node.js पर लाता है)। + +स्पष्टता को सर्वोपरि मानें। चुटकुले मजेदार हैं, लेकिन याद रखें कि कुछ चुटकुले अन्य संस्कृतियों या आपसे अलग अनुभव वाले लोगों पर लागू नहीं हो सकते हैं। आपके कुछ संभावित उपयोगकर्ता कंपनी के कर्मचारी हो सकते हैं: जब उन्हें कार्यस्थल पर आपके प्रोजेक्ट के बारे में बताना हो तो आप उन्हें असहज नहीं करना चाहेंगे! + +### नाम टकराव से बचना + +[समान नाम वाले ओपन सोर्स प्रोजेक्ट की जांच करें](http://ivantomic.com/projects/ospnc/), खासकर यदि आप एक ही भाषा या पारिस्थितिकी तंत्र साझा करते हैं। यदि आपका नाम किसी लोकप्रिय मौजूदा प्रोजेक्ट से मेल खाता है, तो आप अपने दर्शकों को भ्रमित कर सकते हैं। + +यदि आप अपने प्रोजेक्ट का प्रतिनिधित्व करने के लिए एक वेबसाइट, ट्विटर हैंडल या अन्य संपत्तियां चाहते हैं, तो सुनिश्चित करें कि आपको अपने इच्छित नाम मिल सकें। आदर्श रूप से, मन की शांति के लिए [अभी उन नामों को आरक्षित करें](https://instantdomainsearch.com/), भले ही आप अभी उनका उपयोग करने का इरादा नहीं रखते हों। + +सुनिश्चित करें कि आपके प्रोजेक्ट का नाम किसी भी ट्रेडमार्क का उल्लंघन नहीं करता है। कोई कंपनी बाद में आपसे अपना प्रोजेक्ट वापस लेने के लिए कह सकती है, या आपके खिलाफ कानूनी कार्रवाई भी कर सकती है। यह जोखिम के लायक ही नहीं है। + +आप ट्रेडमार्क विवादों के लिए [WIPO ग्लोबल ब्रांड डेटाबेस](http://www.wipo.int/branddb/en/) की जांच कर सकते हैं। यदि आप किसी कंपनी में हैं, तो यह उन चीजों में से एक है जिसमें आपकी [कानूनी टीम आपकी मदद कर सकती है।](../legal/) + +अंत में, अपने प्रोजेक्ट के नाम के लिए त्वरित Google खोज करें। क्या लोग आपका प्रोजेक्ट आसानी से ढूंढ पाएंगे? क्या खोज परिणामों में कुछ और दिखाई देता है जो आप नहीं चाहेंगे कि वे देखें? + +### आप कैसे लिखते हैं (और कोड) आपके ब्रांड को भी प्रभावित करता है! + +अपने प्रोजेक्ट के पूरे जीवनकाल में, आप बहुत सारा लेखन करेंगे: रीडमी, ट्यूटोरियल, सामुदायिक दस्तावेज़, मुद्दों पर प्रतिक्रिया देना, शायद न्यूज़लेटर और मेलिंग सूचियाँ भी। + +चाहे वह आधिकारिक दस्तावेज हो या कोई आकस्मिक ईमेल, आपकी लेखन शैली आपके प्रोजेक्ट के ब्रांड का हिस्सा है। इस बात पर विचार करें कि आप अपने दर्शकों के सामने कैसे आ सकते हैं और क्या आप यही लहजा बताना चाहते हैं। + + + +गर्मजोशीपूर्ण, समावेशी भाषा (जैसे कि "उन्हें", यहां तक ​​कि जब एक व्यक्ति का जिक्र हो) का उपयोग करना आपके प्रोजेक्ट को नए योगदानकर्ताओं का स्वागत करने में काफी मदद कर सकता है। सरल भाषा पर कायम रहें, क्योंकि हो सकता है कि आपके कई पाठक मूल अंग्रेजी बोलने वाले न हों। + +शब्दों को लिखने के तरीके के अलावा, आपकी कोडिंग शैली भी आपके प्रोजेक्ट के ब्रांड का हिस्सा बन सकती है। [Angular](https://angular.io/guide/styleguide) और [jQuery](https://contribute.jquery.org/style-guide/js/) कठोर कोडिंग शैलियों और दिशानिर्देशों वाली परियोजनाओं के दो उदाहरण हैं। + +जब आप अभी शुरुआत कर रहे हों तो अपने प्रोजेक्ट के लिए स्टाइल गाइड लिखना आवश्यक नहीं है, और आप पाएंगे कि आप वैसे भी अपने प्रोजेक्ट में विभिन्न कोडिंग शैलियों को शामिल करने का आनंद लेते हैं। लेकिन आपको यह अनुमान लगाना चाहिए कि आपकी लेखन और कोडिंग शैली विभिन्न प्रकार के लोगों को कैसे आकर्षित या हतोत्साहित कर सकती है। आपके प्रोजेक्ट के शुरुआती चरण आपके लिए वह मिसाल कायम करने का अवसर हैं जो आप देखना चाहते हैं। + +## आपकी प्री-लॉन्च चेकलिस्ट + +क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://help.github.com/articles/making-a-private-repository-public/) और अपनी पीठ थपथपाएं। + +**दस्तावेज़ीकरण** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**लोग** + +यदि आप एक व्यक्ति हैं: + +
+ + +
+ +यदि आप एक कंपनी या संगठन हैं: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## तुमने यह किया! + +आपके पहले प्रोजेक्ट की ओपन सोर्सिंग के लिए बधाई। परिणाम चाहे जो भी हो, सार्वजनिक रूप से काम करना समुदाय के लिए एक उपहार है। प्रत्येक प्रतिबद्धता, टिप्पणी और अनुरोध के साथ, आप अपने लिए और दूसरों के लिए सीखने और बढ़ने के अवसर पैदा कर रहे हैं। diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml new file mode 100644 index 00000000000..076cf4e9203 --- /dev/null +++ b/_data/locales/hi.yml @@ -0,0 +1,32 @@ +hi: + locale_name: Hindi + nav: + about: बारे में + contribute: योगदान करें + index: + lead: ओपन सोर्स सॉफ़्टवेयर उन लोगों द्वारा बनाया जाता है जैसे कि आप। जानें कि आप कैसे अपने प्रोजेक्ट को शुरू कर सकते हैं और उसे बढ़ा सकते हैं। + opensourcefriday: यह शुक्रवार है! कुछ घंटे निवेश करके उन सॉफ़्टवेयर में योगदान करें जिन्हें आप उपयोग करते हैं और पसंद करते हैं + article: + table_of_contents: सामग्री की सूची + back_to_all_guides: सभी मार्गदर्शिकाओं पर वापस जाएं + related_guides: संबंधित मार्गदर्शिकाएं + footer: + contribute: + heading: योगदान करें + description: क्या आपका कोई सुझाव है? यह सामग्री ओपन सोर्स है। हमें इसे सुधारने में मदद करें। + button: योगदान करें + subscribe: + heading: संपर्क में रहें + description: गिटहब की नवीनतम ओपन सोर्स युक्तियों और संसाधनों की पहली जानकारी पाने के लिए पहले ही सुनें। + label: ईमेल पता + button: सदस्यता लें + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] के साथ [love] द्वारा [github] और [friends]" + # Label for code octicon + code_label: कोड + # Label for love octicon + love_label: प्रेम + # Label for the contributors link + friends_label: मित्र + diff --git a/node_modules/.package-lock.json b/node_modules/.package-lock.json new file mode 100644 index 00000000000..0cf4030726e --- /dev/null +++ b/node_modules/.package-lock.json @@ -0,0 +1,240 @@ +{ + "name": "open-source-guide", + "lockfileVersion": 3, + "requires": true, + "packages": { + "node_modules/primer-base": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-base/-/primer-base-2.0.0.tgz", + "integrity": "sha512-qqE3MiI1Zr7HgTO7NxguYHw4QrkRGOQjMPck1bFEZhNL36ey5PWJwqB68X7w6frOjA8tRid2joL99GBQhc1NnQ==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-base/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-box": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/primer-box/-/primer-box-3.0.0.tgz", + "integrity": "sha512-P6gUxgcC5Se2nPx4erHmj6JhqgBMxJDeJyuz5OS+SArWR0cydxi86Cf7mH4eNC+PebJQ91K+ddcxkU6w3vOEqw==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-box/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-breadcrumb": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-breadcrumb/-/primer-breadcrumb-2.0.0.tgz", + "integrity": "sha512-IhIQZ8HXZNnMh53qzl7JKDrUEAH4jPiqQ4WfxNrFwSoYUrQ7eGN3SJ9LD9oIjtmmO9DUUJhvmR0Cbr9OM1VB8w==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-breadcrumb/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-buttons": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/primer-buttons/-/primer-buttons-3.0.0.tgz", + "integrity": "sha512-oQX3FOCRrnSrhPFef5AvLkBV9og7W/U0GYPvu1FbXV+CDVauO8pC5hntQqvwa9w/VCptsJl2qpYSIFCQiH+f1g==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-buttons/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-core": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/primer-core/-/primer-core-7.0.0.tgz", + "integrity": "sha512-m7E5IddQpzV2Jtrlk9s513zmM7ZMtZUBDJ9Bckrz+67tPSvY74jqwfvwvkty/hLhQFPlM8p+c0fmmRTcO+vVIA==", + "dependencies": { + "primer-base": "2.0.0", + "primer-box": "3.0.0", + "primer-breadcrumb": "2.0.0", + "primer-buttons": "3.0.0", + "primer-forms": "3.0.0", + "primer-layout": "2.0.0", + "primer-navigation": "2.0.0", + "primer-pagination": "2.0.0", + "primer-support": "5.0.0", + "primer-table-object": "2.0.0", + "primer-tooltips": "2.0.0", + "primer-truncate": "2.0.0", + "primer-utilities": "5.0.0" + } + }, + "node_modules/primer-core/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-forms": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/primer-forms/-/primer-forms-3.0.0.tgz", + "integrity": "sha512-buKBHx1skjLmPgYvpFL5Xr3cbE9lxGkWS/h8lsuwL3ZCx5axHFu8MI+fKL6BY1EInRfbfk56d6Dn4QbC/ctInQ==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-forms/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-layout": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-layout/-/primer-layout-2.0.0.tgz", + "integrity": "sha512-lwRq5KDaErF4JecHnBr2h6D4Dqbfv28pFBafIOsPvIuMHDHmxNVqao1LRXC86ficL9V0aynlkmH8q6DqKnVPlw==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-layout/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-marketing": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/primer-marketing/-/primer-marketing-7.0.0.tgz", + "integrity": "sha512-gLIWiE3pW1rXEEnmfz2eekq4LC27QUeMccrG87EU5qyEnu8LMr59c5LRibc5EJaCsa4708Jd2WxxSXEfD0ieug==", + "dependencies": { + "primer-marketing-buttons": "2.0.0", + "primer-marketing-support": "2.0.0", + "primer-marketing-type": "2.0.0", + "primer-marketing-utilities": "2.0.0", + "primer-support": "5.0.0" + } + }, + "node_modules/primer-marketing-buttons": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-marketing-buttons/-/primer-marketing-buttons-2.0.0.tgz", + "integrity": "sha512-R8DvbvI6QjH9/xG2diqReqHhkMgKbiJ7+xg2VTlQon3H5sAxvUqBiqfqY+ZrZ9K5eyrLP+3Z/cgysKd/xe1U2A==", + "dependencies": { + "primer-marketing-support": "2.0.0", + "primer-support": "5.0.0" + } + }, + "node_modules/primer-marketing-support": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-marketing-support/-/primer-marketing-support-2.0.0.tgz", + "integrity": "sha512-HyYxwDVn9aGVN4wyXiIAzHrAgmoyNlXvZpRXh/UZRlA9EfZMxlCji3KhuMFzQFtYi+nXt7f/cTB5AX9YRnlVZg==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-marketing-type": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-marketing-type/-/primer-marketing-type-2.0.0.tgz", + "integrity": "sha512-c+bCjKVulTrRhjAHJ7pcaFYDUYiSecVFXMo6DkA9v5JvZ2cK/m4LySo5Eb2qbQmPBwLx6t/V1TnxD2cgKtdIDA==", + "dependencies": { + "primer-marketing-support": "2.0.0", + "primer-support": "5.0.0" + } + }, + "node_modules/primer-marketing-utilities": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-marketing-utilities/-/primer-marketing-utilities-2.0.0.tgz", + "integrity": "sha512-R2Y8uaOy44J9NtBNlLJKUrPKxtxv8svss3vP8YS4RRWISUSQGcjxRFPUX5ra8hqaenWO/NBbmeFVJXDwgrKu1A==", + "dependencies": { + "primer-marketing-support": "2.0.0", + "primer-support": "5.0.0" + } + }, + "node_modules/primer-navigation": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-navigation/-/primer-navigation-2.0.0.tgz", + "integrity": "sha512-yi45wDOuct/Wxp60hG74kfiNKsTluYmhsNelMBOy5WgTmnqtQy0l3d5NAQz/XdvEdiRrpres3LcPxs8GONO3sQ==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-navigation/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-pagination": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-pagination/-/primer-pagination-2.0.0.tgz", + "integrity": "sha512-+1BGHkNJoJtGVkfWi/IUP82MlShSrPJM1my6da1UnfcRBhONfk+7O3DXT7VLscXYk11rYsd/pGKZ8ZPH4DAvsw==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-pagination/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-table-object": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-table-object/-/primer-table-object-2.0.0.tgz", + "integrity": "sha512-ajCCvy93AwE8g62wS9Frw6kw1JM+gLCwMrr5N3ZXsu4lN1171782lnHcNBFdVzu0iFYiovH7CfQ0glVRNJVAbg==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-table-object/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-tooltips": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-tooltips/-/primer-tooltips-2.0.0.tgz", + "integrity": "sha512-cNF3r3hG6sXLr71GbYyJw3BXCBhspW4FjzJ0Hx/BO+lP3XCrNAX/wqd57+vvnWSuaLif2O8s3/Prs3VBF50hVQ==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-tooltips/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-truncate": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/primer-truncate/-/primer-truncate-2.0.0.tgz", + "integrity": "sha512-/rmXZCR/wQpOyQsp/vSY8sO/9IczidcFRN0iUg4oCUXgufNuh8IRHetYOGXwnlMiO5c9EkbNFJi/6jkFmRBd4g==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-truncate/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + }, + "node_modules/primer-utilities": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-utilities/-/primer-utilities-5.0.0.tgz", + "integrity": "sha512-HeMffBQLL2ygyPOUMccN43L9A/3HYsbDhs423Sr3Run1eW1ZvfTgCP3xh9P8Dh/dJt5qHFkekzBc4Y8qsZ3UtA==", + "dependencies": { + "primer-support": "5.0.0" + } + }, + "node_modules/primer-utilities/node_modules/primer-support": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/primer-support/-/primer-support-5.0.0.tgz", + "integrity": "sha512-inUxVSsGirn5IkPxBhFsMBgm8ZHyfOUmOWyDCN8cBXtbaLiCIAjHsPI46yS1zrWxnn0J2kvq8haomkrlHGF08g==" + } + } +}