यह लेख कोरियाई में भी उपलब्ध है, डोह्युंग अहन का धन्यवाद!
मेरे एक पहले लेख की टिप्पणियों में थॉम पार्किन ने एक शानदार बात कही:
बहुत अच्छी सलाह। लेकिन आपने एक बहुत महत्वपूर्ण [अंतिम] बिंदु छोड़ दिया। चूंकि यह ओपन सोर्स है, एक बार जब आप उस फीचर/फंक्शन के विवरण का पता लगा लेते हैं जहां दस्तावेज़ीकरण थोड़ा हल्का है, तो आपको दस्तावेज़ अपडेट करने और पुल रिक्वेस्ट सबमिट करना चाहिए। इस तरह पूरा समुदाय लाभान्वित होता है, और आप अपनी भागीदारी के लिए कुछ "कोडर क्रेड" भी प्राप्त कर सकते हैं!
मुझे खुशी है कि थॉम ने इसका जिक्र किया, क्योंकि यह बहुत महत्वपूर्ण है। दस्तावेज़ीकरण ठीक करना उन परियोजनाओं में योगदान देना शुरू करने का सबसे आसान तरीका है जिनका आप उपयोग करते हैं और प्यार करते हैं।
Rails, Rubinius, और Elixir जैसी परियोजनाओं में मेरा पहला योगदान सभी डॉक फिक्स रहे हैं। मैंने चीजों को स्पष्ट करने के लिए छोटे-छोटे बदलाव किए, कुछ चीजों को समझाया जिन्हें आप केवल कोड पढ़कर खोज सकते थे, यहां तक कि सिर्फ टूटे हुए फॉर्मेटिंग को ठीक किया। ये सभी कुछ बड़े ओपन सोर्स प्रोजेक्ट्स की मदद करने के त्वरित, आसान तरीके रहे हैं। यहां तक कि जब वे किसी प्रोजेक्ट में मेरे एकमात्र योगदान रहे हैं, तब भी उन्होंने भविष्य के उपयोगकर्ताओं और भविष्य के मुझे मदद की है। और यही ओपन सोर्स के बारे में है।
दस्तावेज़ीकरण सुधार शुरू करने का इतना शानदार तरीका क्यों हैं
डॉक फिक्स Rails जैसी बड़ी परियोजना में योगदान करने का सबसे कम डराने वाला तरीका है:
बग ठीक करने के लिए आपको प्रोजेक्ट सेट अप करने की आवश्यकता नहीं है। चूंकि आप केवल दस्तावेज़ीकरण अपडेट कर रहे हैं, आपको टेस्ट या ऐप चलाने की आवश्यकता नहीं है। कभी-कभी, आपको प्रोजेक्ट को अपनी मशीन पर क्लोन करने की भी आवश्यकता नहीं होगी - आप GitHub पर ही अपना बदलाव कर सकते हैं!
यदि अनुरक्षक आपसे अपने पुल रिक्वेस्ट में बदलाव करने के लिए कहता है, तो वे आमतौर पर शब्दों या स्वाद की बात होती है। इस तरह के बदलाव आपके कोड की आलोचना की तुलना में पचाने में आसान हो सकते हैं। और उन्हें बनाना आपके लिए आसान है, क्योंकि आपको टेस्ट या कोड अपडेट नहीं करने हैं, सिर्फ शब्द।
दस्तावेज़ीकरण एक प्रोजेक्ट अनुरक्षक के लिए कठिन है, इसलिए अपडेट की सराहना की जाती है। अक्सर, लेखक कोड के बहुत करीब होते हैं ताकि वे समझ सकें कि भ्रमित करने वाले हिस्से कहां हैं। उन्हें अन्य, नए डेवलपर्स की आवश्यकता होती है जो उन्हें बताएं कि डॉक्स को कहां मदद की ज़रूरत है। अपने प्रोजेक्ट को एक शुरुआतकर्ता के रूप में देखना अभ्यास लेता है, और हर किसी ने वह कौशल नहीं बनाया है।
अंत में, आप एक कम-प्रभाव वाले बदलाव के साथ अनुरक्षक के साथ संबंध बनाना शुरू कर रहे हैं। आप प्रोजेक्ट की दिशा नहीं बदल रहे हैं, जैसे आप एक पूरी सुविधा का योगदान करते समय करेंगे। इसलिए आपका बदलाव अनुरक्षक के लिए समीक्षा करना आसान है, और वे आमतौर पर आपसे अधिक तेज़ी से प्रतिक्रिया देंगे। आपका मर्ज रिक्वेस्ट "क्या यह एक अच्छा विचार है?" चरण में अटक नहीं जाएगा।
जैसे-जैसे आप उस रिश्ते को बनाते रहते हैं, आपको एक विश्वसनीय योगदानकर्ता के रूप में देखा जाने लगेगा। आपके पुल रिक्वेस्ट तेजी से समीक्षा किए जाएंगे, और आप दोनों के लिए अधिक जटिल फीचर अनुरोधों और बग फिक्स के माध्यम से बात करना आसान होगा।
वे शुरू करने में आसान हैं, करने में आसान हैं, और तेजी से मर्ज होते हैं। तो आपका पहला योगदान डॉक फिक्स क्यों नहीं होगा?
अपडेटेड दस्तावेज़ीकरण वापस योगदान करना कैसे शुरू करें
डॉक अपडेट में योगदान करना बग ठीक करने की तरह एक महत्वपूर्ण तरीके से है: दोनों उन चीजों के प्रति संवेदनशील होने पर निर्भर करते हैं जो गलत लगती हैं। आपको ध्यान देना होगा।
जब आप उस व्यवहार का सामना करते हैं जिसकी आपने अपेक्षा नहीं की थी, तो यह डॉक्स अपडेट करने का समय हो सकता है। अगर आपको किसी समस्या को हल करने के लिए कोड में गोता लगाना पड़ा, तो आप इसके बारे में अन्य लोगों को बताना भी चाह सकते हैं। आपको जो दस्तावेज़ीकरण पढ़ते हैं उसमें टूटे हुए फॉर्मेटिंग और टाइपो के प्रति भी संवेदनशील होना चाहिए। अगर आप इसे ठीक नहीं करने जा रहे हैं, तो कौन करेगा?
एक बार जब आपको इस बात का अच्छा अंदाजा हो जाए कि कहां बदलाव करना है और आप इसे कैसे शब्दों में कहना चाहते हैं, तो अपना बदलाव करें और GitHub के माध्यम से एक पुल रिक्वेस्ट भेजें।
अगर आप अभी भी डॉक्स को अपडेट करने के सर्वोत्तम तरीके पर निर्णय लेने की कोशिश कर रहे हैं, तो GitHub पर एक इश्यू खोलें। यह ऐसा कुछ हो सकता है:
"अरे, यह मेरे लिए भ्रमित करने वाला था। मैं इसे कुछ इस तरह अपडेट करने की सोच रहा था: ... आप क्या सोचते हैं? कुछ और जो मुझे उल्लेख करना चाहिए?" साथ में, आप ऐसा शब्दांकन लेकर आ सकते हैं जो सभी को संतुष्ट करे।
अंत में, निराश न हों अगर आपको प्रतिक्रिया नहीं मिलती। बड़ी परियोजनाओं में बहुत कुछ चल रहा होता है, इसलिए आपके योगदान का दरार से गिरना आसान है। एक हफ्ते या उसके बाद, अगर आप अभी भी किसी से नहीं सुनते हैं, तो अनुरक्षक से फिर से पूछें।
दस्तावेज़ीकरण अक्सर पहली चीज़ होती है जिसका सामना आप लाइब्रेरी के साथ काम करते समय करते हैं, इसलिए यह महत्वपूर्ण है कि यह विस्तृत और स्पष्ट हो।
तो जब आप अपने द्वारा उपयोग किए जाने वाले कोड के बारे में भ्रमित हों, या स्रोत में गोता लगाना पड़े, तो अगले व्यक्ति के लिए इसे आसान बनाएं। एक त्वरित अपडेट लिखें, और इसे वापस योगदान करें। यह ओपन सोर्स योगदानकर्ता बनने का सबसे आसान तरीका है जिसे मैं जानता हूं।
यह लेख मूल रूप से मेरी सूची के लोगों को भेजा गया था। इस तरह के और लेख पढ़ने के लिए, यहां साइन अप करें!
