From 88418b61286a3a6de96c4c25b17f3a8114f86c1b Mon Sep 17 00:00:00 2001 From: James Titus Date: Wed, 30 Aug 2023 20:42:55 +0530 Subject: [PATCH 01/25] initial commit hindi --- _data/locales/hi.yml | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 _data/locales/hi.yml diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml new file mode 100644 index 00000000000..84435d4d5fb --- /dev/null +++ b/_data/locales/hi.yml @@ -0,0 +1,32 @@ +hi: + locale_name: हिंदी + 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: मित्र + From ab3861d499291f08c23084af2d84978f2c11b069 Mon Sep 17 00:00:00 2001 From: James Titus Date: Wed, 30 Aug 2023 23:03:25 +0530 Subject: [PATCH 02/25] articles update --- _articles/hi/best-practices.md | 284 ++++++++++ _articles/hi/building-community.md | 279 ++++++++++ _articles/hi/code-of-conduct.md | 114 ++++ _articles/hi/finding-users.md | 148 +++++ _articles/hi/getting-paid.md | 178 ++++++ _articles/hi/how-to-contribute.md | 520 ++++++++++++++++++ _articles/hi/index.html | 5 + _articles/hi/leadership-and-governance.md | 156 ++++++ _articles/hi/legal.md | 158 ++++++ ...ing-balance-for-open-source-maintainers.md | 221 ++++++++ _articles/hi/metrics.md | 128 +++++ _articles/hi/starting-a-project.md | 356 ++++++++++++ 12 files changed, 2547 insertions(+) create mode 100644 _articles/hi/best-practices.md create mode 100644 _articles/hi/building-community.md create mode 100644 _articles/hi/code-of-conduct.md create mode 100644 _articles/hi/finding-users.md create mode 100644 _articles/hi/getting-paid.md create mode 100644 _articles/hi/how-to-contribute.md create mode 100644 _articles/hi/index.html create mode 100644 _articles/hi/leadership-and-governance.md create mode 100644 _articles/hi/legal.md create mode 100644 _articles/hi/maintaining-balance-for-open-source-maintainers.md create mode 100644 _articles/hi/metrics.md create mode 100644 _articles/hi/starting-a-project.md diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md new file mode 100644 index 00000000000..52982086e51 --- /dev/null +++ b/_articles/hi/best-practices.md @@ -0,0 +1,284 @@ +--- +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: _" +नहीं अस्थायी है, हाँ हमेशा के लिए है।"_ जबकि किसी अन्य व्यक्ति के उत्साह के साथ सहानुभूति रखना अच्छी बात है, किसी योगदान को अस्वीकार करना उसके पीछे वाले व्यक्ति को अस्वीकार करने के समान नहीं है। + +अंततः, यदि कोई योगदान पर्याप्त नहीं है, तो आप इसे स्वीकार करने के लिए बाध्य नहीं हैं। जब लोग आपके प्रोजेक्ट में योगदान दें तो दयालु और उत्तरदायी बनें, लेकिन केवल उन बदलावों को स्वीकार करें जिनके बारे में आपको वास्तव में विश्वास है कि वे आपके प्रोजेक्ट को बेहतर बनाएंगे। आप जितनी बार ना कहने का अभ्यास करेंगे, यह उतना ही आसान हो जाएगा। वादा करना। + +### सक्रिय होना + +सबसे पहले अवांछित योगदान की मात्रा को कम करने के लिए, अपने योगदान मार्गदर्शिका में योगदान जमा करने और स्वीकार करने के लिए अपने प्रोजेक्ट की प्रक्रिया की व्याख्या करें। + +यदि आपको बहुत अधिक निम्न-गुणवत्ता वाले योगदान प्राप्त हो रहे हैं, तो आवश्यक है कि योगदानकर्ता पहले से ही थोड़ा काम करें, उदाहरण के लिए: + +* कोई अंक या पीआर टेम्पलेट/चेकलिस्ट भरें +* पीआर सबमिट करने से पहले एक मुद्दा खोलें + +यदि वे आपके नियमों का पालन नहीं करते हैं, तो समस्या को तुरंत बंद करें और अपने दस्तावेज़ की ओर इंगित करें। + +हालाँकि यह दृष्टिकोण पहली बार में निर्दयी लग सकता है, सक्रिय होना वास्तव में दोनों पक्षों के लिए अच्छा है। इससे इस बात की संभावना कम हो जाती है कि कोई व्यक्ति काम के कई घंटे बर्बाद करके ऐसे पुल अनुरोध में लगाएगा जिसे आप स्वीकार नहीं करेंगे। और यह आपके कार्यभार को प्रबंधित करना आसान बनाता है। + + + +कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें। + +### मार्गदर्शन को गले लगाओ + +हो सकता है कि आपके समुदाय में कोई व्यक्ति नियमित रूप से ऐसे योगदान सबमिट करता हो जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करता हो। बार-बार अस्वीकृतियों से गुजरना दोनों पक्षों के लिए निराशाजनक हो सकता है। + +यदि आप देखते हैं कि कोई आपके प्रोजेक्ट को लेकर उत्साहित है, लेकिन उसे थोड़ा निखारने की जरूरत है, तो धैर्य रखें। प्रत्येक स्थिति में स्पष्ट रूप से बताएं कि उनका योगदान परियोजना की अपेक्षाओं को पूरा क्यों नहीं करता है। उन्हें किसी आसान या कम अस्पष्ट कार्य की ओर इंगित करने का प्रयास करें, जैसे उनके पैरों को गीला करने के लिए _"अच्छा पहला अंक,"_ चिह्नित कोई मुद्दा। यदि आपके पास समय है, तो उनके पहले योगदान के माध्यम से उन्हें सलाह देने पर विचार करें, या अपने समुदाय में किसी और को ढूंढें जो उन्हें सलाह देने के लिए तैयार हो सकता है। + +## अपने समुदाय का लाभ उठाएं + +आपको सब कुछ खुद ही करने की ज़रूरत नहीं है. आपके प्रोजेक्ट का समुदाय किसी कारण से मौजूद है! भले ही आपके पास अभी तक कोई सक्रिय योगदानकर्ता समुदाय नहीं है, यदि आपके पास बहुत सारे उपयोगकर्ता हैं, तो उन्हें काम पर लगाएं। + +### कार्यभार साझा करें + +यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें। + +नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [label issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी। + +जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं। + +दूसरों को इसके लिए प्रोत्साहित करना[share ownership of the project](../building-community/#share-ownership-of-your-project) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js). + + + +यदि आपको अपने प्रोजेक्ट से हटना है, या तो अंतराल पर या स्थायी रूप से, तो किसी और को आपकी जगह लेने के लिए कहने में कोई शर्म की बात नहीं है। + +यदि अन्य लोग इसकी दिशा को लेकर उत्साहित हैं, तो उन्हें प्रतिबद्ध पहुंच प्रदान करें या औपचारिक रूप से नियंत्रण किसी और को सौंप दें। यदि किसी ने आपके प्रोजेक्ट को फोर्क किया है और इसे कहीं और सक्रिय रूप से बनाए रख रहा है, तो अपने मूल प्रोजेक्ट से फोर्क को जोड़ने पर विचार करें। यह बहुत अच्छा है कि इतने सारे लोग चाहते हैं कि आपका प्रोजेक्ट चालू रहे! + +@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) अपने प्रोजेक्ट, [डोक्कू](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..25309ad6f28 --- /dev/null +++ b/_articles/hi/building-community.md @@ -0,0 +1,279 @@ +--- +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/#writing-a-readme) +और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे। +* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#writing-your-contributing-guidelines) और अपने मुद्दों को अद्यतन रखते हुए। +* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं। + +[GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें। + +* **जब कोई नया व्यक्ति आपके प्रोजेक्ट पर आता है, तो उनकी रुचि के लिए उन्हें धन्यवाद दें!** किसी को वापस आने से रोकने के लिए केवल एक नकारात्मक अनुभव की आवश्यकता होती है। +* **उत्तरदायी बनें।** यदि आप एक महीने तक उनके मुद्दे पर प्रतिक्रिया नहीं देते हैं, तो संभावना है कि वे पहले ही आपके प्रोजेक्ट के बारे में भूल चुके होंगे। +* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। वहाँ हैं[योगदान करने के कई तरीके](../how-to-contribute/#what-it-means-to-contribute) एक परियोजना के लिए. लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें। +* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#learning-to-say-no) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें। + + + +अधिकांश ओपन सोर्स योगदानकर्ता "आकस्मिक योगदानकर्ता" हैं: वे लोग जो कभी-कभार ही किसी परियोजना में योगदान करते हैं। एक आकस्मिक योगदानकर्ता के पास आपके प्रोजेक्ट को पूरी तरह से गति देने का समय नहीं हो सकता है, इसलिए आपका काम उनके लिए योगदान करना आसान बनाना है। + +अन्य योगदानकर्ताओं को प्रोत्साहित करना आपके लिए भी एक निवेश है। जब आप अपने सबसे बड़े प्रशंसकों को उस काम के लिए सशक्त बनाते हैं जिसके लिए वे उत्साहित हैं, तो सब कुछ स्वयं करने का दबाव कम होता है। + +### हर चीज़ का दस्तावेजीकरण करें + + + +जब आप कोई नया प्रोजेक्ट शुरू करते हैं, तो अपने काम को निजी रखना स्वाभाविक लग सकता है। लेकिन जब आप अपनी प्रक्रिया को सार्वजनिक रूप से दस्तावेज़ित करते हैं तो ओपन सोर्स प्रोजेक्ट फलते-फूलते हैं। + +जब आप चीज़ें लिखते हैं, तो हर कदम पर अधिक लोग भाग ले सकते हैं। आपको किसी ऐसी चीज़ पर मदद मिल सकती है जिसके बारे में आपको पता भी नहीं था कि आपको इसकी ज़रूरत है। + +चीज़ों को लिखने का अर्थ केवल तकनीकी दस्तावेज़ीकरण से कहीं अधिक है। जब भी आपको कुछ लिखने या अपने प्रोजेक्ट पर निजी तौर पर चर्चा करने की इच्छा महसूस हो, तो अपने आप से पूछें कि क्या आप इसे सार्वजनिक कर सकते हैं। + +अपने प्रोजेक्ट के रोडमैप, आप किस प्रकार के योगदान की तलाश कर रहे हैं, योगदान की समीक्षा कैसे की जाती है, या आपने कुछ निर्णय क्यों लिए, इस बारे में पारदर्शी रहें। + +यदि आप देखते हैं कि कई उपयोगकर्ता एक ही समस्या से जूझ रहे हैं, तो उत्तरों को 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/#enforcing-your-code-of-conduct). Your [आचार संहिता](../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/) एक या दो अनुरक्षक जो अधिकांश कार्य करते हैं। आपका प्रोजेक्ट जितना बड़ा होगा, और आपका समुदाय जितना बड़ा होगा, सहायता पाना उतना ही आसान होगा। + +हालाँकि आपको कॉल का उत्तर देने के लिए हमेशा कोई नहीं मिल सकता है, लेकिन वहाँ सिग्नल लगाने से अन्य लोगों के कॉल करने की संभावना बढ़ जाती है। और आप जितनी जल्दी शुरुआत करेंगे, उतनी जल्दी लोग मदद कर सकते हैं। + + + +## विवादों का समाधान + +आपके प्रोजेक्ट के शुरुआती चरणों में, बड़े निर्णय लेना आसान होता है। जब आप कुछ करना चाहते हैं, तो आप बस उसे करते हैं। + +जैसे-जैसे आपका प्रोजेक्ट अधिक लोकप्रिय होगा, अधिक लोग आपके निर्णयों में रुचि लेंगे। भले ही आपके पास योगदानकर्ताओं का एक बड़ा समुदाय न हो, यदि आपके प्रोजेक्ट में बहुत सारे उपयोगकर्ता हैं, तो आप पाएंगे कि लोग निर्णयों पर विचार कर रहे हैं या अपने स्वयं के मुद्दे उठा रहे हैं। + +अधिकांश भाग के लिए, यदि आपने एक मैत्रीपूर्ण, सम्मानजनक समुदाय विकसित किया है और अपनी प्रक्रियाओं को खुले तौर पर प्रलेखित किया है, तो आपका समुदाय समाधान खोजने में सक्षम होना चाहिए। लेकिन कभी-कभी आप ऐसे मुद्दे में फंस जाते हैं जिसका समाधान करना थोड़ा कठिन होता है। + +### दयालुता का स्तर निर्धारित करें + +जब आपका समुदाय किसी कठिन मुद्दे से जूझ रहा हो, तो गुस्सा बढ़ सकता है। लोग क्रोधित या निराश हो सकते हैं और इसे एक-दूसरे पर या आप पर निकाल सकते हैं। + +एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [act immediately](../building-community/#dont-tolerate-bad-actors) +चर्चाओं को सभ्य और उत्पादक बनाए रखना। + + + +अन्य लोग मार्गदर्शन के लिए आपकी ओर देख रहे हैं। अच्छा उदाहरण स्थापित करो। आप अभी भी निराशा, नाखुशी या चिंता व्यक्त कर सकते हैं, लेकिन ऐसा शांति से करें। + +खुद को शांत रखना आसान नहीं है, लेकिन नेतृत्व प्रदर्शित करने से आपके समुदाय के स्वास्थ्य में सुधार होता है। इंटरनेट आपका धन्यवाद करता है. + +### अपने README को एक संविधान मानें + +आपका README है [more than just a set of instructions](../starting-a-project/#writing-a-readme). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके 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..3c3d187ae79 --- /dev/null +++ b/_articles/hi/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: en +title: Your Code of Conduct +description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Why do I need a code of conduct? + +A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. + +Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. + +A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. + +## Establishing a code of conduct + +Try to establish a code of conduct as early as possible: ideally, when you first create your project. + +In addition to communicating your expectations, a code of conduct describes the following: + +* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ +* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ +* What happens if someone violates the code of conduct +* How someone can report violations + +Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. + +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples. + +Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. + +## Deciding how you'll enforce your code of conduct + + + +You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: + +* It demonstrates that you are serious about taking action when it's needed. + +* Your community will feel more reassured that complaints actually get reviewed. + +* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. + +You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. + +Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.* + +For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). + +## Enforcing your code of conduct + +Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. + +### Gather information about the situation + +Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. + +The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. + +Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. + + + +### Take appropriate action + +After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. + +When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. + +There are a few ways you might respond to a code of conduct violation: + +* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. + +* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. + +Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: + +* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project + +* **Permanently ban** the person from the project + +Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. + +## Your responsibilities as a maintainer + +A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. + +As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. + +A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. + +In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. + +## Encourage the behavior you want to see in the world 🌎 + +When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md new file mode 100644 index 00000000000..61e7b3e98ff --- /dev/null +++ b/_articles/hi/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: en +title: Finding Users for Your Project +description: Help your open source project grow by getting it in the hands of happy users. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Spreading the word + +There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work! + +## Figure out your message + +Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. + +What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance. + +Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want. + +For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. + +## Help people find and follow your project + + + +Help people find and remember your project by pointing them to a single namespace. + +**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene. + +If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. + + + +**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_. + +If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience! + +## Go where your project's audience is (online) + +Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience. + +Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work. + + + +See if you can find ways to share your project in relevant ways: + +* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work. +* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution. +* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work. + +Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want. + +If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication. + +## Go where your project's audience is (offline) + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. + +If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. + + + +If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work. + +As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun. + + + +When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world. + +Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers. + + + +## Build a reputation + +In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects. + +Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships. + + + +It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others. + +There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. + +## Keep at it! + +It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md new file mode 100644 index 00000000000..7fd4a32af4c --- /dev/null +++ b/_articles/hi/getting-paid.md @@ -0,0 +1,178 @@ +--- +lang: en +title: Getting Paid for Open Source Work +description: Sustain your work in open source by getting financial support for your time or your project. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Why some people seek financial support + +Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. + + + +There are many reasons why a person would not want to be paid for their open source work. + +* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. +* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. +* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. + + + +For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. + +Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. + + + +Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. + + + +If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. + +## Funding your own time + +Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. + +It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. + +If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. + +Many companies are developing open source programs to build their brand and recruit quality talent. + +@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: + +> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. + +If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. + + + +If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: + +* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source +* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees + +Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. + +Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: + +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) +* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Finally, sometimes open source projects put bounties on issues that you might consider helping with. + +* @ConnorChristie was able to get paid for [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 did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). + +## Finding funding for your project + +Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. + +Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas. + +As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. + +### Raise money for your work through crowdfunding campaigns or sponsorships + +Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. +A few examples of sponsored projects include: + +* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects + +### Create a revenue stream + +Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support +* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product +* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service + +Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. + +### Apply for grant funding + +Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) +* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work + +For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. + +## Building a case for financial support + +Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. + +Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. + +### Impact + +Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? + +### Traction + +Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? + +### Value to funder + +Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? + +### Use of funds + +What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. + +### How you'll receive the funds + +Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. + + + +## Experiment and don't give up + +Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md new file mode 100644 index 00000000000..17a04ad9821 --- /dev/null +++ b/_articles/hi/how-to-contribute.md @@ -0,0 +1,520 @@ +--- +lang: en +title: How to Contribute to Open Source +description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Why contribute to open source? + + + +Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. + +Why do people contribute to open source? Plenty of reasons! + +### Improve software you rely on + +Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. + +### Improve existing skills + +Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. + +### Meet people who are interested in similar things + +Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. + +### Find mentors and teach others + +Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved. + +### Build public artifacts that help you grow a reputation (and a career) + +By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. + +### Learn people skills + +Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. + +### It's empowering to be able to make changes, even small ones + +You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. + +## What it means to contribute + +If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong? + +Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience. + +### You don't have to contribute code + +A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions! + + + +Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. + +### Do you like planning events? + +* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organize the project's conference (if they have one) +* Help community members find the right conferences and submit proposals for speaking + +### Do you like to design? + +* Restructure layouts to improve the project's usability +* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Put together a style guide to help the project have a consistent visual design +* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) + +### Do you like to write? + +* Write and improve the project's documentation +* Curate a folder of examples showing how the project is used +* Start a newsletter for the project, or curate highlights from the mailing list +* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Write a translation for the project's documentation + + + +### Do you like organizing? + +* Link to duplicate issues, and suggest new issue labels, to keep things organized +* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) +* Ask clarifying questions on recently opened issues to move the discussion forward + +### Do you like to code? + +* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Ask if you can help write a new feature +* Automate project setup +* Improve tooling and testing + +### Do you like helping people? + +* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit +* Answer questions for people on open issues +* Help moderate the discussion boards or conversation channels + +### Do you like helping others code? + +* Review code on other people's submissions +* Write tutorials for how a project can be used +* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### You don't just have to work on software projects! + +While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. + +For example: + +* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) +* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates +* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) + +Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. + +## Orienting yourself to a new project + + + +For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. + +Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. + +### Anatomy of an open source project + +Every open source community is different. + +Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. + +That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. + +A typical open source project has the following types of people: + +* **Author:** The person/s or organization that created the project +* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) +* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) +* **Contributors:** Everyone who has contributed something back to the project +* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction + +Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information. + +A project also has documentation. These files are usually listed in the top level of a repository. + +* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. +* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. +* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. +* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. +* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects. + +Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works. + +* **Issue tracker:** Where people discuss issues related to the project. +* **Pull requests:** Where people discuss and review changes that are in progress. +* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. +* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. + +## Finding a project to contribute to + +Now that you've figured out how open source projects work, it's time to find a project to contribute to! + +If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_ + +Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. + +Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. + +Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. + +Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. + +You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! + +> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. + +If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +You can also use one of the following resources to help you discover and contribute to new projects: + +* [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/) + +### A checklist before you contribute + +When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response. + +Here's a handy checklist to evaluate whether a project is good for new contributors. + +**Meets the definition of open source** + +
+ + +
+ +**Project actively accepts contributions** + +Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Next, look at the project's issues. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Now do the same for the project's pull requests. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Project is welcoming** + +A project that is friendly and welcoming signals that they will be receptive to new contributors. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## How to submit a contribution + +You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. + +### Communicating effectively + +Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. + + + +Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. + +**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). + +> 😇 _"X doesn't happen when I do Y"_ +> +> 😢 _"X is broken! Please fix it."_ + +**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn. + +> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> +> 😢 _"How do I X?"_ + +**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. + +> 😇 _"I'd like to write an API tutorial."_ +> +> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ + +**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. + +> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> +> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ + +**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. + +> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> +> 😢 _"Why can't you fix my problem? Isn't this your project?"_ + +**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. + +> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ +> +> 😢 _"Why won't you support my use case? This is unacceptable!"_ + +**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. + +### Gathering context + +Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. + +If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: + +* **Issues** are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution +* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one + +Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. + +If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. + + + +### Opening an issue + +You should usually open an issue in the following situations: + +* Report an error you can't solve yourself +* Discuss a high-level topic or idea (for example, community, vision or policies) +* Propose a new feature or other project idea + +Tips for communicating on issues: + +* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. +* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. +* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. + +### Opening a pull request + +You should usually open a pull request in the following situations: + +* Submit trivial fixes (for example, a typo, a broken link or an obvious error) +* Start work on a contribution that was already asked for, or that you've already discussed, in an issue + +A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. + +If the project is on GitHub, here's how to submit a pull request: + +* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) +* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. +* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") +* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. +* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project. +* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. + +If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. + +## What happens after you submit a contribution + +You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. + +After you submit a contribution, one of the following will happen: + +### 😭 You don't get a response. + +Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. + +If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. + +**Don't** reach out to that person privately; remember that public communication is vital to open source projects. + +If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. + +### 🚧 Someone requests changes to your contribution. + +It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. + +When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. + +If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. + +### 👎 Your contribution doesn't get accepted. + +Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! + +### 🎉 Your contribution gets accepted. + +Hooray! You've successfully made an open source contribution! + +## You did it! + +Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. diff --git a/_articles/hi/index.html b/_articles/hi/index.html new file mode 100644 index 00000000000..ef7a7cb9a84 --- /dev/null +++ b/_articles/hi/index.html @@ -0,0 +1,5 @@ +--- +layout: index +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..6fd75930d5d --- /dev/null +++ b/_articles/hi/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: en +title: Leadership and Governance +description: Growing open source projects can benefit from formal rules for making decisions. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Understanding governance for your growing project + +Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. + +## What are examples of formal roles used in open source projects? + +Many projects follow a similar structure for contributor roles and recognition. + +What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: + +* **Maintainer** +* **Contributor** +* **Committer** + +**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers. + +A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. + +**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). + + + +**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. + +While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. + + + +## How do I formalize these leadership roles? + +Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. + +For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. + +For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. + +If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. + + + +Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. + +Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. + +Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). + +## When should I give someone commit access? + +Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. + +On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! + +If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. + + + +## What are some of the common governance structures for open source projects? + +There are three common governance structures associated with open source projects. + +* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. + +* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. + +* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). + +Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: + +* [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) + +## Do I need governance docs when I launch my project? + +There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! + +Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. + +If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. + + + +## What happens if corporate employees start submitting contributions? + +Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. + +As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. + +It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. + +"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) + +Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. + +## Do I need a legal entity to support my project? + +You don't need a legal entity to support your open source project unless you're handling money. + +For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). + +If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). + +Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [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) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. + + + +If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md new file mode 100644 index 00000000000..8adc3897659 --- /dev/null +++ b/_articles/hi/legal.md @@ -0,0 +1,158 @@ +--- +lang: en +title: The Legal Side of Open Source +description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Understanding the legal implications of open source + +Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) + +## Why do people care so much about the legal side of open source? + +Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. + +In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. + +Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. + +If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. + +Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. + +## Are public GitHub projects open source? + +When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. + +![Create repository](/assets/images/legal/repo-create-name.png) + +**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [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), which allows others to view and fork your project, but your work otherwise comes with no permissions. + +If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. + +## Just give me the TL;DR on what I need to protect my project. + +You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. + +[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/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). + +When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). + + + +## Which open source license is appropriate for my project? + +If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. + +Otherwise, picking the right open source license for your project depends on your objectives. + +Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. + +On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. + +You may also want to consider the **communities** you hope will use and contribute to your project: + +* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). +* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. + +Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). + +When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). + +## What if I want to change the license of my project? + +Most projects never need to change licenses. But occasionally circumstances change. + +For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: + +**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! + +**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. + +**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. + +Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. + +## Does my project need an additional contributor agreement? + +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. + +Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. + + + +Some situations where you may want to consider an additional contributor agreement for your project include: + +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. +* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). +* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. +* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. + +If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. + +## What does my company's legal team need to know? + +If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. + +For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. + +**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: + +* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. + +* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. + +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). + +* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. + +* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. + +If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). + +Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: + +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). + + + +* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. +* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. + + + +* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). 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..51d312d3499 --- /dev/null +++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,221 @@ +--- +lang: en +untranslated: true +title: Maintaining Balance for Open Source Maintainers +description: Tips for self-care and avoiding burnout as a maintainer. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. + +To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play. + +So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with. + + + +By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work. + +## Tips for Self-Care and Avoiding Burnout as a Maintainer: + +### Identify your motivations for working in open source + +Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus. + +### Reflect on what causes you to get out of balance and stressed out + +It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: + +* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. + + + +* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations. + + + +* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. + + + +* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. + + + +* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community. + + + +### Watch out for signs of burnout + +Can you keep up your pace for 10 weeks? 10 months? 10 years? + +There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress). + + + +### What would you need to continue sustaining yourself and your community? + +This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard: + +* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. + + You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work. + +* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions. + + + +* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [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) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term. + + If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. + + + +* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time. + + + + Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about. + + + + + +Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run. + +## Additional Resources + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](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) series + +## Contributors + +Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: + +[@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..145dd18119b --- /dev/null +++ b/_articles/hi/metrics.md @@ -0,0 +1,128 @@ +--- +lang: en +title: Open Source Metrics +description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Why measure anything? + +Data, when used wisely, can help you make better decisions as an open source maintainer. + +With more information, you can: + +* Understand how users respond to a new feature +* Figure out where new users come from +* Identify, and decide whether to support, an outlier use case or functionality +* Quantify your project's popularity +* Understand how your project is used +* Raise money through sponsorships and grants + +For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work: + +> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. + +Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you. + +If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. + +## Discovery + +Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see: + +* **Total page views:** Tells you how many times your project was viewed + +* **Total unique visitors:** Tells you how many people viewed your project + +* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working. + +* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors. + +[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. + +You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. + +## Usage + +People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ + +If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads. + +Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. + +If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +If usage is low compared to the number of people discovering your project, there are two issues to consider. Either: + +* Your project isn't successfully converting your audience, or +* You're attracting the wrong audience + +For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience. + +Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing. + +Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business? + +## Retention + +People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ + +It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). + +Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. + +Examples of community metrics that you may want to regularly track include: + +* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. + +* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. + +* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. + +* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. + + + +## Maintainer activity + +Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_ + +Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave. + +[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions. + +Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_ + +You could also measure the time it takes to move between stages in the contribution process, such as: + +* Average time an issue remains open +* Whether issues get closed by PRs +* Whether stale issues get closed +* Average time to merge a pull request + +## Use 📊 to learn about people + +Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive. + +[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health. diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md new file mode 100644 index 00000000000..15b01773ef7 --- /dev/null +++ b/_articles/hi/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: en +title: Starting an Open Source Project +description: Learn more about the world of open source and get ready to launch your own project. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## The "what" and "why" of open source + +So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it. + +### What does "open source" mean? + +When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). + +Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions. + +_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge). + +### Why do people open source their work? + + + +[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include: + +* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. + +* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [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 inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). + +Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. + +### Does open source mean "free of charge"? + +One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. + +Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. + +As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. + +## Should I launch my own open source project? + +The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works. + +If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone! + +Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience. + +If you're not yet convinced, take a moment to think about what your goals might be. + +### Setting your goals + +Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ + +There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. + +If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. + + + +As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. + +While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. + +**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. + +If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early. + + + +### Contributing to other projects + +If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. + +If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). + +## Launching your own open source project + +There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. + +Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. + +No matter which stage you decide to open source your project, every project should include the following documentation: + +* [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/) + +As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. + +If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. + +### Choosing a license + +An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.** + +Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work. + +[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/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from. + +When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source. + +![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) + +If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/). + +### Writing a README + +READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it. + +In your README, try to answer the following questions: + +* What does this project do? +* Why is this project useful? +* How do I get started? +* Where can I get more help, if I need it? + +You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. + + + +Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. + +For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. + +When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. + +### Writing your contributing guidelines + +A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on: + +* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) +* How to suggest a new feature +* How to set up your environment and run tests + +In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as: + +* The types of contributions you're looking for +* Your roadmap or vision for the project +* How contributors should (or should not) get in touch with you + +Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. + +For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: + +> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. + +In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution. + +Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. + +For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. + +![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Establishing a code of conduct + + + +Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. + +For more information, check out our [Code of Conduct guide](../code-of-conduct/). + +In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. + +Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. + +Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. + +## Naming and branding your project + +Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message. + +### Choosing the right name + +Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: + +* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting +* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server + +If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). + +Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! + +### Avoiding name conflicts + +[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. + +If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. + +Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. + +You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). + +Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? + +### How you write (and code) affects your brand, too! + +Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. + +Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. + + + +Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. + +Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. + +It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. + +## Your pre-launch checklist + +Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back. + +**Documentation** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**People** + +If you're an individual: + +
+ + +
+ +If you're a company or organization: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## You did it! + +Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow. From acce4cc6191c5cbde78d3304ad0658e482908cd0 Mon Sep 17 00:00:00 2001 From: James Titus Date: Thu, 31 Aug 2023 11:15:21 +0530 Subject: [PATCH 03/25] hindi update --- _articles/hi/best-practices.md | 12 ++-- _articles/hi/code-of-conduct.md | 106 ++++++++++++++--------------- _articles/hi/finding-users.md | 114 ++++++++++++++++---------------- _articles/hi/index.html | 1 + 4 files changed, 117 insertions(+), 116 deletions(-) diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md index 52982086e51..1613e0d2809 100644 --- a/_articles/hi/best-practices.md +++ b/_articles/hi/best-practices.md @@ -45,7 +45,7 @@ related: avatar मैंने इसे गलती से किया। मैंने किसी पूर्ण समाधान को लाने के लिए प्रयास नहीं किया। आधे-पूरे समाधान की जगह, मुझे खेद है कि मैंने यह नहीं कहा "मेरे पास इसके लिए अभी समय नहीं है, लेकिन मैं इसे दीर्घकालिक सूची में जोड़ दूंगा जिसे हमारे लिए अच्छा हो सकता है।"

-— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/) +— @lord, ["नए ओपन सोर्स अनुरक्षकों के लिए युक्तियाँ"](https://lord.io/blog/2014/oss-tips/)

@@ -102,7 +102,7 @@ related: avatar बड़े स्केल के ओपन सोर्स प्रोजेक्ट्स के समर्थन को हैंडल करने की कुंजी है, मुद्दों को आगे बढ़ाने की कोशिश करें। मुद्दों को ठप करने से बचने का प्रयास करें। यदि आप एक iOS डेवलपर हैं, तो आप जानते हैं कि रेडर्स (radars) सबमिट करना कितना खिचड़ हो सकता है। आप 2 साल बाद प्रतिक्रिया प्राप्त कर सकते हैं, और आपको नवीनतम iOS संस्करण के साथ पुनः प्रयास करने की सलाह दी जा सकती है।

-— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities) +— @KrauseFx, ["ओपन सोर्स समुदायों को स्केल करना"](https://krausefx.com/blog/scaling-open-source-communities)

@@ -149,7 +149,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user avatar आदर्श रूप से, उन्हें CONTRIBUTING.md फ़ाइल में समझाएं कि वे भविष्य में काम शुरू करने से पहले बेहतर संकेत कैसे प्राप्त कर सकते हैं कि क्या स्वीकार किया जाएगा या क्या नहीं।

-— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests) +— @MikeMcQuaid, ["कृपया पुल अनुरोध बंद करें"](https://github.com/blog/2124-kindly-closing-pull-requests)

@@ -179,7 +179,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user avatar मैं कह रहा था, "हाँ, कोई भी शामिल हो सकता है, आपके पास बहुत अधिक कोडिंग विशेषज्ञता होनी आवश्यक नहीं है [...]।" हमारे पास लोगों ने [एक कार्यक्रम में] आने के लिए साइन अप किया था और तभी मैं वास्तव में सोच रहा था: क्या यह सच है, जो मैं कह रहा हूं? वहाँ 40 लोग आने वाले हैं, और ऐसा नहीं है कि मैं उनमें से प्रत्येक के साथ बैठ सकता हूँ...लेकिन लोग एक साथ आए, और यह काम कर गया। जैसे ही एक व्यक्ति को यह मिल गया, वे अपने पड़ोसी को सिखा सकते थे।

-— @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39) +— @lmccart, ["ओपन सोर्स" का क्या मतलब है? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)

@@ -201,7 +201,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user avatar मैं 80% उपयोग के मामले को पूरा करता हूं। यदि आप यूनिकॉर्न में से एक हैं, तो कृपया मेरे काम को छोड़ दें। मैं नाराज नहीं होऊंगा! मेरी सार्वजनिक परियोजनाएँ लगभग हमेशा सबसे आम समस्याओं को हल करने के लिए होती हैं; मैं या तो अपने काम को आगे बढ़ाकर या इसे विस्तारित करके गहराई तक जाना आसान बनाने की कोशिश करता हूं।

-— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes) +— @geerlingguy, ["मैं पीआर क्यों बंद करता हूँ?"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)

@@ -227,7 +227,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user avatar मेरा मानना ​​है कि उन सभी कोड के लिए परीक्षण आवश्यक हैं जिन पर लोग काम करते हैं। यदि कोड पूरी तरह से और पूरी तरह से सही था, तो इसमें बदलाव की आवश्यकता नहीं होगी - हम केवल तभी कोड लिखते हैं जब कुछ गलत होता है, चाहे वह "यह क्रैश हो जाता है" या "इसमें ऐसी और ऐसी सुविधा का अभाव है"। और चाहे आप जो भी बदलाव कर रहे हों, आपके द्वारा गलती से पेश किए गए किसी भी प्रतिगमन को पकड़ने के लिए परीक्षण आवश्यक हैं।

-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Rust का सामुदायिक स्वचालन"](https://edunham.net/2016/09/27/rust_s_community_automation.html)

diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md index 3c3d187ae79..bd1c46ae7a0 100644 --- a/_articles/hi/code-of-conduct.md +++ b/_articles/hi/code-of-conduct.md @@ -1,7 +1,7 @@ --- -lang: en -title: Your Code of Conduct -description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +lang: hi +title: आपकी आचार संहिता +description: आचार संहिता को अपनाकर और लागू करके स्वस्थ और रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाना। class: coc order: 8 image: /assets/images/cards/coc.png @@ -10,105 +10,105 @@ related: - leadership --- -## Why do I need a code of conduct? +## मुझे आचार संहिता की आवश्यकता क्यों है? -A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. +आचार संहिता एक दस्तावेज है जो आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार की अपेक्षाएं स्थापित करता है। आचार संहिता को अपनाने और लागू करने से आपके समुदाय के लिए एक सकारात्मक सामाजिक माहौल बनाने में मदद मिल सकती है। -Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. +आचार संहिता न केवल आपके प्रतिभागियों को, बल्कि स्वयं को भी सुरक्षित रखने में मदद करती है। यदि आप किसी प्रोजेक्ट को बनाए रखते हैं, तो आप पा सकते हैं कि अन्य प्रतिभागियों का अनुत्पादक रवैया आपको समय के साथ अपने काम के बारे में थका हुआ या नाखुश महसूस करा सकता है। -A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. +आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाने के लिए सशक्त बनाती है। सक्रिय रहने से यह संभावना कम हो जाती है कि आप या अन्य लोग अपने प्रोजेक्ट से थक जाएंगे, और जब कोई ऐसा कुछ करता है जिससे आप सहमत नहीं हैं तो आपको कार्रवाई करने में मदद मिलती है। -## Establishing a code of conduct +## आचार संहिता स्थापित करना -Try to establish a code of conduct as early as possible: ideally, when you first create your project. +यथाशीघ्र एक आचार संहिता स्थापित करने का प्रयास करें: आदर्श रूप से, जब आप पहली बार अपना प्रोजेक्ट बनाते हैं। -In addition to communicating your expectations, a code of conduct describes the following: +आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है: -* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ -* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ -* What happens if someone violates the code of conduct -* How someone can report violations +* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_ +*आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_ +*यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा +* कोई कैसे उल्लंघन की रिपोर्ट कर सकता है -Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. +जहां भी आप कर सकें, पूर्व कला का उपयोग करें। [योगदानकर्ता अनुबंध](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग कुबेरनेट्स, रेल्स और स्विफ्ट सहित 40,000 से अधिक ओपन सोर्स परियोजनाओं द्वारा किया जाता है। -The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples. +The [Django आचार संहिता](https://www.djangoproject.com/conduct/) और यह [नागरिक आचार संहिता](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) आचार संहिता के दो अच्छे उदाहरण भी हैं। -Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. +एक CODE_OF_CONDUCT फ़ाइल अपने प्रोजेक्ट की रूट डायरेक्टरी में फ़ाइल में रखें, और इसे अपने समुदाय से जोड़कर इसे अपने समुदाय के लिए दृश्यमान बनाएं CONTRIBUTING या README फ़ाइल. -## Deciding how you'll enforce your code of conduct +## यह निर्णय लेना कि आप अपनी आचार संहिता को कैसे लागू करेंगे -You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: +उल्लंघन होने से **_पहले_** आपको स्पष्ट करना चाहिए कि आपकी आचार संहिता कैसे लागू की जाएगी। ऐसा करने के कई कारण हैं: -* It demonstrates that you are serious about taking action when it's needed. +* यह दर्शाता है कि आप जरूरत पड़ने पर कार्रवाई करने को लेकर गंभीर हैं। -* Your community will feel more reassured that complaints actually get reviewed. +* आपका समुदाय अधिक आश्वस्त महसूस करेगा कि शिकायतों की वास्तव में समीक्षा की जाती है। -* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. +* आप अपने समुदाय को आश्वस्त करेंगे कि समीक्षा प्रक्रिया निष्पक्ष और पारदर्शी है, क्या उन्हें कभी भी उल्लंघन के लिए जांच में पाया जाएगा। -You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. +आपको लोगों को आचार संहिता के उल्लंघन की रिपोर्ट करने का एक निजी तरीका (जैसे ईमेल पता) देना चाहिए और यह बताना चाहिए कि वह रिपोर्ट कौन प्राप्त करता है। यह एक अनुरक्षक, अनुरक्षकों का समूह या आचार संहिता कार्य समूह हो सकता है। -Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +यह मत भूलिए कि हो सकता है कि कोई व्यक्ति उस व्यक्ति के बारे में उल्लंघन की रिपोर्ट करना चाहता हो जो उन रिपोर्टों को प्राप्त करता है। इस मामले में, उन्हें किसी अन्य को उल्लंघन की रिपोर्ट करने का विकल्प दें। उदाहरण के लिए,@ctb and @mr-c [उनके प्रोजेक्ट पर स्पष्टीकरण दें](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): -> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.* +> अपमानजनक, परेशान करने वाले, या अन्यथा अस्वीकार्य व्यवहार के मामलों की रिपोर्ट **khmer-project@idyll.org** पर ईमेल करके की जा सकती है, जो केवल सी. टाइटस ब्राउन और माइकल आर. क्रूसो को जाती है। उनमें से किसी एक से जुड़े मुद्दे की रिपोर्ट करने के लिए कृपया विज्ञान और प्रौद्योगिकी के लिए एक एनएसएफ केंद्र, बीकॉन सेंटर फॉर द स्टडी ऑफ इवोल्यूशन इन एक्शन में विविधता निदेशक **जूडी ब्राउन क्लार्क, पीएच.डी.** को ईमेल करें।* -For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). +प्रेरणा के लिए, Django का [प्रवर्तन मैनुअल](https://www.djangoproject.com/conduct/enforcement-manual/) देखें (हालाँकि, आपके प्रोजेक्ट के आकार के आधार पर, आपको इतनी व्यापक चीज़ की आवश्यकता नहीं हो सकती है). -## Enforcing your code of conduct +## अपनी आचार संहिता लागू करना -Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. +कभी-कभी, आपके सर्वोत्तम प्रयासों के बावजूद, कोई ऐसा कार्य करेगा जो इस संहिता का उल्लंघन करता है। नकारात्मक या हानिकारक व्यवहार सामने आने पर उससे निपटने के कई तरीके हैं। -### Gather information about the situation +### स्थिति के बारे में जानकारी इकट्ठा करें -Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. +समुदाय के प्रत्येक सदस्य की आवाज़ को अपनी आवाज़ के समान महत्वपूर्ण मानें। यदि आपको कोई रिपोर्ट मिलती है कि किसी ने आचार संहिता का उल्लंघन किया है, तो इसे गंभीरता से लें और मामले की जांच करें, भले ही वह उस व्यक्ति के साथ आपके अपने अनुभव से मेल न खाता हो। ऐसा करना आपके समुदाय को संकेत देता है कि आप उनके दृष्टिकोण को महत्व देते हैं और उनके निर्णय पर भरोसा करते हैं। -The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. +विचाराधीन समुदाय का सदस्य बार-बार अपराधी हो सकता है जो लगातार दूसरों को असहज महसूस कराता है, या हो सकता है कि उसने केवल एक बार ही कुछ कहा या किया हो। संदर्भ के आधार पर दोनों ही कार्रवाई करने के आधार हो सकते हैं। -Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. +प्रतिक्रिया देने से पहले, स्वयं को यह समझने का समय दें कि क्या हुआ था। यह बेहतर ढंग से समझने के लिए कि वे कौन हैं और उन्होंने ऐसा व्यवहार क्यों किया होगा, उस व्यक्ति की पिछली टिप्पणियों और बातचीत को पढ़ें। इस व्यक्ति और उनके व्यवहार के बारे में अपने अलावा अन्य दृष्टिकोण इकट्ठा करने का प्रयास करें। -### Take appropriate action +### उचित कार्रवाई करें -After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. +पर्याप्त जानकारी एकत्र करने और संसाधित करने के बाद, आपको यह निर्णय लेना होगा कि क्या करना है। जब आप अपने अगले कदमों पर विचार करें, तो याद रखें कि एक मॉडरेटर के रूप में आपका लक्ष्य एक सुरक्षित, सम्मानजनक और सहयोगात्मक वातावरण को बढ़ावा देना है। न केवल इस बात पर विचार करें कि संबंधित स्थिति से कैसे निपटा जाए, बल्कि यह भी कि आपकी प्रतिक्रिया आपके समुदाय के बाकी व्यवहार और अपेक्षाओं को कैसे प्रभावित करेगी। -When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. +जब कोई आचार संहिता के उल्लंघन की रिपोर्ट करता है, तो इसे संभालना उनका नहीं, आपका काम है। कभी-कभी, रिपोर्टर अपने करियर, प्रतिष्ठा या शारीरिक सुरक्षा को बहुत जोखिम में डालकर जानकारी का खुलासा कर रहा है। उन्हें अपने उत्पीड़क का सामना करने के लिए मजबूर करना रिपोर्टर को समझौतावादी स्थिति में डाल सकता है। आपको संबंधित व्यक्ति के साथ सीधा संवाद संभालना चाहिए, जब तक कि रिपोर्टर स्पष्ट रूप से अन्यथा अनुरोध न करे। -There are a few ways you might respond to a code of conduct violation: +ऐसे कुछ तरीके हैं जिनसे आप आचार संहिता के उल्लंघन पर प्रतिक्रिया दे सकते हैं: -* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. +* **संबंधित व्यक्ति को सार्वजनिक चेतावनी दें** और बताएं कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला, अधिमानतः उस चैनल में जहां यह हुआ। जहां संभव हो, सार्वजनिक संचार शेष समुदाय को बताता है कि आप आचार संहिता को गंभीरता से लेते हैं। दयालु बनें, लेकिन अपने संचार में दृढ़ रहें। -* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. +* **व्यक्तिगत रूप से उस व्यक्ति तक पहुंचें**यह समझाने के लिए कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला। यदि स्थिति में संवेदनशील व्यक्तिगत जानकारी शामिल है तो आप निजी संचार चैनल का उपयोग करना चाह सकते हैं। यदि आप किसी के साथ निजी तौर पर संवाद करते हैं, तो उन लोगों को सीसी देना एक अच्छा विचार है जिन्होंने सबसे पहले स्थिति की सूचना दी थी, ताकि वे जान सकें कि आपने कार्रवाई की है। सीसी देने से पहले रिपोर्टिंग व्यक्ति से सहमति मांगें। -Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: +कभी-कभी, किसी समाधान तक नहीं पहुंचा जा सकता. सामना किए जाने पर संबंधित व्यक्ति आक्रामक या शत्रुतापूर्ण हो सकता है या अपना व्यवहार नहीं बदलता है। इस स्थिति में, आप कड़ी कार्रवाई करने पर विचार कर सकते हैं। उदाहरण के लिए: -* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project +* **परियोजना के किसी भी पहलू में भाग लेने पर अस्थायी प्रतिबंध के माध्यम से लागू, परियोजना से संबंधित व्यक्ति को निलंबित करें** -* **Permanently ban** the person from the project +* **प्रोजेक्ट से व्यक्ति को स्थायी रूप से प्रतिबंधित** करें -Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. +सदस्यों पर प्रतिबंध लगाना हल्के में नहीं लिया जाना चाहिए और यह दृष्टिकोण में स्थायी और अपूरणीय अंतर का प्रतिनिधित्व करता है। आपको ये उपाय केवल तभी करना चाहिए जब यह स्पष्ट हो कि किसी समाधान पर नहीं पहुंचा जा सकता। -## Your responsibilities as a maintainer +## एक अनुरक्षक के रूप में आपकी जिम्मेदारियाँ -A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. +आचार संहिता कोई ऐसा कानून नहीं है जिसे मनमाने ढंग से लागू किया जाए। आप आचार संहिता के प्रवर्तक हैं और आचार संहिता द्वारा स्थापित नियमों का पालन करना आपकी जिम्मेदारी है। -As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. +एक अनुरक्षक के रूप में आप अपने समुदाय के लिए दिशानिर्देश स्थापित करते हैं और उन दिशानिर्देशों को अपनी आचार संहिता में निर्धारित नियमों के अनुसार लागू करते हैं। इसका अर्थ है आचार संहिता उल्लंघन की किसी भी रिपोर्ट को गंभीरता से लेना। रिपोर्टर को उनकी शिकायत की गहन और निष्पक्ष समीक्षा करनी चाहिए। यदि आप यह निर्धारित करते हैं कि जिस व्यवहार की उन्होंने रिपोर्ट की है वह उल्लंघन नहीं है, तो उन्हें स्पष्ट रूप से बताएं और बताएं कि आप इस पर कार्रवाई क्यों नहीं करने जा रहे हैं। वे इसके साथ क्या करते हैं यह उन पर निर्भर है: उस व्यवहार को सहन करें जिससे उन्हें कोई समस्या थी, या समुदाय में भाग लेना बंद कर दें। -A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. +व्यवहार की एक रिपोर्ट जो तकनीकी रूप से आचार संहिता का उल्लंघन नहीं करती है, फिर भी यह संकेत दे सकती है कि आपके समुदाय में कोई समस्या है, और आपको इस संभावित समस्या की जांच करनी चाहिए और तदनुसार कार्य करना चाहिए। इसमें स्वीकार्य व्यवहार को स्पष्ट करने के लिए अपनी आचार संहिता को संशोधित करना और/या उस व्यक्ति से बात करना शामिल हो सकता है जिसके व्यवहार की रिपोर्ट की गई थी और उन्हें यह बताना कि हालांकि उन्होंने आचार संहिता का उल्लंघन नहीं किया है, वे जो अपेक्षित है उससे किनारा कर रहे हैं और निश्चित कर रहे हैं। प्रतिभागी असहज महसूस करते हैं। -In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. +अंत में, एक अनुरक्षक के रूप में, आप स्वीकार्य व्यवहार के लिए मानक निर्धारित और लागू करते हैं। आपके पास परियोजना के सामुदायिक मूल्यों को आकार देने की क्षमता है, और प्रतिभागी आपसे उन मूल्यों को निष्पक्ष और समान तरीके से लागू करने की उम्मीद करते हैं। -## Encourage the behavior you want to see in the world 🌎 +## उस व्यवहार को प्रोत्साहित करें जो आप दुनिया में देखना चाहते हैं 🌎 -When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. +जब कोई परियोजना शत्रुतापूर्ण या अप्रिय लगती है, भले ही वह सिर्फ एक व्यक्ति हो जिसका व्यवहार दूसरों द्वारा सहन किया जाता है, तो आप कई और योगदानकर्ताओं को खोने का जोखिम उठाते हैं, जिनमें से कुछ से आप कभी भी नहीं मिल सकते हैं। आचार संहिता को अपनाना या लागू करना हमेशा आसान नहीं होता है, लेकिन स्वागत योग्य माहौल को बढ़ावा देने से आपके समुदाय को बढ़ने में मदद मिलेगी। diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md index 61e7b3e98ff..94d36a15e3f 100644 --- a/_articles/hi/finding-users.md +++ b/_articles/hi/finding-users.md @@ -1,7 +1,7 @@ --- -lang: en -title: Finding Users for Your Project -description: Help your open source project grow by getting it in the hands of happy users. +lang: hi +title: अपने प्रोजेक्ट के लिए उपयोगकर्ता ढूँढना +description: अपने ओपन सोर्स प्रोजेक्ट को खुश उपयोगकर्ताओं के हाथों में पहुंचाकर उसे बढ़ने में मदद करें। class: finding order: 3 image: /assets/images/cards/finding.png @@ -10,139 +10,139 @@ related: - building --- -## Spreading the word +## बातों का प्रसार -There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work! +ऐसा कोई नियम नहीं है जो कहता हो कि लॉन्च करते समय आपको एक ओपन सोर्स प्रोजेक्ट का प्रचार करना होगा। ओपन सोर्स में काम करने के कई संतोषजनक कारण हैं जिनका लोकप्रियता से कोई लेना-देना नहीं है। यह आशा करने के बजाय कि अन्य लोग आपके ओपन सोर्स प्रोजेक्ट को ढूंढेंगे और उसका उपयोग करेंगे, आपको अपनी कड़ी मेहनत के बारे में प्रचार करना होगा! -## Figure out your message +## अपने संदेश का पता लगाएं -Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. +इससे पहले कि आप अपने प्रोजेक्ट को बढ़ावा देने का वास्तविक काम शुरू करें, आपको यह समझाने में सक्षम होना चाहिए कि यह क्या करता है और यह क्यों मायने रखता है। -What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance. +आपके प्रोजेक्ट को क्या अलग या दिलचस्प बनाता है? आपने इसे क्यों बनाया? इन प्रश्नों का स्वयं उत्तर देने से आपको अपने प्रोजेक्ट के महत्व के बारे में बताने में मदद मिलेगी। -Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want. +याद रखें कि लोग उपयोगकर्ता के रूप में शामिल होते हैं, और अंततः योगदानकर्ता बन जाते हैं, क्योंकि आपका प्रोजेक्ट उनके लिए एक समस्या का समाधान करता है। जब आप अपने प्रोजेक्ट के संदेश और मूल्य के बारे में सोचते हैं, तो उन्हें इस नजरिए से देखने का प्रयास करें कि उपयोगकर्ता और योगदानकर्ता क्या चाहते हैं। -For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: +उदाहरण के लिए, @robb अपने प्रोजेक्ट को स्पष्ट रूप से बताने के लिए कोड उदाहरणों का उपयोग करता है, [Cartography](https://github.com/robb/Cartography), उपयोगी है: ![Cartography README](/assets/images/finding-users/cartography.jpg) -For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. +मैसेजिंग के बारे में गहराई से जानने के लिए मोज़िला देखें ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) उपयोगकर्ता व्यक्तित्व विकसित करने के लिए व्यायाम। -## Help people find and follow your project +## अपने प्रोजेक्ट को ढूंढने और उसका अनुसरण करने में लोगों की सहायता करें -Help people find and remember your project by pointing them to a single namespace. +लोगों को एक ही नामस्थान की ओर इंगित करके अपना प्रोजेक्ट ढूंढने और याद रखने में सहायता करें। -**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene. +**अपने काम को बढ़ावा देने के लिए एक स्पष्ट हैंडल रखें।** एक ट्विटर हैंडल, GitHub URL, या IRC चैनल लोगों को आपके प्रोजेक्ट की ओर इंगित करने का एक आसान तरीका है। ये आउटलेट आपके प्रोजेक्ट के बढ़ते समुदाय को एकत्रित होने की जगह भी देते हैं। -If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. +यदि आप अभी तक अपने प्रोजेक्ट के लिए आउटलेट स्थापित नहीं करना चाहते हैं, तो अपने हर काम में अपने स्वयं के ट्विटर या GitHub हैंडल को बढ़ावा दें। आपके ट्विटर या GitHub हैंडल को बढ़ावा देने से लोगों को पता चलेगा कि आपसे कैसे संपर्क किया जाए या आपके काम का अनुसरण किया जाए। यदि आप किसी बैठक या कार्यक्रम में बोलते हैं, तो सुनिश्चित करें कि आपकी संपर्क जानकारी आपके बायो या स्लाइड में शामिल है। -**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project. +**अपने प्रोजेक्ट के लिए एक वेबसाइट बनाने पर विचार करें।** एक वेबसाइट आपके प्रोजेक्ट को मित्रवत और नेविगेट करने में आसान बनाती है, खासकर जब इसे स्पष्ट दस्तावेज़ीकरण और ट्यूटोरियल के साथ जोड़ा जाता है। एक वेबसाइट होने से यह भी पता चलता है कि आपका प्रोजेक्ट सक्रिय है जिससे आपके दर्शकों को इसका उपयोग करने में अधिक सहजता महसूस होगी। लोगों को अपने प्रोजेक्ट का उपयोग करने के तरीके के बारे में विचार देने के लिए उदाहरण प्रदान करें। -[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_. +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django के सह-निर्माता ने कहा कि एक वेबसाइट _"प्रारंभिक दिनों में Django के साथ हमने जो किया वह अब तक का सबसे अच्छा काम था"_. -If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. +यदि आपका प्रोजेक्ट 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) -Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience! +अब जब भी आपके पास अपने प्रोजेक्ट के लिए एक संदेश है, और लोगों के लिए आपके प्रोजेक्ट को आकर्षित करने का एक आसान तरीका है, तो वहां आएं और अपने दर्शकों से बात करें! -## Go where your project's audience is (online) +## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑनलाइन) -Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience. +ऑनलाइन आउटरीच बात को तेजी से साझा करने और फैलाने का एक शानदार तरीका है। ऑनलाइन चैनलों का उपयोग करके, आपके पास बहुत व्यापक दर्शकों तक पहुंचने की क्षमता है। -Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work. +अपने दर्शकों तक पहुंचने के लिए मौजूदा ऑनलाइन समुदायों और प्लेटफार्मों का लाभ उठाएं। यदि आपका ओपन सोर्स प्रोजेक्ट एक सॉफ्टवेयर प्रोजेक्ट है, तो आप संभवतः अपने दर्शकों को ढूंढ सकते हैं [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), या [Quora](https://www.quora.com/). वे चैनल ढूंढें जहां आपको लगता है कि लोगों को आपके काम से सबसे अधिक लाभ होगा या वे आपके काम के बारे में उत्साहित होंगे। -See if you can find ways to share your project in relevant ways: +देखें कि क्या आप अपने प्रोजेक्ट को प्रासंगिक तरीकों से साझा करने के तरीके ढूंढ सकते हैं: -* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work. -* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution. -* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work. +* **प्रासंगिक ओपन सोर्स प्रोजेक्ट्स और समुदायों को जानें।** कभी-कभी, आपको सीधे अपने प्रोजेक्ट का प्रचार करने की ज़रूरत नहीं होती है। यदि आपका प्रोजेक्ट पायथन का उपयोग करने वाले डेटा वैज्ञानिकों के लिए एकदम सही है, तो पायथन डेटा विज्ञान समुदाय को जानें। जैसे-जैसे लोग आपको जानने लगेंगे, आपके काम के बारे में बात करने और साझा करने के स्वाभाविक अवसर पैदा होंगे। +* **उन लोगों को ढूंढें जो उस समस्या का अनुभव कर रहे हैं जिसे आपका प्रोजेक्ट हल करता है।** उन लोगों के लिए संबंधित मंचों के माध्यम से खोजें जो आपके प्रोजेक्ट के लक्षित दर्शकों में आते हैं। उनके प्रश्न का उत्तर दें और समाधान के रूप में अपनी परियोजना का सुझाव देने के लिए, जब उचित हो, एक चतुराईपूर्ण तरीका खोजें। +* **प्रतिक्रिया के लिए पूछें।** ऐसे दर्शकों के सामने अपना और अपने काम का परिचय दें जिन्हें यह प्रासंगिक और दिलचस्प लगे। इस बारे में स्पष्ट रहें कि आपको क्या लगता है कि आपके प्रोजेक्ट से किसे लाभ होगा। वाक्य को पूरा करने का प्रयास करें: _"मुझे लगता है कि मेरा प्रोजेक्ट वास्तव में एक्स की मदद करेगा, जो Y_ करने की कोशिश कर रहे हैं"। केवल अपने काम का प्रचार करने के बजाय दूसरों की प्रतिक्रिया सुनें और उसका जवाब दें। -Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want. +सामान्यतया, बदले में चीज़ें मांगने से पहले दूसरों की मदद करने पर ध्यान केंद्रित करें। क्योंकि कोई भी किसी प्रोजेक्ट को आसानी से ऑनलाइन प्रमोट कर सकता है, इसलिए बहुत शोर होगा। भीड़ से अलग दिखने के लिए, लोगों को यह संदर्भ दें कि आप कौन हैं, न कि केवल वह जो आप चाहते हैं। -If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication. +यदि कोई आपकी आरंभिक पहुंच पर ध्यान नहीं देता है या प्रतिक्रिया नहीं देता है, तो निराश न हों! अधिकांश प्रोजेक्ट लॉन्च एक पुनरावृत्तीय प्रक्रिया है जिसमें महीनों या वर्षों का समय लग सकता है। यदि आपको पहली बार कोई प्रतिक्रिया नहीं मिलती है, तो एक अलग रणनीति आज़माएं, या पहले दूसरों के काम में मूल्य जोड़ने के तरीकों की तलाश करें। अपने प्रोजेक्ट को प्रचारित करने और लॉन्च करने में समय और समर्पण लगता है। -## Go where your project's audience is (offline) +## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑफ़लाइन) -![Public speaking](/assets/images/finding-users/public_speaking.jpg) +![सार्वजनिक रूप से बोलना](/assets/images/finding-users/public_speaking.jpg) -Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. +ऑफ़लाइन कार्यक्रम दर्शकों के बीच नई परियोजनाओं को बढ़ावा देने का एक लोकप्रिय तरीका है। वे व्यस्त दर्शकों तक पहुंचने और गहरे मानवीय संबंध बनाने का एक शानदार तरीका हैं, खासकर यदि आप डेवलपर्स तक पहुंचने में रुचि रखते हैं। -If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. +यदि आप [सार्वजनिक भाषण में नए](https://peaking.io/) हैं, तो एक स्थानीय बैठक ढूंढ़कर शुरुआत करें जो आपके प्रोजेक्ट की भाषा या पारिस्थितिकी तंत्र से संबंधित हो। -If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work. +यदि आपने पहले कभी किसी कार्यक्रम में बात नहीं की है, तो घबराहट महसूस होना बिल्कुल सामान्य है! याद रखें कि आपके दर्शक वहां हैं क्योंकि वे वास्तव में आपके काम के बारे में सुनना चाहते हैं। -As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun. +जब आप अपनी बात लिखते हैं, तो इस बात पर ध्यान केंद्रित करें कि आपके दर्शकों को क्या दिलचस्प लगेगा और उन्हें क्या लाभ मिलेगा। अपनी भाषा मित्रतापूर्ण एवं सुगम्य रखें। मुस्कुराएं, सांस लें और आनंद लें। -When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world. +जब आप तैयार महसूस करें, तो अपने प्रोजेक्ट को बढ़ावा देने के लिए एक सम्मेलन में बोलने पर विचार करें। सम्मेलन आपको अधिक लोगों तक पहुँचने में मदद कर सकते हैं, कभी-कभी दुनिया भर से। -Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers. +ऐसे सम्मेलनों की तलाश करें जो आपकी भाषा या पारिस्थितिकी तंत्र के लिए विशिष्ट हों। अपना भाषण प्रस्तुत करने से पहले, उपस्थित लोगों के लिए अपनी बात तैयार करने के लिए सम्मेलन पर शोध करें और सम्मेलन में बोलने के लिए स्वीकार किए जाने की संभावना बढ़ाएं। आप अक्सर सम्मेलन के वक्ताओं को देखकर अपने दर्शकों के बारे में अंदाजा लगा सकते हैं। -## Build a reputation +## प्रतिष्ठा बनायें -In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects. +ऊपर उल्लिखित रणनीतियों के अलावा, लोगों को अपने प्रोजेक्ट में साझा करने और योगदान करने के लिए आमंत्रित करने का सबसे अच्छा तरीका उनकी परियोजनाओं को साझा करना और योगदान देना है। -Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships. +नए लोगों की मदद करना, संसाधन साझा करना और दूसरों की परियोजनाओं में विचारशील योगदान देना आपको सकारात्मक प्रतिष्ठा बनाने में मदद करेगा। ओपन सोर्स समुदाय में एक सक्रिय सदस्य होने से लोगों को आपके काम के संदर्भ में मदद मिलेगी और आपके प्रोजेक्ट पर ध्यान देने और साझा करने की अधिक संभावना होगी। अन्य ओपन सोर्स परियोजनाओं के साथ संबंध विकसित करने से आधिकारिक साझेदारी भी हो सकती है। -It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others. +अपनी प्रतिष्ठा बनाना शुरू करने के लिए कभी भी बहुत जल्दी या बहुत देर नहीं होती है। भले ही आपने अपना खुद का प्रोजेक्ट पहले ही लॉन्च कर दिया हो, दूसरों की मदद करने के तरीकों की तलाश जारी रखें। -There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. +दर्शक वर्ग बनाने का कोई रातोरात समाधान नहीं है। दूसरों का विश्वास और सम्मान हासिल करने में समय लगता है, और आपकी प्रतिष्ठा बनाना कभी ख़त्म नहीं होता। -## Keep at it! +## बने रहिए! -It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. +लोगों को आपके ओपन सोर्स प्रोजेक्ट पर ध्यान देने में काफी समय लग सकता है। वह ठीक है! आज की कुछ सबसे लोकप्रिय परियोजनाओं को गतिविधि के उच्च स्तर तक पहुंचने में वर्षों लग गए। यह आशा करने के बजाय कि आपका प्रोजेक्ट अनायास लोकप्रियता हासिल कर लेगा, संबंध बनाने पर ध्यान केंद्रित करें। धैर्य रखें और अपना काम उन लोगों के साथ साझा करते रहें जो इसकी सराहना करते हैं। diff --git a/_articles/hi/index.html b/_articles/hi/index.html index ef7a7cb9a84..454d05a6705 100644 --- a/_articles/hi/index.html +++ b/_articles/hi/index.html @@ -1,5 +1,6 @@ --- layout: index +title: ओपन सोर्स गाइड lang: hi permalink: /hi/ --- From bd78cd3a6a9c6c107477915a0310cacc182d92cf Mon Sep 17 00:00:00 2001 From: James Titus Date: Thu, 31 Aug 2023 22:20:33 +0530 Subject: [PATCH 04/25] hindi --articles update --- _articles/hi/getting-paid.md | 162 +++++++++--------- _articles/hi/leadership-and-governance.md | 117 ++++++------- _articles/hi/legal.md | 144 ++++++++-------- ...ing-balance-for-open-source-maintainers.md | 142 +++++++-------- _articles/hi/metrics.md | 126 +++++++------- _data/locales/hi.yml | 2 +- 6 files changed, 350 insertions(+), 343 deletions(-) diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md index 7fd4a32af4c..c0aaf21f9d4 100644 --- a/_articles/hi/getting-paid.md +++ b/_articles/hi/getting-paid.md @@ -1,7 +1,7 @@ --- -lang: en -title: Getting Paid for Open Source Work -description: Sustain your work in open source by getting financial support for your time or your project. +lang: hi +title: ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना +description: अपने समय या अपने प्रोजेक्ट के लिए वित्तीय सहायता प्राप्त करके अपने काम को खुले स्रोत में बनाए रखें। class: getting-paid order: 7 image: /assets/images/cards/getting-paid.png @@ -10,169 +10,171 @@ related: - leadership --- -## Why some people seek financial support +## कुछ लोग वित्तीय सहायता क्यों चाहते हैं? -Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. +ओपन सोर्स का अधिकांश कार्य स्वैच्छिक है। उदाहरण के लिए, हो सकता है कि किसी को अपने द्वारा उपयोग किए जा रहे किसी प्रोजेक्ट में बग का सामना करना पड़े और वह त्वरित समाधान सबमिट कर दे, या हो सकता है कि वे अपने खाली समय में किसी ओपन सोर्स प्रोजेक्ट के साथ छेड़छाड़ करने का आनंद लें। -There are many reasons why a person would not want to be paid for their open source work. +ऐसे कई कारण हैं जिनकी वजह से कोई व्यक्ति अपने ओपन सोर्स कार्य के लिए भुगतान नहीं करना चाहेगा। -* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. -* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. -* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. +* **उनके पास पहले से ही एक पूर्णकालिक नौकरी हो सकती है जो उन्हें पसंद है,** जो उन्हें अपने खाली समय में ओपन सोर्स में योगदान करने में सक्षम बनाती है। +* **वे ओपन सोर्स को एक शौक** या रचनात्मक पलायन के रूप में सोचने का आनंद लेते हैं और अपनी परियोजनाओं पर काम करने के लिए वित्तीय रूप से बाध्य महसूस नहीं करना चाहते हैं। +* **उन्हें ओपन सोर्स में योगदान करने से अन्य लाभ मिलते हैं,** जैसे कि उनकी प्रतिष्ठा या पोर्टफोलियो बनाना, एक नया कौशल सीखना, या किसी समुदाय के करीब महसूस करना। -For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. +दूसरों के लिए, विशेष रूप से जब योगदान जारी है या महत्वपूर्ण समय की आवश्यकता है, तो ओपन सोर्स में योगदान करने के लिए भुगतान प्राप्त करना ही एकमात्र तरीका है जिससे वे भाग ले सकते हैं, या तो क्योंकि परियोजना को इसकी आवश्यकता है, या व्यक्तिगत कारणों से। -Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. +लोकप्रिय परियोजनाओं को बनाए रखना एक महत्वपूर्ण जिम्मेदारी हो सकती है, जिसमें प्रति माह कुछ घंटों के बजाय प्रति सप्ताह 10 या 20 घंटे लगते हैं। -Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. +भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unread-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय। -If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. +यदि आप वित्तीय सहायता की तलाश में हैं, तो विचार करने के लिए दो रास्ते हैं। आप एक योगदानकर्ता के रूप में अपने समय का वित्तपोषण कर सकते हैं, या आप परियोजना के लिए संगठनात्मक वित्तपोषण पा सकते हैं। -## Funding your own time +## अपने समय का वित्तपोषण करना -Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. +आज, कई लोगों को ओपन सोर्स पर अंशकालिक या पूर्णकालिक काम करने के लिए भुगतान मिलता है। अपने समय के लिए भुगतान पाने का सबसे आम तरीका अपने नियोक्ता से बात करना है। -It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. +यदि आपका नियोक्ता वास्तव में परियोजना का उपयोग करता है, तो ओपन सोर्स कार्य के लिए मामला बनाना आसान है, लेकिन अपनी पिच के साथ रचनात्मक बनें। हो सकता है कि आपका नियोक्ता प्रोजेक्ट का उपयोग नहीं करता हो, लेकिन वे पायथन का उपयोग करते हैं, और एक लोकप्रिय पायथन प्रोजेक्ट को बनाए रखने से नए पायथन डेवलपर्स को आकर्षित करने में मदद मिलती है। शायद यह आपके नियोक्ता को सामान्य रूप से अधिक डेवलपर-अनुकूल बनाता है। -If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. +यदि आपके पास कोई मौजूदा ओपन सोर्स प्रोजेक्ट नहीं है जिस पर आप काम करना चाहेंगे, बल्कि चाहेंगे कि आपका वर्तमान कार्य आउटपुट ओपन सोर्स हो, तो अपने नियोक्ता के लिए उनके कुछ आंतरिक सॉफ़्टवेयर को ओपन सोर्स करने का मामला बनाएं। -Many companies are developing open source programs to build their brand and recruit quality talent. +कई कंपनियां अपना ब्रांड बनाने और गुणवत्तापूर्ण प्रतिभाओं की भर्ती के लिए ओपन सोर्स प्रोग्राम विकसित कर रही हैं। -@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: +उदाहरण के लिए, @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) +भर्ती में: -> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. +> यह हमारी हैकर संस्कृति और हमारे संगठन को कैसे समझा जाता है, के साथ निकटता से जुड़ा हुआ है। हमने अपने कर्मचारियों से पूछा, "क्या आप फेसबुक के ओपन सोर्स सॉफ़्टवेयर प्रोग्राम के बारे में जानते थे?" दो-तिहाई ने कहा "हाँ"। एक-आधे ने कहा कि कार्यक्रम ने हमारे लिए काम करने के उनके निर्णय में सकारात्मक योगदान दिया। ये सीमांत संख्याएं नहीं हैं, और मुझे आशा है कि यह प्रवृत्ति जारी रहेगी। -If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. +यदि आपकी कंपनी इस मार्ग पर चलती है, तो समुदाय और कॉर्पोरेट गतिविधि के बीच की सीमाओं को स्पष्ट रखना महत्वपूर्ण है। अंततः, ओपन सोर्स दुनिया भर के लोगों के योगदान के माध्यम से खुद को कायम रखता है, और यह किसी एक कंपनी या स्थान से बड़ा है। -If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: +यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए: -* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source -* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees +*कुछ कंपनियाँ, जैसे [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/) कर्मचारियों के लिए इसका प्रकाशन किया। -Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. +ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है। -Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: +अपनी व्यक्तिगत परिस्थितियों के आधार पर, आप अपने ओपन सोर्स कार्य के वित्तपोषण के लिए स्वतंत्र रूप से धन जुटाने का प्रयास कर सकते हैं। उदाहरण के लिए: -* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) -* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) -* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) +* @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) -Finally, sometimes open source projects put bounties on issues that you might consider helping with. +अंत में, कभी-कभी ओपन सोर्स प्रोजेक्ट उन मुद्दों पर इनाम देते हैं जिनमें आप मदद करने पर विचार कर सकते हैं। -* @ConnorChristie was able to get paid for [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 did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). +* @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). -## Finding funding for your project +## अपने प्रोजेक्ट के लिए फंडिंग ढूँढना -Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. +व्यक्तिगत योगदानकर्ताओं के लिए व्यवस्था से परे, कभी-कभी परियोजनाएं चल रहे काम को निधि देने के लिए कंपनियों, व्यक्तियों या अन्य लोगों से धन जुटाती हैं। -Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas. +संगठनात्मक फंडिंग वर्तमान योगदानकर्ताओं को भुगतान करने, परियोजना चलाने की लागत (जैसे होस्टिंग शुल्क) को कवर करने, या नई सुविधाओं या विचारों में निवेश करने में जा सकती है। -As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. +जैसे-जैसे ओपन सोर्स की लोकप्रियता बढ़ती है, परियोजनाओं के लिए फंडिंग ढूंढना अभी भी प्रयोगात्मक है, लेकिन कुछ सामान्य विकल्प उपलब्ध हैं। -### Raise money for your work through crowdfunding campaigns or sponsorships +### क्राउडफंडिंग अभियानों या प्रायोजन के माध्यम से अपने काम के लिए धन जुटाएं -Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. -A few examples of sponsored projects include: +यदि आपके पास पहले से ही एक मजबूत दर्शक वर्ग या प्रतिष्ठा है, या आपका प्रोजेक्ट बहुत लोकप्रिय है, तो प्रायोजन ढूँढना अच्छा काम करता है। +प्रायोजित परियोजनाओं के कुछ उदाहरणों में शामिल हैं: -* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) -* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects +* **[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 -### Create a revenue stream +### एक राजस्व धारा बनाएँ -Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: +आपके प्रोजेक्ट के आधार पर, आप व्यावसायिक सहायता, होस्ट किए गए विकल्पों या अतिरिक्त सुविधाओं के लिए शुल्क लेने में सक्षम हो सकते हैं। कुछ उदाहरणों में शामिल हैं: -* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support -* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product -* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service +* **[Sidekiq](https://github.com/mperham/sidekiq)** अतिरिक्त सहायता के लिए सशुल्क संस्करण प्रदान करता है +* **[Travis CI](https://github.com/travis-ci)** अपने उत्पाद के सशुल्क संस्करण प्रदान करता है +* **[Ghost](https://github.com/TryGhost/Ghost)** सशुल्क प्रबंधित सेवा वाला एक गैर-लाभकारी संगठन है -Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. +कुछ लोकप्रिय परियोजनाएँ, जैसे [npm](https://github.com/npm/cli) और [Docker](https://github.com/docker/docker), यहां तक ​​कि अपने व्यवसाय के विकास को समर्थन देने के लिए उद्यम पूंजी भी जुटाते हैं। -### Apply for grant funding +### अनुदान निधि के लिए आवेदन करें -Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. +कुछ सॉफ़्टवेयर फ़ाउंडेशन और कंपनियाँ ओपन सोर्स कार्य के लिए अनुदान प्रदान करती हैं। कभी-कभी, परियोजना के लिए कानूनी इकाई स्थापित किए बिना व्यक्तियों को अनुदान का भुगतान किया जा सकता है। -* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) -* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) -* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) -* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work +* **[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/)** पायथन से संबंधित कार्यों के लिए अनुदान प्रदान करता है। -For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. +अधिक विस्तृत विकल्पों और केस अध्ययन के लिए, @nayafia [एक गाइड लिखा](https://github.com/nayafia/lemonade-stand) +ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना। विभिन्न प्रकार की फंडिंग के लिए अलग-अलग कौशल की आवश्यकता होती है, इसलिए यह पता लगाने के लिए अपनी ताकत पर विचार करें कि कौन सा विकल्प आपके लिए सबसे अच्छा काम करता है। -## Building a case for financial support +## वित्तीय सहायता के लिए मामला बनाना -Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. +चाहे आपका प्रोजेक्ट एक नया विचार हो, या वर्षों से चला आ रहा हो, आपको अपने लक्षित फंडर की पहचान करने और एक सम्मोहक मामला बनाने में महत्वपूर्ण विचार करने की उम्मीद करनी चाहिए। -Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. +चाहे आप अपने समय के लिए भुगतान करना चाह रहे हों, या किसी परियोजना के लिए धन जुटाना चाह रहे हों, आपको निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होना चाहिए। -### Impact +### प्रभाव -Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? +यह प्रोजेक्ट उपयोगी क्यों है? आपके उपयोगकर्ता, या संभावित उपयोगकर्ता, इसे इतना पसंद क्यों करते हैं? पांच साल में यह कहां होगा? -### Traction +### संकर्षण -Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? +सबूत इकट्ठा करने की कोशिश करें कि आपका प्रोजेक्ट मायने रखता है, चाहे वह मेट्रिक्स, उपाख्यान या प्रशंसापत्र हो। क्या अभी कोई कंपनी या उल्लेखनीय लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं? यदि नहीं, तो क्या किसी प्रमुख व्यक्ति ने इसका समर्थन किया है? -### Value to funder +### फंड देने वाले के लिए मूल्य -Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? +फंडर्स, चाहे आपका नियोक्ता हो या अनुदान देने वाला फाउंडेशन, अक्सर अवसरों के साथ संपर्क किया जाता है। उन्हें किसी अन्य अवसर की अपेक्षा आपके प्रोजेक्ट का समर्थन क्यों करना चाहिए? वे व्यक्तिगत रूप से कैसे लाभान्वित होते हैं? -### Use of funds +### धन का उपयोग -What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. +प्रस्तावित फंडिंग से आप वास्तव में क्या हासिल करेंगे? वेतन देने के बजाय परियोजना की उपलब्धियों या परिणामों पर ध्यान दें। -### How you'll receive the funds +### आपको धनराशि कैसे प्राप्त होगी -Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. +क्या फंडर को संवितरण से संबंधित कोई आवश्यकता है? उदाहरण के लिए, आपको एक गैर-लाभकारी संस्था होने या एक गैर-लाभकारी वित्तीय प्रायोजक होने की आवश्यकता हो सकती है। या शायद धनराशि किसी संगठन के बजाय किसी व्यक्तिगत ठेकेदार को दी जानी चाहिए। ये आवश्यकताएं फंडर्स के बीच अलग-अलग होती हैं, इसलिए पहले से ही अपना शोध करना सुनिश्चित करें। -## Experiment and don't give up +## प्रयोग करो और हार मत मानो -Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. +पैसा जुटाना आसान नहीं है, चाहे आप एक ओपन सोर्स प्रोजेक्ट हों, एक गैर-लाभकारी संस्था हों, या एक सॉफ्टवेयर स्टार्टअप हों, और ज्यादातर मामलों में आपको रचनात्मक होने की आवश्यकता होती है। यह पहचानना कि आप भुगतान कैसे प्राप्त करना चाहते हैं, अपना शोध करना, और अपने आप को अपने फंडर के स्थान पर रखना आपको फंडिंग के लिए एक ठोस मामला बनाने में मदद करेगा। diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md index 6fd75930d5d..579273895c1 100644 --- a/_articles/hi/leadership-and-governance.md +++ b/_articles/hi/leadership-and-governance.md @@ -1,7 +1,7 @@ --- -lang: en -title: Leadership and Governance -description: Growing open source projects can benefit from formal rules for making decisions. +lang: hi +title: नेतृत्व और शासन +description: निर्णय लेने के लिए औपचारिक नियमों से बढ़ते ओपन सोर्स प्रोजेक्ट्स को फायदा हो सकता है। class: leadership order: 6 image: /assets/images/cards/leadership.png @@ -10,147 +10,148 @@ related: - metrics --- -## Understanding governance for your growing project +## अपने बढ़ते प्रोजेक्ट के लिए प्रशासन को समझना -Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. +आपका प्रोजेक्ट बढ़ रहा है, लोग इसमें लगे हुए हैं और आप इस चीज़ को जारी रखने के लिए प्रतिबद्ध हैं। इस स्तर पर, आप सोच रहे होंगे कि नियमित परियोजना योगदानकर्ताओं को अपने वर्कफ़्लो में कैसे शामिल किया जाए, चाहे वह किसी को प्रतिबद्ध पहुंच प्रदान करना हो या सामुदायिक बहस को हल करना हो। यदि आपके कोई प्रश्न हैं, तो हमें उत्तर मिल गए हैं। -## What are examples of formal roles used in open source projects? +## ओपन सोर्स प्रोजेक्ट्स में उपयोग की जाने वाली औपचारिक भूमिकाओं के उदाहरण क्या हैं? -Many projects follow a similar structure for contributor roles and recognition. +कई परियोजनाएँ योगदानकर्ता भूमिकाओं और मान्यता के लिए समान संरचना का पालन करती हैं। -What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: +हालाँकि, इन भूमिकाओं का वास्तव में क्या मतलब है, यह पूरी तरह आप पर निर्भर है। यहां कुछ प्रकार की भूमिकाएं दी गई हैं जिन्हें आप पहचान सकते हैं: -* **Maintainer** -* **Contributor** -* **Committer** +* **रखरखाव** +* **योगदान देने वाला** +* **कमिटर** -**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers. +**कुछ परियोजनाओं के लिए, "रखरखावकर्ता"** किसी परियोजना में प्रतिबद्ध पहुंच वाले एकमात्र लोग होते हैं। अन्य परियोजनाओं में, वे केवल वे लोग हैं जो रीडमी में अनुरक्षक के रूप में सूचीबद्ध हैं। -A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. +एक अनुरक्षक आवश्यक रूप से ऐसा व्यक्ति नहीं है जो आपके प्रोजेक्ट के लिए कोड लिखता हो। यह कोई ऐसा व्यक्ति हो सकता है जिसने आपके प्रोजेक्ट को प्रचारित करने के लिए बहुत काम किया हो, या लिखित दस्तावेज़ीकरण किया हो जिसने प्रोजेक्ट को दूसरों के लिए अधिक सुलभ बना दिया हो। चाहे वे दिन-प्रतिदिन कुछ भी करें, एक अनुरक्षक संभवतः वह व्यक्ति होता है जो परियोजना की दिशा में ज़िम्मेदारी महसूस करता है और इसे सुधारने के लिए प्रतिबद्ध है। -**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). +**एक "योगदानकर्ता" कोई भी हो सकता है** जो किसी मुद्दे या पुल अनुरोध पर टिप्पणी करता है, जो लोग परियोजना में मूल्य जोड़ते हैं (चाहे वह मुद्दों का परीक्षण करना हो, कोड लिखना हो, या घटनाओं का आयोजन करना हो), या मर्ज किए गए पुल अनुरोध वाला कोई भी व्यक्ति (शायद योगदानकर्ता की सबसे संकीर्ण परिभाषा।) -**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. +**शब्द "कमिटर"** का उपयोग कमिट एक्सेस, जो एक विशिष्ट प्रकार की जिम्मेदारी है, को योगदान के अन्य रूपों से अलग करने के लिए किया जा सकता है। -While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. +हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों। -## How do I formalize these leadership roles? +## मैं इन नेतृत्व भूमिकाओं को कैसे औपचारिक बनाऊं? -Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. +अपनी नेतृत्व भूमिकाओं को औपचारिक बनाने से लोगों को स्वामित्व महसूस करने में मदद मिलती है और समुदाय के अन्य सदस्यों को पता चलता है कि मदद के लिए किससे संपर्क करना चाहिए। -For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. +एक छोटी परियोजना के लिए, नेताओं को नामित करना आपके README या CONTRIBUTORS टेक्स्ट फ़ाइल में उनके नाम जोड़ने जितना आसान हो सकता है। -For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. +किसी बड़े प्रोजेक्ट के लिए, यदि आपके पास कोई वेबसाइट है, तो एक टीम पेज बनाएं या वहां अपने प्रोजेक्ट लीडरों की सूची बनाएं। उदाहरण के लिए, [Postgres](https://github.com/postgres/postgres/) के पास एक [comprehensive team page](https://www.postgresql.org/community/contributors/) प्रत्येक योगदानकर्ता के लिए संक्षिप्त प्रोफ़ाइल के साथ। -If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. +यदि आपके प्रोजेक्ट में बहुत सक्रिय योगदानकर्ता समुदाय है, तो आप अनुरक्षकों की एक "कोर टीम" बना सकते हैं, या ऐसे लोगों की उपसमितियां भी बना सकते हैं जो विभिन्न मुद्दे क्षेत्रों (उदाहरण के लिए, सुरक्षा, समस्या निवारण, या सामुदायिक आचरण) का स्वामित्व लेते हैं। लोगों को वे भूमिकाएँ सौंपने के बजाय स्वयं संगठित होने दें और उनके लिए स्वेच्छा से काम करने दें जिनके बारे में वे सबसे अधिक उत्साहित हैं। -Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). +नेतृत्व दल एक निर्दिष्ट चैनल बनाना चाह सकते हैं (जैसे आईआरसी पर) या परियोजना पर चर्चा करने के लिए नियमित रूप से मिलना चाहते हैं (जैसे गिटर या गूगल हैंगआउट पर)। आप उन बैठकों को सार्वजनिक भी कर सकते हैं ताकि अन्य लोग सुन सकें। [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). -Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. +एक बार जब आप नेतृत्व की भूमिकाएँ स्थापित कर लें, तो यह दस्तावेज करना न भूलें कि लोग उन्हें कैसे प्राप्त कर सकते हैं! कोई आपके प्रोजेक्ट में अनुरक्षक कैसे बन सकता है या उपसमिति में कैसे शामिल हो सकता है, इसके लिए एक स्पष्ट प्रक्रिया स्थापित करें और इसे अपने में लिखें GOVERNANCE.md. -Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. +उपकरण जैसे [Vossibility](https://github.com/icecrime/vossibility-stack) आपको सार्वजनिक रूप से ट्रैक करने में मदद मिल सकती है कि प्रोजेक्ट में कौन योगदान दे रहा है (या नहीं दे रहा है)। इस जानकारी का दस्तावेजीकरण करने से समुदाय की इस धारणा से बचा जा सकता है कि रखरखाव करने वाले एक समूह हैं जो निजी तौर पर अपने निर्णय लेते हैं। -Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). +अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#share-ownership-of-your-project). -## When should I give someone commit access? +## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए? -Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. +कुछ लोग सोचते हैं कि आपको योगदान देने वाले हर व्यक्ति को प्रतिबद्ध पहुंच देनी चाहिए। ऐसा करने से अधिक लोग आपके प्रोजेक्ट पर स्वामित्व महसूस करने के लिए प्रोत्साहित हो सकते हैं। -On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! +दूसरी ओर, विशेष रूप से बड़ी, अधिक जटिल परियोजनाओं के लिए, आप केवल उन लोगों को प्रतिबद्ध पहुंच देना चाह सकते हैं जिन्होंने अपनी प्रतिबद्धता प्रदर्शित की है। इसे करने का कोई एक सही तरीका नहीं है - वही करें जो आपको सबसे अधिक आरामदायक लगे! -If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. +यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://help.github.com/articles/about-protected-branches/) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में। -## What are some of the common governance structures for open source projects? +## ओपन सोर्स परियोजनाओं के लिए कुछ सामान्य शासन संरचनाएँ क्या हैं? -There are three common governance structures associated with open source projects. +ओपन सोर्स परियोजनाओं से जुड़ी तीन सामान्य शासन संरचनाएँ हैं। -* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. +* **बीडीएफएल:** बीडीएफएल का अर्थ है "जीवन के लिए परोपकारी तानाशाह"। इस संरचना के तहत, सभी प्रमुख परियोजना निर्णयों पर एक व्यक्ति (आमतौर पर परियोजना का प्रारंभिक लेखक) का अंतिम अधिकार होता है। [Python](https://github.com/python) एक उत्कृष्ट उदाहरण है. छोटी परियोजनाएँ संभवतः डिफ़ॉल्ट रूप से बीडीएफएल हैं, क्योंकि केवल एक या दो अनुरक्षक होते हैं। किसी कंपनी में शुरू हुआ प्रोजेक्ट भी बीडीएफएल श्रेणी में आ सकता है। -* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. +* **मेरिटोक्रेसी:** **(नोट: शब्द "मेरिटोक्रेसी" कुछ समुदायों के लिए नकारात्मक अर्थ रखता है और इसका एक नकारात्मक प्रभाव है[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) +योग्यतातंत्र हैं. योगदान केवल अपना प्रतिनिधित्व करने वाले व्यक्तियों द्वारा ही किया जा सकता है, किसी कंपनी द्वारा नहीं। -* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). +* **उदार योगदान:** उदार योगदान मॉडल के तहत, जो लोग सबसे अधिक काम करते हैं उन्हें सबसे प्रभावशाली माना जाता है, लेकिन यह वर्तमान कार्य पर आधारित है न कि ऐतिहासिक योगदान पर। प्रमुख परियोजना निर्णय शुद्ध वोट के बजाय सर्वसम्मति प्राप्त करने की प्रक्रिया (प्रमुख शिकायतों पर चर्चा) के आधार पर किए जाते हैं, और यथासंभव अधिक से अधिक सामुदायिक दृष्टिकोणों को शामिल करने का प्रयास किया जाता है। उदार योगदान मॉडल का उपयोग करने वाली परियोजनाओं के लोकप्रिय उदाहरणों में शामिल हैं [Node.js](https://foundation.nodejs.org/) और [Rust](https://www.rust-lang.org/). -Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: +आपको किसका उपयोग करना चाहिए? यह आप पर निर्भर करता है! हर मॉडल के फायदे और फायदे हैं। और यद्यपि वे पहली बार में काफी भिन्न लग सकते हैं, तीनों मॉडलों में जितना वे दिखते हैं उससे कहीं अधिक समानता है। यदि आप इनमें से किसी एक मॉडल को अपनाने में रुचि रखते हैं, तो इन टेम्पलेट्स को देखें: * [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) -## Do I need governance docs when I launch my project? +## क्या मुझे अपना प्रोजेक्ट लॉन्च करते समय शासन दस्तावेज़ों की आवश्यकता होगी? -There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! +आपके प्रोजेक्ट के प्रशासन को लिखने का कोई सही समय नहीं है, लेकिन एक बार जब आप अपने समुदाय की गतिशीलता को देख लेंगे तो इसे परिभाषित करना बहुत आसान हो जाएगा। ओपन सोर्स गवर्नेंस के बारे में सबसे अच्छी (और सबसे कठिन) बात यह है कि इसे समुदाय द्वारा आकार दिया जाता है! -Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. +हालाँकि, कुछ शुरुआती दस्तावेज़ अनिवार्य रूप से आपके प्रोजेक्ट के प्रशासन में योगदान देंगे, इसलिए आप जो कर सकते हैं उसे लिखना शुरू कर दें। उदाहरण के लिए, आप व्यवहार के लिए स्पष्ट अपेक्षाओं को परिभाषित कर सकते हैं, या आपके प्रोजेक्ट के लॉन्च पर भी आपकी योगदानकर्ता प्रक्रिया कैसे काम करती है। -If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. +यदि आप एक ओपन सोर्स प्रोजेक्ट लॉन्च करने वाली कंपनी का हिस्सा हैं, तो लॉन्च से पहले इस बारे में आंतरिक चर्चा करना उचित है कि आपकी कंपनी प्रोजेक्ट को आगे बढ़ाने के बारे में कैसे बनाए रखने और निर्णय लेने की उम्मीद करती है। हो सकता है कि आप सार्वजनिक रूप से यह स्पष्ट करना चाहें कि आपकी कंपनी इस परियोजना में कैसे शामिल होगी (या नहीं करेगी!)। -## What happens if corporate employees start submitting contributions? +## यदि कॉर्पोरेट कर्मचारी अंशदान जमा करना शुरू कर दें तो क्या होगा? -Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. +सफल ओपन सोर्स परियोजनाओं का उपयोग कई लोगों और कंपनियों द्वारा किया जाता है, और कुछ कंपनियों के पास अंततः राजस्व धाराएं परियोजना से जुड़ी हो सकती हैं। उदाहरण के लिए, कोई कंपनी किसी वाणिज्यिक सेवा पेशकश में परियोजना के कोड को एक घटक के रूप में उपयोग कर सकती है। -As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. +जैसे-जैसे परियोजना अधिक व्यापक रूप से उपयोग की जाती है, इसमें विशेषज्ञता रखने वाले लोगों की मांग अधिक हो जाती है - आप उनमें से एक हो सकते हैं! - और कभी-कभी उन्हें प्रोजेक्ट में किए गए काम के लिए भुगतान मिलेगा। -It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. +व्यावसायिक गतिविधि को सामान्य और विकास ऊर्जा के एक अन्य स्रोत के रूप में मानना ​​महत्वपूर्ण है। निःसंदेह, भुगतान किए गए डेवलपर्स को अवैतनिक डेवलपर्स की तुलना में विशेष व्यवहार नहीं मिलना चाहिए; प्रत्येक योगदान का मूल्यांकन उसकी तकनीकी खूबियों के आधार पर किया जाना चाहिए। हालाँकि, लोगों को व्यावसायिक गतिविधि में शामिल होने में सहज महसूस करना चाहिए, और किसी विशेष वृद्धि या सुविधा के पक्ष में बहस करते समय अपने उपयोग के मामलों को बताने में सहज महसूस करना चाहिए। -"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) +"वाणिज्यिक" "ओपन सोर्स" के साथ पूरी तरह से संगत है। "वाणिज्यिक" का सीधा सा मतलब है कि इसमें कहीं न कहीं पैसा शामिल है - कि सॉफ्टवेयर का उपयोग वाणिज्य में किया जाता है, जो कि एक परियोजना के अपनाने के रूप में तेजी से संभव है। (जब ओपन सोर्स सॉफ़्टवेयर का उपयोग गैर-ओपन-सोर्स उत्पाद के हिस्से के रूप में किया जाता है, तो समग्र उत्पाद अभी भी "मालिकाना" सॉफ़्टवेयर होता है, हालांकि, ओपन सोर्स की तरह, इसका उपयोग वाणिज्यिक या गैर-व्यावसायिक उद्देश्यों के लिए किया जा सकता है।) -Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. +किसी भी अन्य की तरह, व्यावसायिक रूप से प्रेरित डेवलपर्स अपने योगदान की गुणवत्ता और मात्रा के माध्यम से परियोजना में प्रभाव प्राप्त करते हैं। जाहिर है, एक डेवलपर जिसे उसके समय के लिए भुगतान किया जाता है, वह उस व्यक्ति से अधिक काम करने में सक्षम हो सकता है जिसे भुगतान नहीं किया जाता है, लेकिन यह ठीक है: भुगतान कई संभावित कारकों में से एक है जो किसी के काम को प्रभावित कर सकता है। अपनी परियोजना चर्चाओं को योगदानों पर केंद्रित रखें, न कि उन बाहरी कारकों पर जो लोगों को योगदान देने में सक्षम बनाते हैं। -## Do I need a legal entity to support my project? +## क्या मुझे अपने प्रोजेक्ट का समर्थन करने के लिए एक कानूनी इकाई की आवश्यकता है? -You don't need a legal entity to support your open source project unless you're handling money. +जब तक आप पैसे का प्रबंधन नहीं कर रहे हों, आपको अपने ओपन सोर्स प्रोजेक्ट का समर्थन करने के लिए किसी कानूनी इकाई की आवश्यकता नहीं है। -For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). +उदाहरण के लिए, यदि आप एक वाणिज्यिक व्यवसाय बनाना चाहते हैं, तो आप एक सी कॉर्प या एलएलसी स्थापित करना चाहेंगे (यदि आप अमेरिका में स्थित हैं)। यदि आप केवल अपने ओपन सोर्स प्रोजेक्ट से संबंधित अनुबंध कार्य कर रहे हैं, तो आप एकमात्र मालिक के रूप में धन स्वीकार कर सकते हैं, या एलएलसी स्थापित कर सकते हैं (यदि आप अमेरिका में स्थित हैं)। -If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). +यदि आप अपने ओपन सोर्स प्रोजेक्ट के लिए दान स्वीकार करना चाहते हैं, तो आप एक दान बटन सेट कर सकते हैं (उदाहरण के लिए पेपैल या स्ट्राइप का उपयोग करके), लेकिन पैसा तब तक कर-कटौती योग्य नहीं होगा जब तक कि आप एक योग्य गैर-लाभकारी संस्था (501c3, यदि आप अमेरिका में हैं)। -Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [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) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. +कई परियोजनाएँ एक गैर-लाभकारी संस्था स्थापित करने की परेशानी से गुज़रना नहीं चाहती हैं, इसलिए वे इसके बजाय एक गैर-लाभकारी राजकोषीय प्रायोजक ढूंढती हैं। एक राजकोषीय प्रायोजक आपकी ओर से दान स्वीकार करता है, आमतौर पर दान के एक प्रतिशत के बदले में। [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) ऐसे संगठनों के उदाहरण हैं जो ओपन सोर्स परियोजनाओं के लिए वित्तीय प्रायोजक के रूप में काम करते हैं। -If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. +यदि आपका प्रोजेक्ट किसी निश्चित भाषा या पारिस्थितिकी तंत्र से निकटता से जुड़ा हुआ है, तो एक संबंधित सॉफ़्टवेयर फ़ाउंडेशन भी हो सकता है जिसके साथ आप काम कर सकते हैं। उदाहरण के लिए, [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 index 8adc3897659..a1ebf7d8a6c 100644 --- a/_articles/hi/legal.md +++ b/_articles/hi/legal.md @@ -1,7 +1,7 @@ --- -lang: en -title: The Legal Side of Open Source -description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +lang: hi +title: ओपन सोर्स का कानूनी पक्ष +description: ओपन सोर्स के कानूनी पक्ष के बारे में आपने जो कुछ भी सोचा है, और कुछ चीजें जो आपने नहीं सोची हैं। class: legal order: 10 image: /assets/images/cards/legal.png @@ -10,149 +10,153 @@ related: - leadership --- -## Understanding the legal implications of open source +## ओपन सोर्स के कानूनी निहितार्थ को समझना -Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) +अपने रचनात्मक कार्य को दुनिया के साथ साझा करना एक रोमांचक और पुरस्कृत अनुभव हो सकता है। इसका मतलब यह भी हो सकता है कि कई कानूनी चीजें जिनके बारे में आप नहीं जानते कि आपको चिंता करने की ज़रूरत है। शुक्र है, आपको शून्य से शुरुआत करने की ज़रूरत नहीं है। हमने आपकी कानूनी ज़रूरतें पूरी कर ली हैं। (इससे पहले कि आप गहराई से जानें, हमारा पढ़ना सुनिश्चित करें [disclaimer](/notices/).) -## Why do people care so much about the legal side of open source? +## लोग ओपन सोर्स के कानूनी पक्ष की इतनी परवाह क्यों करते हैं? -Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. +ख़ुशी है कि आपने पूछा! जब आप कोई रचनात्मक कार्य (जैसे लेखन, ग्राफ़िक्स, या कोड) करते हैं, तो वह कार्य डिफ़ॉल्ट रूप से विशेष कॉपीराइट के अंतर्गत होता है। यानी, कानून मानता है कि आपके काम के लेखक के रूप में, आपको यह कहने का अधिकार है कि दूसरे इसके साथ क्या कर सकते हैं। -In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. +सामान्य तौर पर, इसका मतलब यह है कि कोई भी अन्य व्यक्ति टेक-डाउन, शेक-डाउन या मुकदमेबाजी के जोखिम के बिना आपके काम का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है। -Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. +हालाँकि, ओपन सोर्स एक असामान्य परिस्थिति है, क्योंकि लेखक को उम्मीद है कि अन्य लोग काम का उपयोग, संशोधन और साझा करेंगे। लेकिन चूँकि कानूनी डिफ़ॉल्ट अभी भी अनन्य कॉपीराइट है, इसलिए आपको एक ऐसे लाइसेंस की आवश्यकता है जो इन अनुमतियों को स्पष्ट रूप से बताता हो। -If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. +यदि आप ओपन सोर्स लाइसेंस लागू नहीं करते हैं, तो आपके प्रोजेक्ट में योगदान देने वाला प्रत्येक व्यक्ति भी अपने काम का विशेष कॉपीराइट धारक बन जाता है। इसका मतलब है कि कोई भी उनके योगदान का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है - और उस "कोई भी" में आप शामिल नहीं हैं। -Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. +अंततः, आपके प्रोजेक्ट में लाइसेंस आवश्यकताओं वाली निर्भरताएँ हो सकती हैं जिनके बारे में आपको जानकारी नहीं थी। आपके प्रोजेक्ट के समुदाय, या आपके नियोक्ता की नीतियों के लिए, आपके प्रोजेक्ट को विशिष्ट ओपन सोर्स लाइसेंस का उपयोग करने की भी आवश्यकता हो सकती है। हम नीचे इन स्थितियों को कवर करेंगे। -## Are public GitHub projects open source? +## क्या सार्वजनिक GitHub परियोजनाएँ खुला स्रोत हैं? -When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. +जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://help.github.com/articles/creating-a-new-repository/), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है। ![Create repository](/assets/images/legal/repo-create-name.png) -**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [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), which allows others to view and fork your project, but your work otherwise comes with no permissions. +**अपने 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), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है। -If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. +यदि आप चाहते हैं कि अन्य लोग आपके प्रोजेक्ट का उपयोग, वितरण, संशोधन या योगदान करें, तो आपको एक ओपन सोर्स लाइसेंस शामिल करना होगा। उदाहरण के लिए, कोई व्यक्ति आपके GitHub प्रोजेक्ट के किसी भी हिस्से को अपने कोड में कानूनी रूप से उपयोग नहीं कर सकता, भले ही वह सार्वजनिक हो, जब तक कि आप स्पष्ट रूप से उन्हें ऐसा करने का अधिकार नहीं देते। -## Just give me the TL;DR on what I need to protect my project. +## बस मुझे टीएल;डीआर दें कि मुझे अपने प्रोजेक्ट की सुरक्षा के लिए क्या चाहिए। -You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. +आप भाग्यशाली हैं, क्योंकि आज, ओपन सोर्स लाइसेंस मानकीकृत और उपयोग में आसान हैं। आप किसी मौजूदा लाइसेंस को सीधे अपने प्रोजेक्ट में कॉपी-पेस्ट कर सकते हैं। -[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/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). +[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/). -When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). +जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://help.github.com/articles/open-source-licensing/). -## Which open source license is appropriate for my project? +## मेरे प्रोजेक्ट के लिए कौन सा ओपन सोर्स लाइसेंस उपयुक्त है? -If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. +यदि आप कोरी स्लेट से शुरुआत कर रहे हैं, तो इसमें गलत होना कठिन है [MIT License](https://choosealicense.com/licenses/mit/). यह संक्षिप्त है, समझने में बहुत आसान है, और किसी को भी कुछ भी करने की अनुमति देता है जब तक कि वे आपके कॉपीराइट नोटिस सहित लाइसेंस की एक प्रति अपने पास रखते हैं। यदि आपको कभी आवश्यकता होगी तो आप प्रोजेक्ट को एक अलग लाइसेंस के तहत जारी करने में सक्षम होंगे। -Otherwise, picking the right open source license for your project depends on your objectives. +अन्यथा, आपके प्रोजेक्ट के लिए सही ओपन सोर्स लाइसेंस चुनना आपके उद्देश्यों पर निर्भर करता है। -Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. +आपके प्रोजेक्ट की बहुत संभावना है (या होगी) **dependencies**. उदाहरण के लिए, यदि आप Node.js प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं, तो आप संभवतः नोड पैकेज मैनेजर (npm) से लाइब्रेरी का उपयोग करेंगे। आप जिन पुस्तकालयों पर निर्भर हैं उनमें से प्रत्येक के पास अपना स्वयं का ओपन सोर्स लाइसेंस होगा। यदि उनका प्रत्येक लाइसेंस "अनुमोदनात्मक" है (डाउनस्ट्रीम लाइसेंसिंग के लिए बिना किसी शर्त के जनता को उपयोग, संशोधन और साझा करने की अनुमति देता है), तो आप अपने इच्छित किसी भी लाइसेंस का उपयोग कर सकते हैं। सामान्य अनुमेय लाइसेंस में एमआईटी, अपाचे 2.0, आईएससी और बीएसडी शामिल हैं। -On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. +दूसरी ओर, यदि आपकी किसी निर्भरता का लाइसेंस "मजबूत कॉपीलेफ्ट" है (सार्वजनिक रूप से समान अनुमतियाँ देता है, समान लाइसेंस डाउनस्ट्रीम का उपयोग करने की शर्त के अधीन), तो आपके प्रोजेक्ट को उसी लाइसेंस का उपयोग करना होगा। सामान्य मजबूत कॉपीलेफ़्ट लाइसेंस में GPLv2, GPLv3, और AGPLv3 शामिल हैं। -You may also want to consider the **communities** you hope will use and contribute to your project: +आप शायद उन **communities** पर भी विचार करना चाहेंगे जिनका आप उपयोग करेंगे और आपके प्रोजेक्ट में योगदान देंगे: -* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). -* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. -* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. +* **क्या आप चाहते हैं कि आपकी परियोजना का उपयोग अन्य परियोजनाओं द्वारा निर्भरता के रूप में किया जाए?** संभवतः आपके प्रासंगिक समुदाय में सबसे लोकप्रिय लाइसेंस का उपयोग करना सबसे अच्छा है। उदाहरण के लिए, [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/) +अच्छा चलेगा। -Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). +आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#what-does-my-companys-legal-team-need-to-know) से बातें करें। -When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). +जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/). -## What if I want to change the license of my project? +## यदि मैं अपने प्रोजेक्ट का लाइसेंस बदलना चाहूँ तो क्या होगा? -Most projects never need to change licenses. But occasionally circumstances change. +अधिकांश परियोजनाओं को कभी भी लाइसेंस बदलने की आवश्यकता नहीं होती है। लेकिन कभी-कभी हालात बदल जाते हैं. -For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: +उदाहरण के लिए, जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, इसमें निर्भरताएँ या उपयोगकर्ता जुड़ते हैं, या आपकी कंपनी रणनीतियाँ बदलती है, जिनमें से किसी को भी अलग लाइसेंस की आवश्यकता हो सकती है या चाहिए। साथ ही, यदि आपने शुरू से ही अपने प्रोजेक्ट को लाइसेंस देने की उपेक्षा की है, तो लाइसेंस जोड़ना प्रभावी रूप से लाइसेंस बदलने के समान है। अपने प्रोजेक्ट का लाइसेंस जोड़ते या बदलते समय विचार करने योग्य तीन मूलभूत बातें हैं: -**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! +**यह जटिल है।** लाइसेंस अनुकूलता और अनुपालन का निर्धारण करना और कॉपीराइट किसके पास है, यह बहुत जल्दी जटिल और भ्रमित करने वाला हो सकता है। नई रिलीज़ और योगदान के लिए नए लेकिन संगत लाइसेंस पर स्विच करना सभी मौजूदा योगदानों को दोबारा लाइसेंस देने से अलग है। लाइसेंस बदलने की इच्छा के पहले संकेत पर अपनी कानूनी टीम को शामिल करें। भले ही आपके पास लाइसेंस परिवर्तन के लिए अपने प्रोजेक्ट के कॉपीराइट धारकों से अनुमति है या आप प्राप्त कर सकते हैं, फिर भी अपने प्रोजेक्ट के अन्य उपयोगकर्ताओं और योगदानकर्ताओं पर परिवर्तन के प्रभाव पर विचार करें। अपने प्रोजेक्ट के लिए लाइसेंस परिवर्तन को एक "गवर्नेंस इवेंट" के रूप में सोचें, जो आपके प्रोजेक्ट के हितधारकों के साथ स्पष्ट संचार और परामर्श के साथ आसानी से चलेगा। शुरुआत से ही अपने प्रोजेक्ट के लिए उपयुक्त लाइसेंस चुनने और उसका उपयोग करने का और भी अधिक कारण! -**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. +**आपके प्रोजेक्ट का मौजूदा लाइसेंस।** यदि आपके प्रोजेक्ट का मौजूदा लाइसेंस उस लाइसेंस के अनुकूल है जिसे आप बदलना चाहते हैं, तो आप नए लाइसेंस का उपयोग शुरू कर सकते हैं। ऐसा इसलिए है क्योंकि यदि लाइसेंस ए लाइसेंस बी के साथ संगत है, तो आप बी की शर्तों का अनुपालन करते समय ए की शर्तों का अनुपालन करेंगे (लेकिन जरूरी नहीं कि इसका विपरीत भी हो)। इसलिए यदि आप वर्तमान में एक अनुमेय लाइसेंस (उदाहरण के लिए, एमआईटी) का उपयोग कर रहे हैं, तो आप अधिक शर्तों वाले लाइसेंस में बदल सकते हैं, जब तक कि आप एमआईटी लाइसेंस और किसी भी संबंधित कॉपीराइट नोटिस की एक प्रति अपने पास रखते हैं (यानी, इसका अनुपालन करना जारी रखते हैं। एमआईटी लाइसेंस की न्यूनतम शर्तें)। लेकिन यदि आपका वर्तमान लाइसेंस अनुमेय नहीं है (उदाहरण के लिए, कॉपीलेफ्ट, या आपके पास लाइसेंस नहीं है) और आप एकमात्र कॉपीराइट धारक नहीं हैं, तो आप अपने प्रोजेक्ट के लाइसेंस को एमआईटी में नहीं बदल सकते। मूलतः, अनुमेय लाइसेंस के साथ परियोजना के कॉपीराइट धारकों ने लाइसेंस बदलने की अग्रिम अनुमति दे दी है। -**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. +**आपके प्रोजेक्ट के मौजूदा कॉपीराइट धारक।** यदि आप अपने प्रोजेक्ट में एकमात्र योगदानकर्ता हैं तो या तो आप या आपकी कंपनी प्रोजेक्ट के एकमात्र कॉपीराइट धारक हैं। आप या आपकी कंपनी जो भी लाइसेंस जोड़ना या बदलना चाहती है, आप उसे जोड़ या बदल सकते हैं। अन्यथा ऐसे अन्य कॉपीराइट धारक भी हो सकते हैं जिनसे लाइसेंस बदलने के लिए आपको सहमति की आवश्यकता होगी। कौन हैं वे? जिन लोगों की आपके प्रोजेक्ट में प्रतिबद्धता है, वे शुरुआत करने के लिए एक अच्छी जगह हैं। लेकिन कुछ मामलों में कॉपीराइट उन लोगों के नियोक्ताओं के पास होगा। कुछ मामलों में लोगों ने केवल न्यूनतम योगदान दिया होगा, लेकिन ऐसा कोई सख्त नियम नहीं है कि कोड की कुछ पंक्तियों के तहत योगदान कॉपीराइट के अधीन नहीं है। क्या करें? निर्भर करता है। अपेक्षाकृत छोटी और युवा परियोजना के लिए, सभी मौजूदा योगदानकर्ताओं को किसी मुद्दे या पुल अनुरोध में लाइसेंस परिवर्तन के लिए सहमत करना संभव हो सकता है। बड़ी और लंबे समय तक चलने वाली परियोजनाओं के लिए, आपको कई योगदानकर्ताओं और यहां तक ​​कि उनके उत्तराधिकारियों की तलाश करनी पड़ सकती है। मोज़िला को फ़ायरफ़ॉक्स, थंडरबर्ड और संबंधित सॉफ़्टवेयर को पुनः लाइसेंस देने में वर्षों (2001-2006) लग गए। -Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. +वैकल्पिक रूप से, आप अपने मौजूदा ओपन सोर्स लाइसेंस द्वारा अनुमत शर्तों से परे, कुछ शर्तों के तहत कुछ लाइसेंस परिवर्तनों के लिए योगदानकर्ताओं को पहले से सहमत कर सकते हैं (एक अतिरिक्त योगदानकर्ता समझौते के माध्यम से - नीचे देखें)। इससे लाइसेंस बदलने की जटिलता कुछ हद तक बदल जाती है। आपको पहले से ही अपने वकीलों से अधिक सहायता की आवश्यकता होगी, और लाइसेंस परिवर्तन निष्पादित करते समय आप अभी भी अपने प्रोजेक्ट के हितधारकों के साथ स्पष्ट रूप से संवाद करना चाहेंगे। -## Does my project need an additional contributor agreement? +## क्या मेरे प्रोजेक्ट को अतिरिक्त योगदानकर्ता समझौते की आवश्यकता है? -Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). +शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). -An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. +एक अतिरिक्त योगदानकर्ता समझौता - जिसे अक्सर Contributor License Agreement (CLA) कहा जाता है - परियोजना अनुरक्षकों के लिए प्रशासनिक कार्य बना सकता है। एक समझौता कितना काम जोड़ता है यह परियोजना और कार्यान्वयन पर निर्भर करता है। एक साधारण समझौते के लिए आवश्यक हो सकता है कि योगदानकर्ता एक क्लिक के साथ पुष्टि करें कि उनके पास प्रोजेक्ट ओपन सोर्स लाइसेंस के तहत योगदान करने के लिए आवश्यक अधिकार हैं। अधिक जटिल समझौते के लिए कानूनी समीक्षा और योगदानकर्ताओं के नियोक्ताओं से हस्ताक्षर की आवश्यकता हो सकती है। -Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. +साथ ही, "कागजी कार्रवाई" जोड़कर, जो कुछ लोगों का मानना ​​है कि अनावश्यक, समझने में कठिन या अनुचित है (जब समझौते के प्राप्तकर्ता को परियोजना के ओपन सोर्स लाइसेंस के माध्यम से योगदानकर्ताओं या जनता की तुलना में अधिक अधिकार मिलते हैं), एक अतिरिक्त योगदानकर्ता समझौते को अमित्र माना जा सकता है परियोजना के समुदाय के लिए। -Some situations where you may want to consider an additional contributor agreement for your project include: +कुछ स्थितियाँ जहाँ आप अपने प्रोजेक्ट के लिए अतिरिक्त योगदानकर्ता समझौते पर विचार करना चाह सकते हैं उनमें शामिल हैं: -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. -* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). -* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. -* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. +* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [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) इस प्रकार के समझौते का एक उदाहरण है. +* आपको लगता है कि आपके प्रोजेक्ट को अपने जीवनकाल में लाइसेंस बदलने की आवश्यकता हो सकती है और आप चाहते हैं कि योगदानकर्ता ऐसे परिवर्तनों के लिए पहले से सहमत हों। -If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. +यदि आपको अपने प्रोजेक्ट के साथ एक अतिरिक्त योगदानकर्ता समझौते का उपयोग करने की आवश्यकता है, तो एक एकीकरण का उपयोग करने पर विचार करें [CLA assistant](https://github.com/cla-assistant/cla-assistant) योगदानकर्ता व्याकुलता को कम करने के लिए। -## What does my company's legal team need to know? +## मेरी कंपनी की कानूनी टीम को क्या जानना आवश्यक है? -If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. +यदि आप एक कंपनी कर्मचारी के रूप में एक ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो सबसे पहले, आपकी कानूनी टीम को पता होना चाहिए कि आप एक प्रोजेक्ट को ओपन सोर्स कर रहे हैं। -For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. +बेहतर या बदतर के लिए, उन्हें बताने पर विचार करें, भले ही यह एक व्यक्तिगत परियोजना हो। संभवत: आपके पास अपनी कंपनी के साथ एक "कर्मचारी आईपी समझौता" है जो उन्हें आपकी परियोजनाओं पर कुछ नियंत्रण देता है, खासकर यदि वे कंपनी के व्यवसाय से संबंधित हैं या आप परियोजना को विकसित करने के लिए किसी कंपनी के संसाधनों का उपयोग करते हैं। आपकी कंपनी को आपको आसानी से अनुमति देनी चाहिए, और शायद पहले से ही एक कर्मचारी-अनुकूल आईपी समझौते या कंपनी नीति के माध्यम से अनुमति दे दी है। यदि नहीं, तो आप बातचीत कर सकते हैं (उदाहरण के लिए, समझाएं कि आपका प्रोजेक्ट आपके लिए कंपनी के पेशेवर शिक्षण और विकास उद्देश्यों को पूरा करता है), या जब तक आपको एक बेहतर कंपनी नहीं मिल जाती, तब तक अपने प्रोजेक्ट पर काम करने से बचें। -**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: +**यदि आप अपनी कंपनी के लिए किसी प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं,** तो उन्हें अवश्य बताएं। आपकी कानूनी टीम के पास संभवतः पहले से ही नीतियां हैं कि कंपनी की व्यावसायिक आवश्यकताओं और विशेषज्ञता के आधार पर किस ओपन सोर्स लाइसेंस (और शायद अतिरिक्त योगदानकर्ता समझौते) का उपयोग किया जाए ताकि यह सुनिश्चित हो सके कि आपका प्रोजेक्ट उसकी निर्भरता के लाइसेंस का अनुपालन करता है। यदि नहीं, तो आप और वे भाग्यशाली हैं! आपकी कानूनी टीम को इस चीज़ का पता लगाने के लिए आपके साथ काम करने के लिए उत्सुक होना चाहिए। सोचने लायक कुछ बातें: -* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. +* **तृतीय पक्ष सामग्री:** क्या आपके प्रोजेक्ट में दूसरों द्वारा बनाई गई निर्भरताएँ हैं या अन्यथा दूसरों के कोड को शामिल या उपयोग करते हैं? यदि ये ओपन सोर्स हैं, तो आपको सामग्रियों के ओपन सोर्स लाइसेंस का अनुपालन करना होगा। इसकी शुरुआत एक ऐसे लाइसेंस को चुनने से होती है जो तीसरे पक्ष के ओपन सोर्स लाइसेंस के साथ काम करता है (ऊपर देखें)। यदि आपका प्रोजेक्ट तृतीय पक्ष ओपन सोर्स सामग्री को संशोधित या वितरित करता है, तो आपकी कानूनी टीम यह भी जानना चाहेगी कि आप तृतीय पक्ष ओपन सोर्स लाइसेंस की अन्य शर्तों को पूरा कर रहे हैं जैसे कि कॉपीराइट नोटिस बनाए रखना। यदि आपका प्रोजेक्ट दूसरों के कोड का उपयोग करता है जिसके पास ओपन सोर्स लाइसेंस नहीं है, तो आपको संभवतः तीसरे पक्ष के अनुरक्षकों से पूछना होगा [एक ओपन सोर्स लाइसेंस जोड़ें](https://choosealicense.com/no-license/#for-users), और यदि आपको कोई नहीं मिल सकता है, तो अपने प्रोजेक्ट में उनके कोड का उपयोग करना बंद कर दें। -* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. +* **व्यापार रहस्य:** विचार करें कि क्या परियोजना में ऐसा कुछ है जिसे कंपनी आम जनता के लिए उपलब्ध नहीं कराना चाहती है। यदि ऐसा है, तो जिस सामग्री को आप निजी रखना चाहते हैं, उसे निकालने के बाद आप अपने प्रोजेक्ट के बाकी हिस्से को ओपन सोर्स कर सकते हैं। -* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **पेटेंट:** क्या आपकी कंपनी किसी ऐसे पेटेंट के लिए आवेदन कर रही है जिसके ओपन सोर्सिंग से आपका प्रोजेक्ट [सार्वजनिक प्रकटीकरण](https://en.wikipedia.org/wiki/Public_disclosure) बनेगा? अफसोस की बात है, आपको प्रतीक्षा करने के लिए कहा जा सकता है (या हो सकता है कि कंपनी आवेदन की समझदारी पर पुनर्विचार करेगी)। यदि आप बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के कर्मचारियों से अपने प्रोजेक्ट में योगदान की उम्मीद कर रहे हैं, तो आपकी कानूनी टीम चाहती है कि आप योगदानकर्ताओं (जैसे अपाचे 2.0 या जीपीएलवी 3) से एक्सप्रेस पेटेंट अनुदान के साथ लाइसेंस का उपयोग करें, या एक अतिरिक्त योगदानकर्ता अनुबंध ( ऊपर देखें)। -* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. +* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#avoiding-name-conflicts)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है। -* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. +* **गोपनीयता:** क्या आपका प्रोजेक्ट उपयोगकर्ताओं पर डेटा एकत्र करता है? कंपनी सर्वर के लिए "फ़ोन होम"? आपकी कानूनी टीम कंपनी की नीतियों और बाहरी नियमों का अनुपालन करने में आपकी सहायता कर सकती है। -If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). +यदि आप अपनी कंपनी का पहला ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो उपरोक्त पूरा करने के लिए पर्याप्त से अधिक है (लेकिन चिंता न करें, अधिकांश परियोजनाओं को कोई बड़ी चिंता नहीं उठानी चाहिए)। -Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: +लंबी अवधि में, आपकी कानूनी टीम कंपनी को ओपन सोर्स में अपनी भागीदारी से अधिक लाभ प्राप्त करने और सुरक्षित रहने में मदद करने के लिए और अधिक प्रयास कर सकती है: -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). +* **कर्मचारी योगदान नीतियां:** एक कॉर्पोरेट नीति विकसित करने पर विचार करें जो निर्दिष्ट करती है कि आपके कर्मचारी ओपन सोर्स परियोजनाओं में कैसे योगदान करते हैं। एक स्पष्ट नीति आपके कर्मचारियों के बीच भ्रम को कम करेगी और उन्हें कंपनी के सर्वोत्तम हित में ओपन सोर्स परियोजनाओं में योगदान करने में मदद करेगी, चाहे वह उनकी नौकरी के हिस्से के रूप में हो या उनके खाली समय में। एक अच्छा उदाहरण रैकस्पेस की [मॉडल आईपी और ओपन सोर्स योगदान नीति](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) है। -* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. -* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. +* **क्या जारी करें:** [(लगभग) सब कुछ?](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/) सिरदर्द, उत्पाद में देरी और मुकदमों को रोक सकती है . -* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). -* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). +* **पेटेंट:** आपकी कंपनी प्रमुख ओपन सोर्स परियोजनाओं के सदस्यों के उपयोग की सुरक्षा के लिए एक साझा रक्षात्मक पेटेंट पूल [ओपन इन्वेंशन नेटवर्क](https://www.openinventionnetwork.com/) में शामिल होना चाह सकती है, या अन्वेषण कर सकती है अन्य [वैकल्पिक पेटेंट लाइसेंसिंग](https://www.eff.org/document/hacking-patent-system-2016). + +* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). diff --git a/_articles/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md index 51d312d3499..4282247015b 100644 --- a/_articles/hi/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md @@ -1,187 +1,187 @@ --- -lang: en +lang: hi untranslated: true -title: Maintaining Balance for Open Source Maintainers -description: Tips for self-care and avoiding burnout as a maintainer. +title: ओपन सोर्स अनुरक्षकों के लिए संतुलन बनाए रखना +description: एक अनुचर के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ। class: balance order: 0 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png --- -As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. +जैसे-जैसे एक ओपन सोर्स प्रोजेक्ट की लोकप्रियता बढ़ती है, आपको लंबे समय तक तरोताजा और उत्पादक बने रहने के लिए संतुलन बनाए रखने में मदद करने के लिए स्पष्ट सीमाएँ निर्धारित करना महत्वपूर्ण हो जाता है। -To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play. +संतुलन खोजने के लिए अनुरक्षकों के अनुभवों और उनकी रणनीतियों के बारे में जानकारी प्राप्त करने के लिए, हमने मेंटेनर समुदाय के 40 सदस्यों के साथ एक कार्यशाला चलाई, जिससे हमें अनुमति मिली खुले स्रोत में बर्नआउट के साथ उनके प्रत्यक्ष अनुभवों और उन प्रथाओं से सीखना जिन्होंने उन्हें अपने काम में संतुलन बनाए रखने में मदद की है। यहीं पर व्यक्तिगत पारिस्थितिकी की अवधारणा काम आती है। -So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with. +तो, व्यक्तिगत पारिस्थितिकी क्या है? जैसा रॉकवुड लीडरशिप इंस्टीट्यूट द्वारा वर्णित, इसमें "संतुलन बनाए रखना, गति बनाए रखना और शामिल है जीवन भर हमारी ऊर्जा को बनाए रखने की दक्षता।" इसने हमारी बातचीत को तैयार किया, जिससे अनुरक्षकों को समय के साथ विकसित होने वाले एक बड़े पारिस्थितिकी तंत्र के हिस्से के रूप में अपने कार्यों और योगदान को पहचानने में मदद मिली। बर्नआउट, क्रोनिक कार्यस्थल तनाव से उत्पन्न एक सिंड्रोम जैसा कि [डब्ल्यूएचओ द्वारा परिभाषित](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), अनुरक्षकों के बीच असामान्य नहीं है। इससे अक्सर प्रेरणा की हानि, ध्यान केंद्रित करने में असमर्थता और उन योगदानकर्ताओं और समुदाय के लिए सहानुभूति की कमी हो जाती है जिनके साथ आप काम करते हैं। -By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work. +व्यक्तिगत पारिस्थितिकी की अवधारणा को अपनाकर, अनुरक्षक सक्रिय रूप से बर्नआउट से बच सकते हैं, आत्म-देखभाल को प्राथमिकता दे सकते हैं और अपना सर्वश्रेष्ठ कार्य करने के लिए संतुलन की भावना बनाए रख सकते हैं। -## Tips for Self-Care and Avoiding Burnout as a Maintainer: +## एक अनुरक्षक के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ: -### Identify your motivations for working in open source +### ओपन सोर्स में काम करने के लिए अपनी प्रेरणाओं को पहचानें -Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus. +इस बात पर विचार करने के लिए समय निकालें कि ओपन सोर्स रखरखाव के कौन से हिस्से आपको ऊर्जावान बनाते हैं। अपनी प्रेरणाओं को समझने से आपको काम को इस तरह से प्राथमिकता देने में मदद मिल सकती है जिससे आप व्यस्त रहेंगे और नई चुनौतियों के लिए तैयार रहेंगे। चाहे वह उपयोगकर्ताओं से सकारात्मक प्रतिक्रिया हो, समुदाय के साथ सहयोग और मेलजोल की खुशी हो, या कोड में गोता लगाने की संतुष्टि हो, अपनी प्रेरणाओं को पहचानने से आपका ध्यान केंद्रित करने में मदद मिल सकती है। -### Reflect on what causes you to get out of balance and stressed out +### इस बात पर विचार करें कि किन कारणों से आप असंतुलित हो जाते हैं और तनावग्रस्त हो जाते हैं -It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: +यह समझना महत्वपूर्ण है कि किन कारणों से हम थक जाते हैं। यहां कुछ सामान्य विषय हैं जो हमने ओपन सोर्स अनुरक्षकों के बीच देखे हैं: -* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. +* **सकारात्मक प्रतिक्रिया का अभाव:** उपयोगकर्ताओं के पास शिकायत होने पर संपर्क करने की बहुत अधिक संभावना होती है। यदि सब कुछ बढ़िया चलता है, तो वे चुप रहना पसंद करते हैं। सकारात्मक प्रतिक्रिया के बिना मुद्दों की बढ़ती सूची को देखना हतोत्साहित करने वाला हो सकता है, जिसमें दिखाया गया हो कि आपके योगदान से कैसे फर्क पड़ रहा है। -* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations. +* **'नहीं' नहीं कहना:** किसी ओपन सोर्स प्रोजेक्ट पर अपनी अपेक्षा से अधिक ज़िम्मेदारियाँ लेना आसान हो सकता है। चाहे यह उपयोगकर्ताओं, योगदानकर्ताओं, या अन्य अनुरक्षकों से हो - हम हमेशा उनकी अपेक्षाओं पर खरे नहीं उतर सकते। -* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. +* **अकेले काम करना:** एक अनुरक्षक बनना अविश्वसनीय रूप से अकेला हो सकता है। भले ही आप अनुरक्षकों के एक समूह के साथ काम करते हैं, पिछले कुछ वर्षों में वितरित टीमों को व्यक्तिगत रूप से बुलाना कठिन रहा है। -* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. +* **पर्याप्त समय या संसाधन नहीं:** यह स्वयंसेवक अनुरक्षकों के लिए विशेष रूप से सच है, जिन्हें किसी परियोजना पर काम करने के लिए अपने खाली समय का त्याग करना पड़ता है। -* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community. +* **परस्पर विरोधी मांगें:** खुला स्रोत विभिन्न प्रेरणाओं वाले समूहों से भरा है, जिन्हें नेविगेट करना मुश्किल हो सकता है। यदि आपको ओपन सोर्स करने के लिए भुगतान किया जाता है, तो आपके नियोक्ता के हित कभी-कभी समुदाय के विपरीत हो सकते हैं। -### Watch out for signs of burnout +### बर्नआउट के लक्षणों से सावधान रहें -Can you keep up your pace for 10 weeks? 10 months? 10 years? +क्या आप 10 सप्ताह तक अपनी गति बनाए रख सकते हैं? दस महीने? 10 वर्ष? -There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress). +उपकरण जैसे [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) इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं। -### What would you need to continue sustaining yourself and your community? +### आपको अपना और अपने समुदाय का भरण-पोषण जारी रखने के लिए क्या चाहिए होगा? -This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard: +यह प्रत्येक अनुरक्षक के लिए अलग दिखेगा, और आपके जीवन के चरण और अन्य बाहरी कारकों के आधार पर बदल जाएगा। लेकिन यहां कुछ विषय हैं जो हमने सुने हैं: -* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. +* **समुदाय पर निर्भर रहें:** प्रतिनिधिमंडल और योगदानकर्ताओं को ढूंढने से काम का बोझ कम हो सकता है। किसी प्रोजेक्ट के लिए संपर्क के कई बिंदु होने से आपको बिना किसी चिंता के ब्रेक लेने में मदद मिल सकती है। [मेंटेनर कम्युनिटी](http://maintainers.github.com/) जैसे समूहों में अन्य अनुरक्षकों और व्यापक समुदाय से जुड़ें। साथियों के समर्थन और सीखने के लिए यह एक बेहतरीन संसाधन हो सकता है। - You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work. + आप उपयोगकर्ता समुदाय के साथ जुड़ने के तरीकों की भी तलाश कर सकते हैं, ताकि आप नियमित रूप से फीडबैक सुन सकें और अपने ओपन सोर्स कार्य के प्रभाव को समझ सकें। -* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/). +* **फंडिंग का अन्वेषण करें:** चाहे आप कुछ पिज़्ज़ा मनी की तलाश में हों, या पूर्णकालिक ओपन सोर्स पर जाने की कोशिश कर रहे हों, मदद के लिए कई संसाधन मौजूद हैं! पहले कदम के रूप में, दूसरों को आपके ओपन सोर्स कार्य को प्रायोजित करने की अनुमति देने के लिए [GitHub प्रायोजक](https://github.com/sponsors) को चालू करने पर विचार करें। यदि आप पूर्णकालिक बनने के बारे में सोच रहे हैं, तो [GitHub Accelerator](http://accelerator.github.com/) के अगले दौर के लिए आवेदन करें। -* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions. +* **टूल्स का उपयोग करें:** सांसारिक कार्यों को स्वचालित करने के लिए [GitHub Copilot](https://github.com/features/copilot/) और [GitHub Actions](https://github.com/features/actions) जैसे टूल खोजें कार्य करें और अधिक सार्थक योगदान के लिए अपना समय खाली करें। -* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [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) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term. +* **आराम करें और रिचार्ज करें:** ओपन सोर्स के बाहर अपने शौक और रुचियों के लिए समय निकालें। आराम करने और तरोताजा होने के लिए सप्ताहांत की छुट्टी लें-और अपना काम शुरू करें [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) आपकी उपलब्धता दर्शाने के लिए! एक अच्छी रात की नींद आपके प्रयासों को लंबे समय तक जारी रखने की आपकी क्षमता में बड़ा अंतर ला सकती है। - If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. + यदि आपको अपने प्रोजेक्ट के कुछ पहलू विशेष रूप से आनंददायक लगते हैं, तो अपने काम को इस प्रकार व्यवस्थित करने का प्रयास करें ताकि आप इसे पूरे दिन अनुभव कर सकें। -* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time. +* **सीमाएँ निर्धारित करें:** आप हर अनुरोध के लिए हाँ नहीं कह सकते। यह कहने जितना सरल हो सकता है, "मैं अभी उस तक नहीं पहुंच सकता और भविष्य में मेरी कोई योजना नहीं है," या README में यह सूचीबद्ध करना कि आप क्या करने में रुचि रखते हैं और क्या नहीं करने में। उदाहरण के लिए, आप कह सकते हैं: "मैं केवल उन पीआर का विलय करता हूं जिनमें स्पष्ट रूप से उन कारणों को सूचीबद्ध किया गया है कि उन्हें क्यों बनाया गया है," या, "मैं केवल वैकल्पिक गुरुवार को शाम 6 से 7 बजे तक मुद्दों की समीक्षा करता हूं।" यह दूसरों के लिए अपेक्षाएं निर्धारित करता है, और आपको कुछ देता है अपने समय पर योगदानकर्ताओं या उपयोगकर्ताओं की मांगों को कम करने में मदद करने के लिए अन्य समय पर इंगित करना। - Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about. + विषाक्त व्यवहार और नकारात्मक बातचीत को बंद करने में दृढ़ रहना सीखें। उन चीज़ों को ऊर्जा न देना ठीक है जिनकी आपको परवाह नहीं है। -Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run. +याद रखें, व्यक्तिगत पारिस्थितिकी एक सतत अभ्यास है जो आपकी ओपन सोर्स यात्रा में प्रगति के साथ विकसित होगी। आत्म-देखभाल को प्राथमिकता देकर और संतुलन की भावना बनाए रखकर, आप प्रभावी ढंग से और स्थायी रूप से ओपन सोर्स समुदाय में योगदान कर सकते हैं, जिससे आपकी भलाई और लंबे समय तक आपकी परियोजनाओं की सफलता दोनों सुनिश्चित हो सकती है। -## Additional Resources +## अतिरिक्त संसाधन -* [Maintainer Community](http://maintainers.github.com/) -* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon -* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg -* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge -* [SustainOSS](https://sustainoss.org/) -* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla -* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) -* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid -* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) -* Workshop agenda was remixed from [Mozilla's Movement Building from Home](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) series +* [मेंटेनर समुदाय](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) शृंखला -## Contributors +## योगदानकर्ताओं -Many thanks to all the maintainers who shared their experiences and tips with us for this guide! +इस गाइड के लिए अपने अनुभव और सुझाव हमारे साथ साझा करने वाले सभी अनुरक्षकों को बहुत धन्यवाद! -This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: +यह मार्गदर्शिका [@abbycabs](https://github.com/abbycabs) द्वारा इनके योगदान के साथ लिखी गई थी: [@agnostic-apollo](https://github.com/agnostic-apollo) [@AndreaGriffiths11](https://github.com/AndreaGriffiths11) diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md index 145dd18119b..5f4de85f9ba 100644 --- a/_articles/hi/metrics.md +++ b/_articles/hi/metrics.md @@ -1,7 +1,7 @@ --- -lang: en -title: Open Source Metrics -description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +lang: hi +title: ओपन सोर्स मेट्रिक्स +description: अपने ओपन सोर्स प्रोजेक्ट की सफलता को मापने और ट्रैक करके उसे फलने-फूलने में मदद करने के लिए सोच-समझकर निर्णय लें। class: metrics order: 9 image: /assets/images/cards/metrics.png @@ -10,119 +10,119 @@ related: - best-practices --- -## Why measure anything? +## किसी भी चीज़ को क्यों मापें? -Data, when used wisely, can help you make better decisions as an open source maintainer. +डेटा, जब बुद्धिमानी से उपयोग किया जाता है, तो आपको ओपन सोर्स अनुरक्षक के रूप में बेहतर निर्णय लेने में मदद मिल सकती है। -With more information, you can: +अधिक जानकारी के साथ, आप यह कर सकते हैं: -* Understand how users respond to a new feature -* Figure out where new users come from -* Identify, and decide whether to support, an outlier use case or functionality -* Quantify your project's popularity -* Understand how your project is used -* Raise money through sponsorships and grants +* समझें कि उपयोगकर्ता किसी नई सुविधा पर कैसे प्रतिक्रिया देते हैं +* पता लगाएं कि नए उपयोगकर्ता कहां से आते हैं +* बाहरी उपयोग के मामले या कार्यक्षमता को पहचानें और निर्णय लें कि इसका समर्थन करना है या नहीं +* अपने प्रोजेक्ट की लोकप्रियता का आकलन करें +* समझें कि आपके प्रोजेक्ट का उपयोग कैसे किया जाता है +* प्रायोजन और अनुदान के माध्यम से धन जुटाएं -For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work: +उदाहरण के लिए, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) ने पाया कि Google Analytics उन्हें काम को प्राथमिकता देने में मदद करता है: -> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. +> होमब्रू निःशुल्क प्रदान किया जाता है और इसे पूरी तरह से स्वयंसेवकों द्वारा अपने खाली समय में चलाया जाता है। परिणामस्वरूप, हमारे पास भविष्य की सुविधाओं को सर्वोत्तम तरीके से डिज़ाइन करने और वर्तमान कार्य को प्राथमिकता देने के तरीके पर निर्णय लेने के लिए होमब्रू उपयोगकर्ताओं का विस्तृत उपयोगकर्ता अध्ययन करने के लिए संसाधन नहीं हैं। अनाम समग्र उपयोगकर्ता विश्लेषण हमें लोग होमब्रू का उपयोग कैसे, कहां और कब करते हैं, इसके आधार पर सुधारों और सुविधाओं को प्राथमिकता देने की अनुमति देते हैं। -Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you. +लोकप्रियता ही सब कुछ नहीं है. हर कोई अलग-अलग कारणों से खुले स्रोत में आ जाता है। यदि एक ओपन सोर्स अनुरक्षक के रूप में आपका लक्ष्य अपना काम दिखाना है, अपने कोड के बारे में पारदर्शी होना है, या सिर्फ मनोरंजन करना है, तो मेट्रिक्स आपके लिए महत्वपूर्ण नहीं हो सकते हैं। -If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. +यदि आप अपने प्रोजेक्ट को गहराई से समझने में रुचि रखते हैं, तो अपने प्रोजेक्ट की गतिविधि का विश्लेषण करने के तरीकों के लिए आगे पढ़ें। -## Discovery +## खोज -Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_ +इससे पहले कि कोई भी आपके प्रोजेक्ट का उपयोग कर सके या उसमें योगदान कर सके, उन्हें यह जानना होगा कि यह मौजूद है। अपने आप से पूछें: _क्या लोगों को यह प्रोजेक्ट मिल रहा है?_ ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) -If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see: +यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://help.github.com/articles/about-repository-graphs/#traffic) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं: -* **Total page views:** Tells you how many times your project was viewed +* **कुल पृष्ठ दृश्य:** आपको बताता है कि आपका प्रोजेक्ट कितनी बार देखा गया -* **Total unique visitors:** Tells you how many people viewed your project +* **कुल अद्वितीय विज़िटर:** आपको बताता है कि कितने लोगों ने आपका प्रोजेक्ट देखा -* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working. +* **रेफ़रिंग साइटें:** आपको बताती हैं कि विज़िटर कहाँ से आए। यह मीट्रिक आपको यह पता लगाने में मदद कर सकता है कि आपको अपने दर्शकों तक कहां पहुंचना है और क्या आपके प्रचार प्रयास काम कर रहे हैं। -* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors. +* **लोकप्रिय सामग्री:** आपको बताती है कि विज़िटर आपके प्रोजेक्ट पर कहां जाते हैं, पृष्ठ दृश्य और अद्वितीय विज़िटर के आधार पर। -[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. +[गिटहब सितारे](https://help.github.com/articles/about-stars/) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं। -You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. +आप भी चाहते होंगे [tविशिष्ट स्थानों में रैक खोज योग्यता](https://opensource.com/business/16/6/pirate-metrics): उदाहरण के लिए, Google पेजरैंक, आपके प्रोजेक्ट की वेबसाइट से रेफरल ट्रैफ़िक, या अन्य ओपन सोर्स प्रोजेक्ट या वेबसाइट से रेफरल। -## Usage +## उपयोग -People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ +लोग आपके प्रोजेक्ट को इस जंगली और पागलपन वाली चीज़ पर ढूंढ रहे हैं जिसे हम इंटरनेट कहते हैं। आदर्श रूप से, जब वे आपका प्रोजेक्ट देखेंगे, तो वे कुछ करने के लिए मजबूर महसूस करेंगे। दूसरा प्रश्न जो आप पूछना चाहेंगे वह है: _क्या लोग इस परियोजना का उपयोग कर रहे हैं?_ -If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads. +यदि आप अपने प्रोजेक्ट को वितरित करने के लिए npm या RubyGems.org जैसे पैकेज मैनेजर का उपयोग करते हैं, तो आप अपने प्रोजेक्ट के डाउनलोड को ट्रैक करने में सक्षम हो सकते हैं। -Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. +प्रत्येक पैकेज प्रबंधक "डाउनलोड" की थोड़ी अलग परिभाषा का उपयोग कर सकता है, और डाउनलोड आवश्यक रूप से इंस्टॉल या उपयोग से संबंधित नहीं है, लेकिन यह तुलना के लिए कुछ आधार रेखा प्रदान करता है। कई लोकप्रिय पैकेज प्रबंधकों में उपयोग के आंकड़ों को ट्रैक करने के लिए [Libraries.io](https://libraries.io/) का उपयोग करने का प्रयास करें। -If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. +यदि आपका प्रोजेक्ट GitHub पर है, तो "ट्रैफ़िक" पृष्ठ पर फिर से नेविगेट करें। आप यह देखने के लिए [क्लोन ग्राफ](https://github.com/blog/1873-clone-graphs) का उपयोग कर सकते हैं कि आपके प्रोजेक्ट को किसी दिए गए दिन में कितनी बार क्लोन किया गया है, कुल क्लोन और अद्वितीय क्लोनर्स द्वारा विभाजित किया गया है। -![Clone graph](/assets/images/metrics/clone_graph.png) +![क्लोन ग्राफ़](/assets/images/metrics/clone_graph.png) -If usage is low compared to the number of people discovering your project, there are two issues to consider. Either: +यदि आपके प्रोजेक्ट को खोजने वाले लोगों की संख्या की तुलना में उपयोग कम है, तो विचार करने के लिए दो मुद्दे हैं। दोनों में से एक: -* Your project isn't successfully converting your audience, or -* You're attracting the wrong audience +* आपका प्रोजेक्ट आपके दर्शकों को सफलतापूर्वक परिवर्तित नहीं कर रहा है, या +* आप गलत दर्शकों को आकर्षित कर रहे हैं -For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience. +उदाहरण के लिए, यदि आपका प्रोजेक्ट हैकर न्यूज़ के पहले पन्ने पर आता है, तो आपको संभवतः खोज (ट्रैफ़िक) में वृद्धि दिखाई देगी, लेकिन रूपांतरण दर कम होगी, क्योंकि आप हैकर न्यूज़ पर सभी तक पहुंच रहे हैं। हालाँकि, यदि आपका रूबी प्रोजेक्ट रूबी सम्मेलन में प्रदर्शित किया गया है, तो आपको लक्षित दर्शकों से उच्च रूपांतरण दर देखने की अधिक संभावना है। -Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing. +यह पता लगाने का प्रयास करें कि आपके दर्शक कहां से आ रहे हैं और अपने प्रोजेक्ट पेज पर दूसरों से फीडबैक मांगें ताकि यह पता चल सके कि आप इन दोनों में से किस समस्या का सामना कर रहे हैं। -Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business? +एक बार जब आप जान जाते हैं कि लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं, तो आप यह पता लगाने की कोशिश करना चाहेंगे कि वे इसके साथ क्या कर रहे हैं। क्या वे आपके कोड को फोर्क करके और सुविधाएँ जोड़कर इस पर निर्माण कर रहे हैं? क्या वे इसका उपयोग विज्ञान या व्यवसाय के लिए कर रहे हैं? -## Retention +## अवधारण -People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ +लोगों को आपका प्रोजेक्ट मिल रहा है और वे इसका उपयोग कर रहे हैं। अगला प्रश्न जो आप स्वयं से पूछना चाहेंगे वह है: _क्या लोग इस परियोजना में योगदान दे रहे हैं?_ -It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). +योगदानकर्ताओं के बारे में सोचना शुरू करना कभी भी जल्दी नहीं है। अन्य लोगों के हस्तक्षेप के बिना, आप अपने आप को एक अस्वस्थ स्थिति में डालने का जोखिम उठाते हैं जहां आपका प्रोजेक्ट लोकप्रिय है (कई लोग इसका उपयोग करते हैं) लेकिन समर्थित नहीं है (मांग को पूरा करने के लिए रखरखाव के लिए पर्याप्त समय नहीं है)। -Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. +प्रतिधारण के लिए [नए योगदानकर्ताओं की आमद](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), की भी आवश्यकता होती है, चूँकि पहले सक्रिय योगदानकर्ता अंततः अन्य चीज़ों की ओर बढ़ेंगे। -Examples of community metrics that you may want to regularly track include: +सामुदायिक मेट्रिक्स के उदाहरण जिन्हें आप नियमित रूप से ट्रैक करना चाहते हैं उनमें शामिल हैं: -* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. +* **कुल योगदानकर्ता संख्या और प्रति योगदानकर्ता प्रतिबद्धताओं की संख्या:** आपको बताता है कि आपके पास कितने योगदानकर्ता हैं, और कौन कम या ज्यादा सक्रिय है। GitHub पर, आप इसे "अंतर्दृष्टि" -> "योगदानकर्ता" के अंतर्गत देख सकते हैं। अभी, यह ग्राफ़ केवल उन योगदानकर्ताओं की गणना करता है जिन्होंने रिपॉजिटरी की डिफ़ॉल्ट शाखा के लिए प्रतिबद्ध किया है। -![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) +![योगदानकर्ता ग्राफ](/assets/images/metrics/repo_contributors_specific_graph.png) -* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. +* **पहली बार, आकस्मिक और बार-बार योगदान देने वाले:** आपको यह ट्रैक करने में मदद करता है कि क्या आपको नए योगदानकर्ता मिल रहे हैं, और क्या वे वापस आते हैं। (आकस्मिक योगदानकर्ता कम संख्या में कमिट वाले योगदानकर्ता होते हैं। चाहे वह एक कमिट हो, पांच से कम कमिट हो, या कुछ और यह आप पर निर्भर है।) नए योगदानकर्ताओं के बिना, आपके प्रोजेक्ट का समुदाय स्थिर हो सकता है। -* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. +* **खुले मुद्दों और खुले पुल अनुरोधों की संख्या:** यदि ये संख्या बहुत अधिक हो जाती है, तो आपको समस्या परीक्षण और कोड समीक्षा में मदद की आवश्यकता हो सकती है। -* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. +* **_खुले हुए_ मुद्दों और _खुले_पुल अनुरोधों की संख्या:** खुले हुए मुद्दों का मतलब है कि किसी को आपके प्रोजेक्ट की इतनी परवाह है कि वह किसी मुद्दे को खोल सके। यदि वह संख्या समय के साथ बढ़ती है, तो यह दर्शाता है कि लोग आपके प्रोजेक्ट में रुचि रखते हैं। -* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. +* **योगदान के प्रकार:** उदाहरण के लिए, कमिट करना, टाइपो या बग को ठीक करना, या किसी मुद्दे पर टिप्पणी करना। -## Maintainer activity +## अनुरक्षक गतिविधि -Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_ +अंत में, आप यह सुनिश्चित करके लूप को बंद करना चाहेंगे कि आपके प्रोजेक्ट के अनुरक्षक प्राप्त योगदान की मात्रा को संभालने में सक्षम हैं। आखिरी सवाल जो आप खुद से पूछना चाहेंगे वह है: _क्या मैं (या हम) अपने समुदाय को जवाब दे रहे हैं?_ -Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave. +अनुत्तरदायी अनुरक्षक खुले स्रोत परियोजनाओं के लिए एक बाधा बन जाते हैं। यदि कोई योगदान जमा करता है लेकिन रखरखावकर्ता से कभी जवाब नहीं मिलता है, तो वे निराश महसूस कर सकते हैं और छोड़ सकते हैं। -[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions. +[मोज़िला से अनुसंधान](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) सुझाव देता है कि बार-बार योगदान को प्रोत्साहित करने में अनुरक्षक प्रतिक्रिया एक महत्वपूर्ण कारक है। -Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_ +विचार करना [यह ट्रैक करना कि आपको (या किसी अन्य अनुरक्षक को) योगदान का जवाब देने में कितना समय लगता है](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), चाहे कोई समस्या हो या पुल अनुरोध। प्रतिक्रिया देने के लिए कार्रवाई की आवश्यकता नहीं है. यह कहने जितना सरल हो सकता है: _"आपके सबमिशन के लिए धन्यवाद! मैं अगले सप्ताह के भीतर इसकी समीक्षा करूंगा।"_ -You could also measure the time it takes to move between stages in the contribution process, such as: +आप योगदान प्रक्रिया के चरणों के बीच लगने वाले समय को भी माप सकते हैं, जैसे: -* Average time an issue remains open -* Whether issues get closed by PRs -* Whether stale issues get closed -* Average time to merge a pull request +* किसी अंक के खुले रहने का औसत समय +* क्या मुद्दे पीआर द्वारा बंद कर दिए जाते हैं +* क्या बासी मुद्दे बंद हो जाते हैं +* पुल अनुरोध को मर्ज करने का औसत समय -## Use 📊 to learn about people +## लोगों के बारे में जानने के लिए 📊 का प्रयोग करें -Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive. +मेट्रिक्स को समझने से आपको एक सक्रिय, बढ़ता हुआ ओपन सोर्स प्रोजेक्ट बनाने में मदद मिलेगी। भले ही आप डैशबोर्ड पर प्रत्येक मीट्रिक को ट्रैक नहीं करते हैं, फिर भी अपना ध्यान उस प्रकार के व्यवहार पर केंद्रित करने के लिए उपरोक्त ढांचे का उपयोग करें जो आपके प्रोजेक्ट को आगे बढ़ाने में मदद करेगा। -[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health. +[CHAOSS](https://chaoss.community/) एक स्वागतयोग्य, खुला स्रोत समुदाय है जो सामुदायिक स्वास्थ्य के लिए एनालिटिक्स, मेट्रिक्स और सॉफ्टवेयर पर केंद्रित है। diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml index 84435d4d5fb..076cf4e9203 100644 --- a/_data/locales/hi.yml +++ b/_data/locales/hi.yml @@ -1,5 +1,5 @@ hi: - locale_name: हिंदी + locale_name: Hindi nav: about: बारे में contribute: योगदान करें From 6773bdf935c8ecbb3073b9a72522c231d02132b7 Mon Sep 17 00:00:00 2001 From: James Titus Date: Fri, 1 Sep 2023 11:17:07 +0530 Subject: [PATCH 05/25] article update --hindi --- _articles/hi/starting-a-project.md | 269 ++++++++++++++--------------- 1 file changed, 134 insertions(+), 135 deletions(-) diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md index 15b01773ef7..671117cc326 100644 --- a/_articles/hi/starting-a-project.md +++ b/_articles/hi/starting-a-project.md @@ -1,7 +1,7 @@ --- -lang: en -title: Starting an Open Source Project -description: Learn more about the world of open source and get ready to launch your own project. +lang: hi +title: एक ओपन सोर्स प्रोजेक्ट शुरू करना +description: ओपन सोर्स की दुनिया के बारे में और जानें और अपना खुद का प्रोजेक्ट लॉन्च करने के लिए तैयार हो जाएं। class: beginners order: 2 image: /assets/images/cards/beginner.png @@ -10,280 +10,279 @@ related: - building --- -## The "what" and "why" of open source +## खुले स्रोत का "क्या" और "क्यों"। -So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it. +तो क्या आप ओपन सोर्स के साथ शुरुआत करने के बारे में सोच रहे हैं? बधाई हो! दुनिया आपके योगदान की सराहना करती है. आइए बात करें कि ओपन सोर्स क्या है और लोग ऐसा क्यों करते हैं। -### What does "open source" mean? +### "ओपन सोर्स" का क्या मतलब है? -When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). +जब कोई प्रोजेक्ट ओपन सोर्स होता है, तो इसका मतलब है कि **कोई भी किसी भी उद्देश्य के लिए आपके प्रोजेक्ट का उपयोग, अध्ययन, संशोधन और वितरण करने के लिए स्वतंत्र है।** ये अनुमतियाँ [एक ओपन सोर्स लाइसेंस](https://opensource.org/licenses) के माध्यम से लागू की जाती हैं। -Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions. +खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है। -_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge). +_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#does-open-source-mean-free-of-charge)। -### Why do people open source their work? +### लोग अपना काम ओपन सोर्स क्यों करते हैं? -[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include: +[इसके कई कारण हैं](https://ben.balter.com/2015/11/23/why-open-source/) कोई व्यक्ति या संगठन किसी प्रोजेक्ट को ओपन सोर्स क्यों करना चाहेगा। कुछ उदाहरणों में शामिल हैं: -* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. +* **सहयोग:** ओपन सोर्स प्रोजेक्ट दुनिया में किसी से भी बदलाव स्वीकार कर सकते हैं। [व्यायाम](https://github.com/exercism/), उदाहरण के लिए, 350 से अधिक योगदानकर्ताओं वाला एक प्रोग्रामिंग अभ्यास मंच है। -* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). +* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [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 inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). +* **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). -Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. +ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें। -### Does open source mean "free of charge"? +### क्या ओपन सोर्स का मतलब "निःशुल्क" है? +ओपन सोर्स का सबसे बड़ा आकर्षण यह है कि इसमें पैसा खर्च नहीं होता है। हालाँकि, "निःशुल्क", खुले स्रोत के समग्र मूल्य का एक उपोत्पाद है। -One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. +क्योंकि [एक ओपन सोर्स लाइसेंस के लिए आवश्यक है](https://opensource.org/osd-annotated) कि कोई भी आपके प्रोजेक्ट को लगभग किसी भी उद्देश्य के लिए उपयोग, संशोधित और साझा कर सकता है, प्रोजेक्ट स्वयं निःशुल्क होते हैं। यदि प्रोजेक्ट के उपयोग में पैसे खर्च होते हैं, तो कोई भी कानूनी तौर पर इसकी प्रतिलिपि बना सकता है और इसके बजाय मुफ़्त संस्करण का उपयोग कर सकता है। -Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. +परिणामस्वरूप, अधिकांश ओपन सोर्स प्रोजेक्ट मुफ़्त हैं, लेकिन "निःशुल्क" ओपन सोर्स परिभाषा का हिस्सा नहीं है। ओपन सोर्स की आधिकारिक परिभाषा का अनुपालन करते हुए, दोहरे लाइसेंसिंग या सीमित सुविधाओं के माध्यम से अप्रत्यक्ष रूप से ओपन सोर्स परियोजनाओं के लिए शुल्क लेने के कई तरीके हैं। -As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. +## क्या मुझे अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना चाहिए? -## Should I launch my own open source project? +संक्षिप्त उत्तर हां है, क्योंकि परिणाम चाहे जो भी हो, अपना खुद का प्रोजेक्ट लॉन्च करना यह सीखने का एक शानदार तरीका है कि ओपन सोर्स कैसे काम करता है। -The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works. +यदि आपने पहले कभी कोई प्रोजेक्ट ओपन सोर्स नहीं किया है, तो आप इस बात से घबरा सकते हैं कि लोग क्या कहेंगे, या कोई नोटिस करेगा या नहीं। यदि यह आपके जैसा लगता है, तो आप अकेले नहीं हैं! -If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone! +ओपन सोर्स कार्य किसी भी अन्य रचनात्मक गतिविधि की तरह है, चाहे वह लेखन हो या पेंटिंग। अपने काम को दुनिया के साथ साझा करना डरावना लग सकता है, लेकिन बेहतर होने का एकमात्र तरीका अभ्यास करना है - भले ही आपके पास दर्शक न हों। -Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience. +यदि आप अभी तक आश्वस्त नहीं हैं, तो एक क्षण रुककर सोचें कि आपके लक्ष्य क्या हो सकते हैं। -If you're not yet convinced, take a moment to think about what your goals might be. +### अपने लक्ष्य निर्धारित करना -### Setting your goals +लक्ष्य आपको यह पता लगाने में मदद कर सकते हैं कि किस पर काम करना है, किस चीज़ को ना कहना है और आपको कहाँ दूसरों से मदद की ज़रूरत है। अपने आप से यह पूछकर शुरुआत करें, _मैं इस प्रोजेक्ट का ओपन सोर्सिंग क्यों कर रहा हूँ?_ -Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ +इस प्रश्न का कोई भी सही उत्तर नहीं है। आपके पास एक ही प्रोजेक्ट के लिए कई लक्ष्य हो सकते हैं, या अलग-अलग लक्ष्यों वाली अलग-अलग परियोजनाएँ हो सकती हैं। -There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. - -If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. +यदि आपका एकमात्र लक्ष्य अपना काम दिखाना है, तो हो सकता है कि आप योगदान भी न चाहें, और अपने README में ऐसा कहें भी नहीं। दूसरी ओर, यदि आप योगदानकर्ता चाहते हैं, तो आप स्पष्ट दस्तावेज़ीकरण और नए लोगों का स्वागत महसूस कराने में समय लगाएंगे। -As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. +जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, आपके समुदाय को आपसे कोड के अलावा और भी बहुत कुछ की आवश्यकता हो सकती है। मुद्दों पर प्रतिक्रिया देना, कोड की समीक्षा करना और अपने प्रोजेक्ट का प्रचार-प्रसार करना एक ओपन सोर्स प्रोजेक्ट में सभी महत्वपूर्ण कार्य हैं। -While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. +जबकि आप गैर-कोडिंग कार्यों पर कितना समय बिताएंगे, यह आपके प्रोजेक्ट के आकार और दायरे पर निर्भर करेगा, आपको उन्हें स्वयं संबोधित करने या आपकी सहायता के लिए किसी को ढूंढने के लिए एक अनुरक्षक के रूप में तैयार रहना चाहिए। -**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. +**यदि आप किसी प्रोजेक्ट की ओपन सोर्सिंग करने वाली कंपनी का हिस्सा हैं,**सुनिश्चित करें कि आपके प्रोजेक्ट के पास आंतरिक संसाधन हैं जो उसे आगे बढ़ाने के लिए आवश्यक हैं। आप यह पहचानना चाहेंगे कि लॉन्च के बाद प्रोजेक्ट को बनाए रखने के लिए कौन ज़िम्मेदार है, और आप उन कार्यों को अपने समुदाय के साथ कैसे साझा करेंगे। -If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early. +यदि आपको परियोजना के प्रचार, संचालन और रखरखाव के लिए समर्पित बजट या स्टाफिंग की आवश्यकता है, तो बातचीत जल्दी शुरू करें। -### Contributing to other projects +### अन्य परियोजनाओं में योगदान देना -If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. +यदि आपका लक्ष्य यह सीखना है कि दूसरों के साथ कैसे सहयोग करें या यह समझें कि ओपन सोर्स कैसे काम करता है, तो किसी मौजूदा प्रोजेक्ट में योगदान देने पर विचार करें। उस प्रोजेक्ट से शुरुआत करें जिसे आप पहले से ही उपयोग करते हैं और पसंद करते हैं। किसी प्रोजेक्ट में योगदान देना टाइप की त्रुटियों को ठीक करने या दस्तावेज़ीकरण को अपडेट करने जितना आसान हो सकता है। -If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). +यदि आप निश्चित नहीं हैं कि योगदानकर्ता के रूप में शुरुआत कैसे करें, तो हमारी जाँच करें [ओपन सोर्स गाइड में योगदान कैसे करें](../how-to-contribute/). -## Launching your own open source project +## अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना -There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. +अपने काम का स्रोत खोलने का कोई सही समय नहीं है। आप किसी विचार का स्रोत खोल सकते हैं, कोई कार्य प्रगति पर है, या वर्षों तक बंद स्रोत रहने के बाद। -Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. +आम तौर पर कहें तो, आपको अपने प्रोजेक्ट को तब ओपन सोर्स करना चाहिए जब आप दूसरों को अपने काम को देखने और उस पर फीडबैक देने में सहज महसूस करें। -No matter which stage you decide to open source your project, every project should include the following documentation: +इससे कोई फर्क नहीं पड़ता कि आप अपने प्रोजेक्ट को किस चरण में खोलने का निर्णय लेते हैं, प्रत्येक प्रोजेक्ट में निम्नलिखित दस्तावेज़ शामिल होने चाहिए: * [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/) -As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. +एक अनुरक्षक के रूप में, ये घटक आपको अपेक्षाओं को संप्रेषित करने, योगदान प्रबंधित करने और सभी के कानूनी अधिकारों (आपके अपने अधिकारों सहित) की रक्षा करने में मदद करेंगे। वे आपके सकारात्मक अनुभव प्राप्त करने की संभावनाओं को उल्लेखनीय रूप से बढ़ा देते हैं। -If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. +यदि आपका प्रोजेक्ट GitHub पर है, तो इन फ़ाइलों को अनुशंसित फ़ाइल नामों के साथ अपनी रूट निर्देशिका में डालने से GitHub को उन्हें पहचानने और स्वचालित रूप से आपके पाठकों के सामने लाने में मदद मिलेगी। -### Choosing a license +### लाइसेंस चुनना -An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.** +एक ओपन सोर्स लाइसेंस यह गारंटी देता है कि अन्य लोग बिना किसी प्रभाव के आपके प्रोजेक्ट का उपयोग, प्रतिलिपि, संशोधन और योगदान कर सकते हैं। यह आपको जटिल कानूनी स्थितियों से भी बचाता है। **ओपन सोर्स प्रोजेक्ट लॉन्च करते समय आपको एक लाइसेंस शामिल करना होगा।** -Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work. +क़ानूनी काम कोई मज़ेदार नहीं है. अच्छी खबर यह है कि आप मौजूदा लाइसेंस को कॉपी करके अपने रिपॉजिटरी में पेस्ट कर सकते हैं। आपकी मेहनत की रक्षा करने में केवल एक मिनट लगेगा। -[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/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from. +[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). -When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source. +जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ओपन सोर्स लाइसेंस शामिल करने से आपका GitHub प्रोजेक्ट ओपन सोर्स बन जाएगा। -![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) +![एक लाइसेंस चुनें](/assets/images/starting-a-project/repository-license-picker.png) -If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/). +यदि आपके पास ओपन सोर्स प्रोजेक्ट के प्रबंधन के कानूनी पहलुओं के बारे में अन्य प्रश्न या चिंताएं हैं, [हमने आपका ध्यान रखा है](../legal/). -### Writing a README +### एक README लिखना -READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it. +READMEs आपके प्रोजेक्ट का उपयोग कैसे करें यह समझाने के अलावा और भी बहुत कुछ करते हैं। वे यह भी बताते हैं कि आपका प्रोजेक्ट क्यों मायने रखता है, और आपके उपयोगकर्ता इसके साथ क्या कर सकते हैं। -In your README, try to answer the following questions: +अपने README में निम्नलिखित प्रश्नों के उत्तर देने का प्रयास करें: -* What does this project do? -* Why is this project useful? -* How do I get started? -* Where can I get more help, if I need it? +* यह प्रोजेक्ट क्या करता है? +* यह प्रोजेक्ट उपयोगी क्यों है? +* मैं कैसे शुरू करूँ? +* यदि मुझे आवश्यकता हो तो मुझे और सहायता कहां से मिल सकती है? -You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. +आप अपने README का उपयोग अन्य प्रश्नों के उत्तर देने के लिए कर सकते हैं, जैसे कि आप योगदान कैसे संभालते हैं, परियोजना के लक्ष्य क्या हैं, और लाइसेंस और एट्रिब्यूशन के बारे में जानकारी। यदि आप योगदान स्वीकार नहीं करना चाहते हैं, या आपका प्रोजेक्ट अभी तक उत्पादन के लिए तैयार नहीं है, तो इस जानकारी को लिख लें। -Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. +कभी-कभी, लोग README लिखने से बचते हैं क्योंकि उन्हें लगता है कि परियोजना अधूरी है, या वे योगदान नहीं चाहते हैं। इसे लिखने के ये सभी बहुत अच्छे कारण हैं। -For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. +अधिक प्रेरणा के लिए, @dguo's का ["एक README बनाएं" मार्गदर्शिका](https://www.makeareadme.com/) उपयोग करने का प्रयास करें या @PurpleBooth's [README टेम्पलेट](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) संपूर्ण README लिखने के लिए। -When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. +जब आप रूट डायरेक्टरी में एक README फ़ाइल शामिल करते हैं, तो GitHub स्वचालित रूप से इसे रिपॉजिटरी होमपेज पर प्रदर्शित करेगा। -### Writing your contributing guidelines +### अपने योगदान संबंधी दिशानिर्देश लिखना -A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on: +एक योगदान फ़ाइल आपके दर्शकों को बताती है कि आपके प्रोजेक्ट में कैसे भाग लेना है। उदाहरण के लिए, आप निम्न पर जानकारी शामिल कर सकते हैं: -* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) -* How to suggest a new feature -* How to set up your environment and run tests +* बग रिपोर्ट कैसे दर्ज करें ([इश्यू और पुल रिक्वेस्ट टेम्प्लेट्स का उपयोग](https://github.com/blog/2111-issue-and-pull-request-templates)) करने का प्रयास करें। +* नई सुविधा का सुझाव कैसे दें +* अपना वातावरण कैसे स्थापित करें और परीक्षण कैसे चलाएं -In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as: +तकनीकी विवरण के अलावा, योगदान फ़ाइल योगदान के लिए आपकी अपेक्षाओं को संप्रेषित करने का एक अवसर है, जैसे: -* The types of contributions you're looking for -* Your roadmap or vision for the project -* How contributors should (or should not) get in touch with you +* आप जिस प्रकार के योगदान की तलाश कर रहे हैं +* परियोजना के लिए आपका रोडमैप या विज़न +* योगदानकर्ताओं को आपसे कैसे संपर्क करना चाहिए (या नहीं करना चाहिए)। -Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. +गर्मजोशीपूर्ण, मैत्रीपूर्ण लहजे का उपयोग करना और योगदान के लिए विशिष्ट सुझाव देना (जैसे दस्तावेज़ लिखना, या वेबसाइट बनाना) नवागंतुकों को भाग लेने के लिए स्वागत और उत्साहित महसूस कराने में काफी मदद कर सकता है। -For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: +उदाहरण के लिए, [सक्रिय व्यवस्थापक](https://github.com/activeadmin/activeadmin/) प्रारंभ होता है [इसकी योगदान मार्गदर्शिका](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) के साथ: -> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. +>सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं। -In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution. +आपके प्रोजेक्ट के शुरुआती चरणों में, आपकी CONTRIBUTING फ़ाइल सरल हो सकती है। योगदान देने के लिए आपको हमेशा यह समझाना चाहिए कि बग या फ़ाइल समस्याओं की रिपोर्ट कैसे करें, और कोई तकनीकी आवश्यकताएं (जैसे परीक्षण) कैसे करें। -Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. +समय के साथ, आप अपनी योगदान फ़ाइल में अन्य अक्सर पूछे जाने वाले प्रश्न जोड़ सकते हैं। इस जानकारी को लिखने का मतलब है कि कम लोग आपसे वही प्रश्न बार-बार पूछेंगे। -For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/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/). -Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. +अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा। -![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) +![योगदान दिशानिर्देश](/assets/images/starting-a-project/Contributing-guidelines.jpg) -### Establishing a code of conduct +### आचार संहिता की स्थापना -Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. +अंत में, एक आचार संहिता आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार के लिए बुनियादी नियम निर्धारित करने में मदद करती है। यह विशेष रूप से मूल्यवान है यदि आप किसी समुदाय या कंपनी के लिए एक ओपन सोर्स प्रोजेक्ट लॉन्च कर रहे हैं। आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार की सुविधा प्रदान करने का अधिकार देती है, जो एक अनुरक्षक के रूप में आपके तनाव को कम करेगा। -For more information, check out our [Code of Conduct guide](../code-of-conduct/). +अधिक जानकारी के लिए, हमारी जाँच करें [आचार संहिता मार्गदर्शिका](../code-of-conduct/). -In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. +यह बताने के अलावा कि आप प्रतिभागियों से कैसे व्यवहार करने की अपेक्षा करते हैं, आचार संहिता यह भी बताती है कि ये अपेक्षाएं किस पर लागू होती हैं, कब लागू होती हैं और उल्लंघन होने पर क्या करना चाहिए। -Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. +ओपन सोर्स लाइसेंस की तरह, आचार संहिता के लिए भी उभरते मानक हैं, इसलिए आपको अपना खुद का लिखने की ज़रूरत नहीं है। [योगदानकर्ता वाचा](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग [40,000 से अधिक ओपन सोर्स प्रोजेक्ट्स](https://www.contributor-covenant.org/adopters) द्वारा किया जाता है। कुबेरनेट्स, रेल्स और स्विफ्ट सहित। इससे कोई फर्क नहीं पड़ता कि आप किस पाठ का उपयोग करते हैं, आपको आवश्यकता पड़ने पर अपनी आचार संहिता लागू करने के लिए तैयार रहना चाहिए। -Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. +टेक्स्ट को सीधे अपने रिपॉजिटरी में एक Code_OF_CONDUCT फ़ाइल में पेस्ट करें। फ़ाइल को अपने प्रोजेक्ट की रूट डायरेक्टरी में रखें ताकि इसे ढूंढना आसान हो, और इसे अपने README से लिंक करें। -## Naming and branding your project +## अपने प्रोजेक्ट का नामकरण और ब्रांडिंग करना -Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message. +ब्रांडिंग एक आकर्षक लोगो या आकर्षक प्रोजेक्ट नाम से कहीं अधिक है। यह इस बारे में है कि आप अपने प्रोजेक्ट के बारे में कैसे बात करते हैं, और आप अपना संदेश किस तक पहुंचाते हैं। -### Choosing the right name +### सही नाम चुनना -Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: +ऐसा नाम चुनें जो याद रखने में आसान हो और, आदर्श रूप से, प्रोजेक्ट क्या करता है, इसका कुछ अंदाज़ा देता हो। उदाहरण के लिए: -* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting -* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server +* [Sentry](https://github.com/getsentry/sentry) क्रैश रिपोर्टिंग के लिए ऐप्स पर नज़र रखता है +* [Thin](https://github.com/macournoyer/thin) एक तेज़ और सरल रूबी वेब सर्वर है -If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). +यदि आप किसी मौजूदा प्रोजेक्ट पर निर्माण कर रहे हैं, तो उपसर्ग के रूप में उनके नाम का उपयोग करने से यह स्पष्ट करने में मदद मिल सकती है कि आपका प्रोजेक्ट क्या करता है (उदाहरण के लिए, [node-fetch](https://github.com/bitinn/node-fetch) window.fetch` को Node.js पर लाता है)। -Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! +स्पष्टता को सर्वोपरि मानें। चुटकुले मजेदार हैं, लेकिन याद रखें कि कुछ चुटकुले अन्य संस्कृतियों या आपसे अलग अनुभव वाले लोगों पर लागू नहीं हो सकते हैं। आपके कुछ संभावित उपयोगकर्ता कंपनी के कर्मचारी हो सकते हैं: जब उन्हें कार्यस्थल पर आपके प्रोजेक्ट के बारे में बताना हो तो आप उन्हें असहज नहीं करना चाहेंगे! -### Avoiding name conflicts +### नाम के झगड़ों से बचना -[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. +[समान नाम वाले ओपन सोर्स प्रोजेक्ट की जांच करें](http://ivantomic.com/projects/ospnc/), खासकर यदि आप एक ही भाषा या पारिस्थितिकी तंत्र साझा करते हैं। यदि आपका नाम किसी लोकप्रिय मौजूदा प्रोजेक्ट से मेल खाता है, तो आप अपने दर्शकों को भ्रमित कर सकते हैं। -If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. +यदि आप अपने प्रोजेक्ट का प्रतिनिधित्व करने के लिए एक वेबसाइट, ट्विटर हैंडल या अन्य संपत्तियां चाहते हैं, तो सुनिश्चित करें कि आपको अपने इच्छित नाम मिल सकें। आदर्श रूप से, मन की शांति के लिए [अभी उन नामों को आरक्षित करें](https://instantdomainsearch.com/), भले ही आप अभी उनका उपयोग करने का इरादा नहीं रखते हों। -Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. +सुनिश्चित करें कि आपके प्रोजेक्ट का नाम किसी भी ट्रेडमार्क का उल्लंघन नहीं करता है। कोई कंपनी बाद में आपसे अपना प्रोजेक्ट वापस लेने के लिए कह सकती है, या आपके खिलाफ कानूनी कार्रवाई भी कर सकती है। यह जोखिम के लायक ही नहीं है। -You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). +आप ट्रेडमार्क विवादों के लिए [WIPO ग्लोबल ब्रांड डेटाबेस](http://www.wipo.int/branddb/en/) की जांच कर सकते हैं। यदि आप किसी कंपनी में हैं, तो यह उन चीजों में से एक है जिसमें आपकी [कानूनी टीम आपकी मदद कर सकती है।](../legal/) -Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? +अंत में, अपने प्रोजेक्ट के नाम के लिए त्वरित Google खोज करें। क्या लोग आपका प्रोजेक्ट आसानी से ढूंढ पाएंगे? क्या खोज परिणामों में कुछ और दिखाई देता है जो आप नहीं चाहेंगे कि वे देखें? -### How you write (and code) affects your brand, too! +### आप कैसे लिखते हैं (और कोड) आपके ब्रांड को भी प्रभावित करता है! -Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. +अपने प्रोजेक्ट के पूरे जीवनकाल में, आप बहुत सारा लेखन करेंगे: रीडमी, ट्यूटोरियल, सामुदायिक दस्तावेज़, मुद्दों पर प्रतिक्रिया देना, शायद न्यूज़लेटर और मेलिंग सूचियाँ भी। -Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. +चाहे वह आधिकारिक दस्तावेज हो या कोई आकस्मिक ईमेल, आपकी लेखन शैली आपके प्रोजेक्ट के ब्रांड का हिस्सा है। इस बात पर विचार करें कि आप अपने दर्शकों के सामने कैसे आ सकते हैं और क्या आप यही लहजा बताना चाहते हैं। -Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. +गर्मजोशीपूर्ण, समावेशी भाषा (जैसे कि "उन्हें", यहां तक ​​कि जब एक व्यक्ति का जिक्र हो) का उपयोग करना आपके प्रोजेक्ट को नए योगदानकर्ताओं का स्वागत करने में काफी मदद कर सकता है। सरल भाषा पर कायम रहें, क्योंकि हो सकता है कि आपके कई पाठक मूल अंग्रेजी बोलने वाले न हों। -Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. +शब्दों को लिखने के तरीके के अलावा, आपकी कोडिंग शैली भी आपके प्रोजेक्ट के ब्रांड का हिस्सा बन सकती है। [Angular](https://angular.io/guide/styleguide) और [jQuery](https://contribute.jquery.org/style-guide/js/) कठोर कोडिंग शैलियों और दिशानिर्देशों वाली परियोजनाओं के दो उदाहरण हैं। -It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. +जब आप अभी शुरुआत कर रहे हों तो अपने प्रोजेक्ट के लिए स्टाइल गाइड लिखना आवश्यक नहीं है, और आप पाएंगे कि आप वैसे भी अपने प्रोजेक्ट में विभिन्न कोडिंग शैलियों को शामिल करने का आनंद लेते हैं। लेकिन आपको यह अनुमान लगाना चाहिए कि आपकी लेखन और कोडिंग शैली विभिन्न प्रकार के लोगों को कैसे आकर्षित या हतोत्साहित कर सकती है। आपके प्रोजेक्ट के शुरुआती चरण आपके लिए वह मिसाल कायम करने का अवसर हैं जो आप देखना चाहते हैं। -## Your pre-launch checklist +## आपकी प्री-लॉन्च चेकलिस्ट -Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back. +क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://help.github.com/articles/making-a-private-repository-public/) और अपनी पीठ थपथपाएं। -**Documentation** +**दस्तावेज़ीकरण**
@@ -292,65 +291,65 @@ Ready to open source your project? Here's a checklist to help. Check all the box
-**People** +**लोग** -If you're an individual: +यदि आप एक व्यक्ति हैं:
-If you're a company or organization: +यदि आप एक कंपनी या संगठन हैं:
-## You did it! +## तुमने यह किया! -Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow. +आपके पहले प्रोजेक्ट की ओपन सोर्सिंग के लिए बधाई। परिणाम चाहे जो भी हो, सार्वजनिक रूप से काम करना समुदाय के लिए एक उपहार है। प्रत्येक प्रतिबद्धता, टिप्पणी और अनुरोध के साथ, आप अपने लिए और दूसरों के लिए सीखने और बढ़ने के अवसर पैदा कर रहे हैं। From 9c0f9903fdfb783ccf876f824e717e64d39d6e7a Mon Sep 17 00:00:00 2001 From: James Titus Date: Fri, 1 Sep 2023 14:15:30 +0530 Subject: [PATCH 06/25] hindi articles update --- _articles/hi/how-to-contribute.md | 431 +++++++++++++++--------------- 1 file changed, 214 insertions(+), 217 deletions(-) diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md index 17a04ad9821..72795bed162 100644 --- a/_articles/hi/how-to-contribute.md +++ b/_articles/hi/how-to-contribute.md @@ -1,7 +1,7 @@ --- -lang: en -title: How to Contribute to Open Source -description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +lang: hi +title: ओपन सोर्स में कैसे योगदान करें +description: क्या आप ओपन सोर्स में योगदान देना चाहते हैं? पहली बार और अनुभवी लोगों के लिए ओपन सोर्स योगदान करने के लिए एक मार्गदर्शिका। class: contribute order: 1 image: /assets/images/cards/contribute.png @@ -14,198 +14,195 @@ related: -Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. +ओपन सोर्स में योगदान करना किसी भी ऐसे कौशल में सीखने, सिखाने और अनुभव बनाने का एक फायदेमंद तरीका हो सकता है जिसकी आप कल्पना कर सकते हैं। -Why do people contribute to open source? Plenty of reasons! +लोग ओपन सोर्स में योगदान क्यों देते हैं? बहुत सारे कारण! -### Improve software you rely on +### जिस सॉफ़्टवेयर पर आप भरोसा करते हैं उसे सुधारें -Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. +बहुत से ओपन सोर्स योगदानकर्ता उस सॉफ़्टवेयर के उपयोगकर्ता बनकर शुरुआत करते हैं जिसमें वे योगदान करते हैं। जब आप अपने द्वारा उपयोग किए जाने वाले ओपन सोर्स सॉफ़्टवेयर में कोई बग पाते हैं, तो आप यह देखने के लिए स्रोत को देखना चाहेंगे कि क्या आप इसे स्वयं ठीक कर सकते हैं। यदि ऐसा मामला है, तो पैच बैक में योगदान करना यह सुनिश्चित करने का सबसे अच्छा तरीका है कि आपके मित्र (और जब आप अगली रिलीज़ के लिए अपडेट करते हैं तो आप स्वयं) इससे लाभ उठा सकेंगे। -### Improve existing skills +### मौजूदा कौशल में सुधार करें -Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. +चाहे वह कोडिंग हो, यूजर इंटरफ़ेस डिज़ाइन हो, ग्राफ़िक डिज़ाइन हो, लेखन हो, या आयोजन हो, यदि आप अभ्यास की तलाश में हैं, तो ओपन सोर्स प्रोजेक्ट पर आपके लिए एक कार्य है। -### Meet people who are interested in similar things +### ऐसे लोगों से मिलें जो समान चीज़ों में रुचि रखते हैं -Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. +गर्मजोशी से स्वागत करने वाले समुदायों के साथ ओपन सोर्स परियोजनाएं लोगों को वर्षों तक वापस लाती हैं। बहुत से लोग खुले स्रोत में अपनी भागीदारी के माध्यम से आजीवन मित्रता बनाते हैं, चाहे वह सम्मेलनों में एक-दूसरे से मिलना हो या बरिटो के बारे में देर रात तक ऑनलाइन चैट करना हो। -### Find mentors and teach others +### मार्गदर्शक खोजें और दूसरों को सिखाएं -Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved. +किसी साझा प्रोजेक्ट पर दूसरों के साथ काम करने का मतलब है कि आपको यह बताना होगा कि आप काम कैसे करते हैं, साथ ही अन्य लोगों से मदद भी मांगनी होगी। सीखने और सिखाने के कार्य इसमें शामिल सभी लोगों के लिए एक संतुष्टिदायक गतिविधि हो सकते हैं। -### Build public artifacts that help you grow a reputation (and a career) +### सार्वजनिक कलाकृतियों का निर्माण करें जो आपको प्रतिष्ठा (और करियर) बढ़ाने में मदद करें -By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. +परिभाषा के अनुसार, आपके सभी ओपन सोर्स कार्य सार्वजनिक हैं, जिसका अर्थ है कि आप जो भी कर सकते हैं उसे प्रदर्शित करने के लिए आपको कहीं भी ले जाने के लिए निःशुल्क उदाहरण मिलते हैं। -### Learn people skills +### लोगों के कौशल सीखें -Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. +ओपन सोर्स नेतृत्व और प्रबंधन कौशल का अभ्यास करने के अवसर प्रदान करता है, जैसे संघर्षों को हल करना, लोगों की टीमों को संगठित करना और काम को प्राथमिकता देना। -### It's empowering to be able to make changes, even small ones +### परिवर्तन करने में सक्षम होना सशक्त है, यहां तक कि छोटे परिवर्तन भी -You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. +ओपन सोर्स में भाग लेने का आनंद लेने के लिए आपको आजीवन योगदानकर्ता बनने की आवश्यकता नहीं है। क्या आपने कभी किसी वेबसाइट पर कोई टाइपो त्रुटि देखी है और सोचा है कि कोई इसे ठीक कर देगा? किसी ओपन सोर्स प्रोजेक्ट पर, आप बस यही कर सकते हैं। ओपन सोर्स लोगों को उनके जीवन और वे दुनिया का अनुभव कैसे करते हैं, इस पर एजेंसी महसूस करने में मदद करता है, और यह अपने आप में संतुष्टिदायक है। -## What it means to contribute +## योगदान देने का क्या मतलब है -If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong? +यदि आप एक नए ओपन सोर्स योगदानकर्ता हैं, तो प्रक्रिया डराने वाली हो सकती है। आपको सही प्रोजेक्ट कैसे मिलता है? यदि आप नहीं जानते कि कोडिंग कैसे की जाती है तो क्या होगा? क्या हो यदि कुछ गलत हो जाए? -Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience. +कोइ चिंता नहीं! किसी ओपन सोर्स प्रोजेक्ट में शामिल होने के सभी प्रकार के तरीके हैं, और कुछ युक्तियाँ आपको अपने अनुभव से अधिकतम लाभ उठाने में मदद करेंगी। -### You don't have to contribute code +### आपको कोड योगदान करने की आवश्यकता नहीं है -A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions! +ओपन सोर्स में योगदान देने के बारे में एक आम ग़लतफ़हमी यह है कि आपको कोड का योगदान करने की आवश्यकता है। वास्तव में, यह अक्सर किसी परियोजना के अन्य भाग होते हैं जिन्हें [सबसे अधिक उपेक्षित या अनदेखा](https://github.com/blog/2195-the-shape-of-open-source) किया जाता है। आप इस प्रकार के योगदान की पेशकश करके परियोजना पर बहुत बड़ा उपकार करेंगे! -Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. +भले ही आपको कोड लिखना पसंद हो, अन्य प्रकार के योगदान किसी प्रोजेक्ट में शामिल होने और समुदाय के अन्य सदस्यों से मिलने का एक शानदार तरीका है। उन संबंधों के निर्माण से आपको परियोजना के अन्य हिस्सों पर काम करने का अवसर मिलेगा। -### Do you like planning events? +### क्या आपको आयोजनों की योजना बनाना पसंद है? -* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) -* Organize the project's conference (if they have one) -* Help community members find the right conferences and submit proposals for speaking +* परियोजना के बारे में कार्यशालाएँ या बैठकें आयोजित करें, [जैसे @fzamperin ने NodeSchool के लिए किया](https://github.com/nodeschool/organizers/issues/406) +* परियोजना का सम्मेलन आयोजित करें (यदि उनके पास एक है) +* समुदाय के सदस्यों को सही सम्मेलन ढूंढने और बोलने के लिए प्रस्ताव प्रस्तुत करने में सहायता करें -### Do you like to design? +### क्या आपको डिज़ाइन करना पसंद है? -* Restructure layouts to improve the project's usability -* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) -* Put together a style guide to help the project have a consistent visual design -* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) +* परियोजना की उपयोगिता में सुधार के लिए लेआउट का पुनर्गठन करें +* प्रोजेक्ट के नेविगेशन या मेनू को पुनर्गठित और परिष्कृत करने के लिए उपयोगकर्ता अनुसंधान करें, [जैसा कि Drupal सुझाव देता है](https://www.drupal.org/community-initiatives/drupal-core/usability) +* प्रोजेक्ट को एक सुसंगत विज़ुअल डिज़ाइन बनाने में मदद करने के लिए एक स्टाइल गाइड साथ रखें +* टी-शर्ट या नए लोगो के लिए कला बनाएं, [जैसे hapi.js के योगदानकर्ताओं ने किया](https://github.com/hapijs/contrib/issues/68) -### Do you like to write? +### क्या आप लिखना पसंद करते हैं? -* Write and improve the project's documentation -* Curate a folder of examples showing how the project is used -* Start a newsletter for the project, or curate highlights from the mailing list -* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) -* Write a translation for the project's documentation +* प्रोजेक्ट के दस्तावेज़ीकरण को लिखें और सुधारें +* प्रोजेक्ट का उपयोग कैसे किया जाता है, यह दर्शाने वाले उदाहरणों का एक फ़ोल्डर बनाएं +* प्रोजेक्ट के लिए एक न्यूज़लेटर शुरू करें, या मेलिंग सूची से हाइलाइट्स क्यूरेट करें +* प्रोजेक्ट के लिए ट्यूटोरियल लिखें, [जैसे PyPA के योगदानकर्ताओं ने किया](https://github.com/pypa/python-package-user-guide/issues/194) +* परियोजना के दस्तावेज़ीकरण के लिए एक अनुवाद लिखें -### Do you like organizing? +### क्या आपको आयोजन करना पसंद है? -* Link to duplicate issues, and suggest new issue labels, to keep things organized -* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) -* Ask clarifying questions on recently opened issues to move the discussion forward +* चीजों को व्यवस्थित रखने के लिए डुप्लिकेट मुद्दों से लिंक करें, और नए अंक लेबल का सुझाव दें +* खुले मुद्दों पर गौर करें और पुराने मुद्दों को बंद करने का सुझाव दें, [जैसे @nzakas ने ESLint के लिए किया](https://github.com/eslint/eslint/issues/6765) +* चर्चा को आगे बढ़ाने के लिए हाल ही में खुले मुद्दों पर स्पष्ट प्रश्न पूछें -### Do you like to code? +### क्या आपको कोड करना पसंद है? -* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) -* Ask if you can help write a new feature -* Automate project setup -* Improve tooling and testing +* निपटने के लिए एक खुला मुद्दा खोजें, [जैसे @dianjin ने कैटलॉग के लिए किया](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* पूछें कि क्या आप एक नई सुविधा लिखने में मदद कर सकते हैं +* स्वचालित प्रोजेक्ट सेटअप +* टूलींग और परीक्षण में सुधार करें -### Do you like helping people? +### क्या आपको लोगों की मदद करना पसंद है? -* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit -* Answer questions for people on open issues -* Help moderate the discussion boards or conversation channels +* प्रोजेक्ट के बारे में प्रश्नों के उत्तर दें, उदाहरण के लिए, स्टैक ओवरफ्लो ([इस पोस्टग्रेज उदाहरण की तरह](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) या रेडिट +* खुले मुद्दों पर लोगों के सवालों के जवाब दें +* चर्चा बोर्डों या वार्तालाप चैनलों को मॉडरेट करने में सहायता करें -### Do you like helping others code? +### क्या आपको दूसरों की कोड में मदद करना पसंद है? -* Review code on other people's submissions -* Write tutorials for how a project can be used -* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* अन्य लोगों के सबमिशन पर कोड की समीक्षा करें +* किसी प्रोजेक्ट का उपयोग कैसे किया जा सकता है, इसके लिए ट्यूटोरियल लिखें +* किसी अन्य योगदानकर्ता को सलाह देने की पेशकश, [जैसे @ereichert ने Rust पर @bronzdoc के लिए किया](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) -### You don't just have to work on software projects! +### आपको सिर्फ सॉफ्टवेयर प्रोजेक्ट पर काम नहीं करना है! -While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. +जबकि "ओपन सोर्स" अक्सर सॉफ़्टवेयर को संदर्भित करता है, आप किसी भी चीज़ पर सहयोग कर सकते हैं। ऐसी किताबें, रेसिपी, सूचियाँ और कक्षाएं हैं जिन्हें ओपन सोर्स प्रोजेक्ट के रूप में विकसित किया जाता है। -For example: +उदाहरण के लिए: -* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) -* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates -* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) +* @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) बनाया। -Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. +भले ही आप एक सॉफ़्टवेयर डेवलपर हों, दस्तावेज़ीकरण प्रोजेक्ट पर काम करने से आपको ओपन सोर्स में शुरुआत करने में मदद मिल सकती है। उन परियोजनाओं पर काम करना अक्सर कम डराने वाला होता है जिनमें कोड शामिल नहीं होता है, और सहयोग की प्रक्रिया आपके आत्मविश्वास और अनुभव का निर्माण करेगी। -## Orienting yourself to a new project +## अपने आप को एक नई परियोजना की ओर उन्मुख करना -For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. +टाइपो फिक्स से अधिक किसी भी चीज़ के लिए, ओपन सोर्स में योगदान करना किसी पार्टी में अजनबियों के समूह के पास जाने जैसा है। यदि आप लामाओं के बारे में बात करना शुरू करते हैं, जबकि वे सुनहरी मछली के बारे में गहन चर्चा में थे, तो वे शायद आपको थोड़ा अजीब तरीके से देखेंगे। -Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. +अपने स्वयं के सुझावों पर आँख मूँद कर कूदने से पहले, कमरे को पढ़ना सीखना शुरू करें। ऐसा करने से संभावना बढ़ जाती है कि आपके विचारों पर ध्यान दिया जाएगा और सुना जाएगा। -### Anatomy of an open source project +### एक ओपन सोर्स प्रोजेक्ट का एनाटॉमी -Every open source community is different. +प्रत्येक खुला स्रोत समुदाय अलग है। -Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. +एक ओपन सोर्स प्रोजेक्ट पर वर्षों बिताने का मतलब है कि आपको एक ओपन सोर्स प्रोजेक्ट के बारे में पता चल गया है। एक अलग प्रोजेक्ट पर जाएँ, और आप पाएंगे कि शब्दावली, मानदंड और संचार शैलियाँ पूरी तरह से अलग हैं। -That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. +जैसा कि कहा गया है, कई ओपन सोर्स प्रोजेक्ट समान संगठनात्मक संरचना का पालन करते हैं। विभिन्न सामुदायिक भूमिकाओं और समग्र प्रक्रिया को समझने से आपको किसी भी नई परियोजना के प्रति शीघ्रता से उन्मुख होने में मदद मिलेगी। -A typical open source project has the following types of people: +एक विशिष्ट ओपन सोर्स प्रोजेक्ट में निम्नलिखित प्रकार के लोग होते हैं: -* **Author:** The person/s or organization that created the project -* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) -* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) -* **Contributors:** Everyone who has contributed something back to the project -* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction +* **लेखक:** वह व्यक्ति/संगठन जिसने प्रोजेक्ट बनाया है +* **स्वामी:** वह व्यक्ति/व्यक्ति जिनके पास संगठन या भंडार पर प्रशासनिक स्वामित्व है (हमेशा मूल लेखक के समान नहीं) +* **रखरखावकर्ता:** योगदानकर्ता जो परियोजना के दृष्टिकोण को आगे बढ़ाने और संगठनात्मक पहलुओं को प्रबंधित करने के लिए जिम्मेदार हैं (वे परियोजना के लेखक या मालिक भी हो सकते हैं।) +* **योगदानकर्ता:** हर कोई जिसने परियोजना में कुछ न कुछ योगदान दिया है +* **समुदाय सदस्य:** वे लोग जो परियोजना का उपयोग करते हैं। वे बातचीत में सक्रिय हो सकते हैं या परियोजना की दिशा पर अपनी राय व्यक्त कर सकते हैं -Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information. +बड़ी परियोजनाओं में उपसमितियां या कार्य समूह भी हो सकते हैं जो टूलींग, ट्राइएज, सामुदायिक मॉडरेशन और इवेंट आयोजन जैसे विभिन्न कार्यों पर केंद्रित हो सकते हैं। इस जानकारी को पाने के लिए किसी प्रोजेक्ट की वेबसाइट पर "टीम" पृष्ठ, या शासन दस्तावेज़ के भंडार में देखें। -A project also has documentation. These files are usually listed in the top level of a repository. +एक प्रोजेक्ट में दस्तावेज़ीकरण भी होता है. ये फ़ाइलें आमतौर पर रिपॉजिटरी के शीर्ष स्तर पर सूचीबद्ध होती हैं। -* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. -* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. -* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. -* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. -* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects. +* **लाइसेंस:** परिभाषा के अनुसार, प्रत्येक ओपन सोर्स प्रोजेक्ट के पास एक [ओपन सोर्स लाइसेंस](https://choosealicense.com) होना चाहिए। यदि प्रोजेक्ट के पास लाइसेंस नहीं है, तो यह खुला स्रोत नहीं है। +* **रीडमी:** रीडमी एक निर्देश पुस्तिका है जो परियोजना में नए समुदाय के सदस्यों का स्वागत करती है। यह बताता है कि परियोजना क्यों उपयोगी है और इसे कैसे शुरू किया जाए। +* **योगदान:** जबकि READMEs लोगों को परियोजना का उपयोग करने में मदद करते हैं, योगदान करने वाले दस्तावेज़ लोगों को परियोजना में योगदान देने में मदद करते हैं। यह बताता है कि किस प्रकार के योगदान की आवश्यकता है और प्रक्रिया कैसे काम करती है। हालाँकि हर परियोजना में योगदान फ़ाइल नहीं होती है, इसकी उपस्थिति संकेत देती है कि यह योगदान करने के लिए एक स्वागत योग्य परियोजना है। +* **आचार संहिता:** आचार संहिता प्रतिभागियों के व्यवहार से संबंधित बुनियादी नियम निर्धारित करती है और एक मैत्रीपूर्ण, स्वागत योग्य वातावरण बनाने में मदद करती है। हालाँकि हर परियोजना में एक Code_OF_CONDUCT फ़ाइल नहीं होती है, लेकिन इसकी उपस्थिति संकेत देती है कि यह योगदान देने के लिए एक स्वागत योग्य परियोजना है। +* **अन्य दस्तावेज़:** अतिरिक्त दस्तावेज़ हो सकते हैं, जैसे ट्यूटोरियल, वॉकथ्रू, या शासन नीतियां, विशेष रूप से बड़ी परियोजनाओं पर। -Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works. +अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है। -* **Issue tracker:** Where people discuss issues related to the project. -* **Pull requests:** Where people discuss and review changes that are in progress. -* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. -* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. +* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं। +* **पुल अनुरोध:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं। +* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं। +* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं। -## Finding a project to contribute to +## योगदान देने के लिए एक परियोजना ढूँढना -Now that you've figured out how open source projects work, it's time to find a project to contribute to! +अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है। -If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_ +* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं। +* **पुल अनुरोध:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं। +* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं। +* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं। -Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. +## योगदान देने के लिए एक परियोजना ढूँढना -Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. +आप README को स्कैन कर सकते हैं और एक टूटा हुआ लिंक या कोई टाइपो पा सकते हैं। या आप एक नए उपयोगकर्ता हैं और आपने देखा कि कुछ टूटा हुआ है, या कोई समस्या है जो आपको लगता है कि वास्तव में दस्तावेज़ में होनी चाहिए। इसे नज़रअंदाज़ करने और आगे बढ़ने, या किसी और से इसे ठीक करने के लिए कहने के बजाय, देखें कि क्या आप इसमें योगदान देकर मदद कर सकते हैं। खुले स्रोत का यही मतलब है! -Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. +> [28% आकस्मिक योगदान](https://www.igor.pro.br/publica/papers/saner2016.pdf) ओपन सोर्स के लिए दस्तावेज हैं, जैसे टाइपो फिक्स, रिफॉर्मेटिंग, या अनुवाद लिखना। -Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. +यदि आप मौजूदा मुद्दों की तलाश कर रहे हैं जिन्हें आप ठीक कर सकते हैं, तो प्रत्येक ओपन सोर्स प्रोजेक्ट में एक `/contribute` पेज होता है जो शुरुआती-अनुकूल मुद्दों पर प्रकाश डालता है जिनके साथ आप शुरुआत कर सकते हैं। GitHub पर रिपॉजिटरी के मुख्य पृष्ठ पर जाएँ, और URL के अंत में `/contribute` जोड़ें (उदाहरण के लिए [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). -You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! - -> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. - -If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). - -You can also use one of the following resources to help you discover and contribute to new projects: +नई परियोजनाओं को खोजने और उनमें योगदान देने में सहायता के लिए आप निम्नलिखित संसाधनों में से किसी एक का भी उपयोग कर सकते हैं: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) @@ -217,304 +214,304 @@ You can also use one of the following resources to help you discover and contrib * [First Contributions](https://firstcontributions.github.io) * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) -### A checklist before you contribute +### योगदान देने से पहले एक चेकलिस्ट -When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response. +जब आपको कोई ऐसा प्रोजेक्ट मिल जाए जिसमें आप योगदान करना चाहते हैं, तो यह सुनिश्चित करने के लिए त्वरित स्कैन करें कि प्रोजेक्ट योगदान स्वीकार करने के लिए उपयुक्त है। वरना आपकी मेहनत को कभी जवाब नहीं मिल पाएगा. -Here's a handy checklist to evaluate whether a project is good for new contributors. +यह मूल्यांकन करने के लिए एक आसान चेकलिस्ट है कि कोई प्रोजेक्ट नए योगदानकर्ताओं के लिए अच्छा है या नहीं। -**Meets the definition of open source** +**ओपन सोर्स की परिभाषा को पूरा करता है**
+ क्या इसके पास लाइसेंस है? आमतौर पर, रिपॉजिटरी के रूट में LICENSE नामक एक फ़ाइल होती है। +
-**Project actively accepts contributions** +**परियोजना सक्रिय रूप से योगदान स्वीकार करती है** -Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage. +Main branch पर commit प्रतिबद्ध को देखें। GitHub पर, आप इस जानकारी को रिपॉजिटरी के होमपेज पर देख सकते हैं।
-Next, look at the project's issues. +इसके बाद, परियोजना के मुद्दों को देखें।
-Now do the same for the project's pull requests. +अब प्रोजेक्ट के पुल रीकवेस्ट के लिए भी ऐसा ही करें।
-**Project is welcoming** +**परियोजना स्वागतयोग्य है** -A project that is friendly and welcoming signals that they will be receptive to new contributors. +एक परियोजना जो मैत्रीपूर्ण और स्वागत योग्य है, यह संकेत देती है कि वे नए योगदानकर्ताओं के प्रति ग्रहणशील होंगे।
-## How to submit a contribution +## योगदान कैसे जमा करें -You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. +आपको अपनी पसंद का एक प्रोजेक्ट मिल गया है और आप योगदान देने के लिए तैयार हैं। अंत में! यहां बताया गया है कि अपना योगदान सही तरीके से कैसे प्राप्त करें। -### Communicating effectively +### प्रभावी ढंग से संचार करना -Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. +चाहे आप एक बार के योगदानकर्ता हों या किसी समुदाय में शामिल होने का प्रयास कर रहे हों, दूसरों के साथ काम करना सबसे महत्वपूर्ण कौशलों में से एक है जिसे आप ओपन सोर्स में विकसित करेंगे। -Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. +इससे पहले कि आप कोई मुद्दा खोलें या अनुरोध खींचें, या चैट में कोई प्रश्न पूछें, अपने विचारों को प्रभावी ढंग से सामने लाने में मदद के लिए इन बिंदुओं को ध्यान में रखें। -**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). +**संदर्भ दें।** दूसरों को तेजी से आगे बढ़ने में मदद करें। यदि आप किसी त्रुटि का सामना कर रहे हैं, तो बताएं कि आप क्या करने का प्रयास कर रहे हैं और इसे कैसे पुन: उत्पन्न करना है। यदि आप कोई नया विचार सुझा रहे हैं, तो स्पष्ट करें कि आप क्यों सोचते हैं कि यह परियोजना के लिए उपयोगी होगा (केवल आपके लिए नहीं!)। -> 😇 _"X doesn't happen when I do Y"_ +> 😇 _"जब मैं यह करता हूं तो वह नहीं होता"_ > -> 😢 _"X is broken! Please fix it."_ +> 😢 _"यह टूट गया है! कृपया इसे ठीक करें।"_ -**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn. +**कृपया अपना होमवर्क पहले से कर लें।** चीजों को न जानना ठीक है, लेकिन दिखाएं कि आपने प्रयास किया। मदद मांगने से पहले, किसी प्रोजेक्ट की रीडमी, दस्तावेज़ीकरण, मुद्दे (खुले या बंद), मेलिंग सूची की जांच करना और उत्तर के लिए इंटरनेट पर खोजना सुनिश्चित करें। जब आप प्रदर्शित करेंगे कि आप सीखने का प्रयास कर रहे हैं तो लोग इसकी सराहना करेंगे। -> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> 😇 _"मुझे नहीं पता कि ईस को कैसे लागू किया जाए। मैंने सहायता दस्तावेजों की जांच की और कोई उल्लेख नहीं मिला।"_ > -> 😢 _"How do I X?"_ +> 😢 _"मैं कैसे यह करूं?"_ -**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. +**अनुरोधों को संक्षिप्त और सीधा रखें।** ईमेल भेजने की तरह, हर योगदान, चाहे कितना भी सरल या उपयोगी क्यों न हो, किसी और की समीक्षा की आवश्यकता होती है। कई परियोजनाओं में मदद के लिए उपलब्ध लोगों की तुलना में अधिक अनुरोध आ रहे हैं। संक्षिप्त रखें। आपको इस बात की संभावना बढ़ जाएगी कि कोई आपकी मदद कर पाएगा। -> 😇 _"I'd like to write an API tutorial."_ +> 😇 _"मैं एक एपीआई ट्यूटोरियल लिखना चाहूंगा।"_ > -> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ +> 😢 _"मैं पिछले दिन राजमार्ग पर गाड़ी चला रहा था और गैस के लिए रुका, और तभी मेरे मन में यह अद्भुत विचार आया कि हमें क्या करना चाहिए, लेकिन इससे पहले कि मैं यह समझाऊं, मैं आपको दिखाता हूं..."_ -**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. +**सभी संचार सार्वजनिक रखें।** हालांकि यह आकर्षक है, जब तक आपको संवेदनशील जानकारी (जैसे कोई सुरक्षा मुद्दा या गंभीर आचरण उल्लंघन) साझा करने की आवश्यकता न हो, निजी तौर पर अनुरक्षकों तक न पहुंचें। जब आप बातचीत को सार्वजनिक रखते हैं, तो अधिक लोग आपके आदान-प्रदान से सीख सकते हैं और लाभ उठा सकते हैं। चर्चाएँ, अपने आप में, योगदान हो सकती हैं। -> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> 😇 _(एक टिप्पणी के रूप में) "@-maintainer नमस्ते! हमें इस PR पर कैसे आगे बढ़ना चाहिए?"_ > -> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ +> 😢_(एक ईमेल के रूप में) "अरे, ईमेल पर आपको परेशान करने के लिए खेद है, लेकिन मैं सोच रहा था कि क्या आपको मेरे PR की समीक्षा करने का मौका मिला है"_ -**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. +**प्रश्न पूछना ठीक है (लेकिन धैर्य रखें!)** हर कोई किसी न किसी समय परियोजना में नया था, और यहां तक ​​कि अनुभवी योगदानकर्ताओं को भी जब वे किसी नई परियोजना को देखते हैं तो उन्हें तेजी लाने की जरूरत होती है। इसी तरह, लंबे समय तक अनुरक्षक भी हमेशा परियोजना के हर हिस्से से परिचित नहीं होते हैं। उन्हें वही धैर्य दिखाएं जो आप चाहते हैं कि वे आपके प्रति दिखाएं। -> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> 😇 _"इस त्रुटि पर ध्यान देने के लिए धन्यवाद। मैंने आपके सुझावों का पालन किया। यहां आउटपुट है।"_ > -> 😢 _"Why can't you fix my problem? Isn't this your project?"_ +> 😢 _"आप मेरी समस्या का समाधान क्यों नहीं कर सकते? क्या यह आपका प्रोजेक्ट नहीं है?"_ -**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. +**सामुदायिक निर्णयों का सम्मान करें।** आपके विचार समुदाय की प्राथमिकताओं या दृष्टिकोण से भिन्न हो सकते हैं। वे प्रतिक्रिया दे सकते हैं या आपके विचार को आगे न बढ़ाने का निर्णय ले सकते हैं। जबकि आपको चर्चा करनी चाहिए और समझौते की तलाश करनी चाहिए, लेकिन अनुरक्षकों को आपके निर्णय के साथ आपकी इच्छा से अधिक समय तक रहना होगा। यदि आप उनकी दिशा से असहमत हैं, तो आप हमेशा अपने स्वयं के कांटे पर काम कर सकते हैं या अपना स्वयं का प्रोजेक्ट शुरू कर सकते हैं। -> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ +> 😇 _"मुझे निराशा है कि आप मेरे उपयोग के मामले का समर्थन नहीं कर सकते, लेकिन जैसा कि आपने समझाया है कि यह केवल उपयोगकर्ताओं के एक छोटे हिस्से को प्रभावित करता है, मैं समझता हूं क्यों। सुनने के लिए धन्यवाद।"_ > -> 😢 _"Why won't you support my use case? This is unacceptable!"_ +> 😢 _"आप मेरे उपयोग के मामले का समर्थन क्यों नहीं करेंगे? यह अस्वीकार्य है!"_ -**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. +**सबसे बढ़कर, इसे उत्तम दर्जे का रखें।** ओपन सोर्स दुनिया भर के सहयोगियों से बना है। भाषाओं, संस्कृतियों, भूगोलों और समय क्षेत्रों में संदर्भ खो जाता है। इसके अलावा, लिखित संचार से स्वर या मनोदशा को व्यक्त करना कठिन हो जाता है। इन वार्तालापों में अच्छे इरादे मानें। किसी विचार पर विनम्रतापूर्वक ज़ोर देना, अधिक संदर्भ मांगना, या अपनी स्थिति को और स्पष्ट करना ठीक है। बस इंटरनेट को उस समय से बेहतर जगह छोड़ने का प्रयास करें जब यह आपको मिला था। -### Gathering context +### संदर्भ एकत्रित करना -Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. +कुछ भी करने से पहले, यह सुनिश्चित करने के लिए त्वरित जांच करें कि आपके विचार की चर्चा कहीं और नहीं की गई है। प्रोजेक्ट के README, मुद्दे (खुले और बंद), मेलिंग सूची और स्टैक ओवरफ़्लो को स्किम करें। आपको हर चीज़ को पढ़ने में घंटों खर्च करने की ज़रूरत नहीं है, लेकिन कुछ प्रमुख शब्दों की त्वरित खोज बहुत काम आती है। -If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: +यदि आपको अपना विचार कहीं और नहीं मिल रहा है, तो आप एक कदम उठाने के लिए तैयार हैं। यदि प्रोजेक्ट GitHub पर है, तो आप संभवतः कोई समस्या खोलकर या अनुरोध खींचकर संवाद करेंगे: -* **Issues** are like starting a conversation or discussion -* **Pull requests** are for starting work on a solution -* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one +* **ईशूस** बातचीत या चर्चा शुरू करने जैसा है +* **पुल रीकवेस्ट** समाधान पर काम शुरू करने के लिए हैं +* **हल्के संचार के लिए,** जैसे कि स्पष्टीकरण या कैसे-कैसे प्रश्न करें, स्टैक ओवरफ़्लो, IRS, स्लैक, या अन्य चैट चैनलों पर पूछने का प्रयास करें, यदि प्रोजेक्ट में कोई है -Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. +किसी मुद्दे को खोलने या अनुरोध खींचने से पहले, यह देखने के लिए कि क्या आपको कुछ विशिष्ट शामिल करने की आवश्यकता है, प्रोजेक्ट के योगदान दस्तावेज़ (आमतौर पर CONTRIBUTING या README में एक फ़ाइल) की जाँच करें। उदाहरण के लिए, वे आपसे एक टेम्पलेट का पालन करने के लिए कह सकते हैं, या आपसे परीक्षण का उपयोग करने के लिए कह सकते हैं। -If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. +यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://help.github.com/articles/watching-repositories/) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है। -### Opening an issue +### एक मुद्दा खुल रहा है -You should usually open an issue in the following situations: +आपको आमतौर पर निम्नलिखित स्थितियों में कोई मुद्दा खोलना चाहिए: -* Report an error you can't solve yourself -* Discuss a high-level topic or idea (for example, community, vision or policies) -* Propose a new feature or other project idea +* उस त्रुटि की रिपोर्ट करें जिसे आप स्वयं हल नहीं कर सकते +* किसी उच्च-स्तरीय विषय या विचार पर चर्चा करें (उदाहरण के लिए, समुदाय, दृष्टिकोण या नीतियां) +* एक नई सुविधा या अन्य परियोजना विचार का प्रस्ताव रखें -Tips for communicating on issues: +मुद्दों पर संवाद करने के लिए युक्तियाँ: -* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. -* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. -* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. +* **यदि आप कोई खुला मुद्दा देखते हैं जिससे आप निपटना चाहते हैं,** लोगों को यह बताने के लिए कि आप इस मुद्दे पर हैं, उस मुद्दे पर टिप्पणी करें। इस तरह, लोगों द्वारा आपके काम की नकल करने की संभावना कम होगी। +* **यदि कोई मुद्दा कुछ समय पहले खोला गया था,** यह संभव है कि इसे कहीं और संबोधित किया जा रहा है, या पहले ही हल किया जा चुका है, इसलिए काम शुरू करने से पहले पुष्टि के लिए टिप्पणी करें। +* **यदि आपने कोई मुद्दा खोला है, लेकिन बाद में आपको स्वयं उत्तर मिल गया है,** लोगों को बताने के लिए मुद्दे पर टिप्पणी करें, फिर मुद्दे को बंद कर दें। यहां तक कि उस परिणाम का दस्तावेज़ीकरण भी परियोजना में एक योगदान है। -### Opening a pull request +### पुल रीकवेस्ट खोलना -You should usually open a pull request in the following situations: +आपको आमतौर पर निम्नलिखित स्थितियों में पुल अनुरोध खोलना चाहिए: -* Submit trivial fixes (for example, a typo, a broken link or an obvious error) -* Start work on a contribution that was already asked for, or that you've already discussed, in an issue +* मामूली सुधार सबमिट करें (उदाहरण के लिए, एक टाइपो, एक टूटा हुआ लिंक या एक स्पष्ट त्रुटि) +* उस योगदान पर काम शुरू करें जो पहले से ही मांगा गया था, या जिस पर आप पहले ही किसी मुद्दे पर चर्चा कर चुके हैंn -A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. +पुल अनुरोध को समाप्त कार्य का प्रतिनिधित्व करने की आवश्यकता नहीं है। आमतौर पर पुल अनुरोध को जल्दी खोलना बेहतर होता है, ताकि अन्य लोग आपकी प्रगति को देख सकें या उस पर प्रतिक्रिया दे सकें। बस इसे "ड्राफ्ट" के रूप में खोलें या विषय पंक्ति में "डब्ल्यूआईपी" (कार्य प्रगति पर) के रूप में चिह्नित करें। आप बाद में कभी भी और कमिट जोड़ सकते हैं। -If the project is on GitHub, here's how to submit a pull request: +यदि प्रोजेक्ट GitHub पर है, तो पुल अनुरोध सबमिट करने का तरीका यहां दिया गया है: -* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) -* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. -* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") -* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. -* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project. -* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. +* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://help.github.com/articles/syncing-a-fork/).) +* **[एक ब्रेनच बनाएँ](https://guides.github.com/introduction/flow/)** आपके संपादनों के लिए. +* **अपने पीआर में किसी भी प्रासंगिक मुद्दे** या सहायक दस्तावेज़ का संदर्भ लें (उदाहरण के लिए, " #37 बंद होता है।") +* **यदि आपके परिवर्तनों में HTML/CSS में अंतर शामिल है तो पहले और बाद के स्क्रीनशॉट शामिल करें**। छवियों को अपने पुल अनुरोध के मुख्य भाग में खींचें और छोड़ें। +* **अपने परिवर्तनों का परीक्षण करें!** यदि कोई मौजूदा परीक्षण मौजूद है तो उसके विरुद्ध अपने परिवर्तन चलाएँ और आवश्यकता पड़ने पर नए बनाएँ। परीक्षण मौजूद हैं या नहीं, सुनिश्चित करें कि आपके परिवर्तन मौजूदा प्रोजेक्ट को बाधित नहीं करते हैं। +* **परियोजना की शैली में अपनी सर्वोत्तम क्षमता से योगदान दें**। इसका मतलब यह हो सकता है कि इंडेंट, सेमी-कोलन या टिप्पणियों का उपयोग आप अपने स्वयं के भंडार से अलग तरीके से करेंगे, लेकिन इससे अनुरक्षक के लिए विलय करना, दूसरों के लिए समझना और भविष्य में बनाए रखना आसान हो जाता है। -If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. +यदि यह आपका पहला पुल अनुरोध है, तो [मेक अ पुल रिक्वेस्ट](http://makeapullrequest.com/) देखें, जिसे @kentcdodds ने वॉकथ्रू वीडियो ट्यूटोरियल के रूप में बनाया है। आप @Roshanjossey द्वारा बनाए गए [प्रथम योगदान](https://github.com/Roshanjossey/first-contributions) रिपॉजिटरी में पुल अनुरोध करने का अभ्यास भी कर सकते हैं। -## What happens after you submit a contribution +## आपके योगदान जमा करने के बाद क्या होता है -You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. +तुमने यह किया! ओपन सोर्स योगदानकर्ता बनने पर बधाई। हमें उम्मीद है कि यह कई में से पहला है। -After you submit a contribution, one of the following will happen: +आपके द्वारा योगदान जमा करने के बाद, निम्नलिखित में से एक होगा: -### 😭 You don't get a response. +### 😭 आपको कोई प्रतिक्रिया नहीं मिलती। -Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. +उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#a-checklist-before-you-contribute) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी। -If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. +यदि आपको एक सप्ताह से अधिक समय में कोई प्रतिक्रिया नहीं मिली है, तो किसी से समीक्षा के लिए पूछते हुए, उसी थ्रेड में विनम्रतापूर्वक प्रतिक्रिया देना उचित है। यदि आप अपने योगदान की समीक्षा करने के लिए सही व्यक्ति का नाम जानते हैं, तो आप उस थ्रेड में उनका @-mention कर सकते हैं। -**Don't** reach out to that person privately; remember that public communication is vital to open source projects. +**उस व्यक्ति तक निजी तौर पर संपर्क न करें; याद रखें कि ओपन सोर्स परियोजनाओं के लिए सार्वजनिक संचार महत्वपूर्ण है। -If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. +यदि आप विनम्रतापूर्वक बात करते हैं और फिर भी कोई प्रतिक्रिया नहीं देता है, तो यह संभव है कि कोई भी कभी भी प्रतिक्रिया नहीं देगा। यह कोई बढ़िया एहसास नहीं है, लेकिन इससे आपको हतोत्साहित न होने दें। यह हर किसी के साथ हुआ है! आपको प्रतिक्रिया न मिलने के कई संभावित कारण हो सकते हैं, जिनमें व्यक्तिगत परिस्थितियाँ भी शामिल हैं जो आपके नियंत्रण से बाहर हो सकती हैं। योगदान देने के लिए कोई अन्य प्रोजेक्ट या तरीका खोजने का प्रयास करें। यदि कुछ भी हो, तो यह एक अच्छा कारण है कि समुदाय के अन्य सदस्यों के शामिल होने और प्रतिक्रिया देने से पहले योगदान देने में बहुत अधिक समय न लगाया जाए। -### 🚧 Someone requests changes to your contribution. +### 🚧 कोई आपके योगदान में परिवर्तन का अनुरोध करता है। -It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. +यह सामान्य बात है कि आपसे आपके योगदान में परिवर्तन करने के लिए कहा जाएगा, चाहे वह आपके विचार के दायरे पर प्रतिक्रिया हो, या आपके कोड में परिवर्तन हो। -When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. +जब कोई परिवर्तन का अनुरोध करता है, तो उत्तरदायी बनें। उन्होंने आपके योगदान की समीक्षा करने के लिए समय लिया है। पीआर खोलना और चले जाना बुरी आदत है। यदि आप नहीं जानते कि परिवर्तन कैसे करें, तो समस्या पर शोध करें और यदि आपको सहायता की आवश्यकता हो तो सहायता माँगें। -If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. +यदि आपके पास अब इस मुद्दे पर काम करने का समय नहीं है (उदाहरण के लिए, यदि बातचीत महीनों से चल रही है, और आपकी परिस्थितियाँ बदल गई हैं), तो अनुरक्षक को बताएं ताकि वे प्रतिक्रिया की उम्मीद न करें। कोई अन्य व्यक्ति कार्यभार संभालने में प्रसन्न हो सकता है। -### 👎 Your contribution doesn't get accepted. +### 👎 आपका योगदान स्वीकार नहीं किया जाता। -Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! +आपका योगदान अंततः स्वीकार किया भी जा सकता है और नहीं भी। उम्मीद है कि आपने पहले से ही इसमें बहुत अधिक काम नहीं किया होगा। यदि आप निश्चित नहीं हैं कि इसे क्यों स्वीकार नहीं किया गया, तो अनुरक्षक से फीडबैक और स्पष्टीकरण मांगना बिल्कुल उचित है। हालाँकि, अंततः, आपको इसका सम्मान करना होगा कि यह उनका निर्णय है। बहस न करें या शत्रुतापूर्ण न बनें। यदि आप असहमत हैं तो फोर्क और अपने संस्करण पर काम करने के लिए आपका हमेशा स्वागत है! -### 🎉 Your contribution gets accepted. +### 🎉 आपका योगदान स्वीकार किया जाता है। -Hooray! You've successfully made an open source contribution! +हुर्रे! आपने सफलतापूर्वक ओपन सोर्स योगदान दे दिया है! -## You did it! +## तुमने यह किया! -Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. +चाहे आपने अभी अपना पहला ओपन सोर्स योगदान दिया हो, या आप योगदान करने के नए तरीकों की तलाश कर रहे हों, हमें उम्मीद है कि आप कार्रवाई करने के लिए प्रेरित होंगे। भले ही आपका योगदान स्वीकार नहीं किया गया हो, जब कोई अनुरक्षक आपकी मदद करने का प्रयास करे तो धन्यवाद कहना न भूलें। ओपन सोर्स आपके जैसे लोगों द्वारा बनाया गया है: एक समय में एक मुद्दा, पुल अनुरोध, टिप्पणी, या हाई-फाइव। From d0bf0bdb8e4e6e56dea5af56a1b62608c76523d5 Mon Sep 17 00:00:00 2001 From: James Titus Date: Fri, 1 Sep 2023 14:40:10 +0530 Subject: [PATCH 07/25] Hindi translation commit --- _articles/hi/best-practices.md | 3 --- _articles/hi/building-community.md | 7 +++---- _articles/hi/getting-paid.md | 4 ++-- _articles/hi/how-to-contribute.md | 18 +++++++++++++++--- _articles/hi/starting-a-project.md | 1 + 5 files changed, 21 insertions(+), 12 deletions(-) diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md index 1613e0d2809..ea8c4047765 100644 --- a/_articles/hi/best-practices.md +++ b/_articles/hi/best-practices.md @@ -18,8 +18,6 @@ related: परियोजना को संभालने के लिए कोड से ज्यादा की आवश्यकता होती है। ये कार्य अक्सर अप्रत्याशित होते हैं, लेकिन एक बढ़ती हुई परियोजना के लिए ये उतने ही महत्वपूर्ण होते हैं। हमने कुछ तरीके जुटाए हैं जो आपके जीवन को आसान बनाने में मदद करेंगे, प्रक्रियाओं की दस्तावेजीकरण से लेकर आपकी समुदाय का उपयोग करने तक। - - ## प्रक्रियाओं की दस्तावेजीकरण चीजों को लिखना मेंटेनर के रूप में आपकी सबसे महत्वपूर्ण चीजों में से एक है। @@ -40,7 +38,6 @@ related: उदाहरण के लिए, @lord ने यह जानकर पाया कि परियोजना की दृष्टि रखने से उसने यह तय किया कि किन अनुरोधों पर समय खर्च करना चाहिए। एक नए मेंटेनर के रूप में, उसने खेद किया कि उसने अपनी परियोजना की दिशा को न अपनाकर अपने पहले विशेषता अनुरोध के लिए [Slate](https://github.com/lord/slate) को मान्यता दी। -