ओपन‑सोर्स मिलियनेयर बनें*
3सरल चरणों में…
केवल 3 सरल चरणों में मैं आपको दिखाऊँगा कि कैसे आपके हालिया कोडिंग को सार्थक PR में बदला जाए!
- दान में डुबकी? 💰
- रिपोज़ में रफ़्तार? 🏎️
- Robb Report को रीबेस कर रहे हैं? 🤯
चलो शुरू करें!!!!!
अस्वीकरण: सफलता के लिए वर्षों का समर्पण और भाग्य आवश्यक हो सकता है।
वास्तविकता
हम सभीने यह सुना है कि ओपन सोर्स में contribute करना कितना फायदेमंद है। लेकिन, शुरुआत करना हमेशा आसान नहीं होता।
अपने करियर में, मैंने कई 10,000‑स्टार रिपॉज़िटरीज़ के लिए कई PR लिखे हैं। मेरे modest योगदान Node.js, Docker, Lodash, Bluebird, Gatsby, Rancher, Angular, React Router, Minio, MDN (Mozilla Developer Network) और कई अन्य में शामिल हो चुके हैं।
मैं आपको आसान योगदान का अपना रहस्य बताने वाला हूँ, लेकिन पहले हमें पारंपरिक सलाह की समस्याओं पर संक्षेप में चर्चा करनी होगी।
यह (नहीं) तरीका है
ओपन सोर्स में contribute करना क्यों कठिन लगता है?
सबसे आम सलाह वास्तव में बेकार और ख़राब के बीच कहीं पड़ती है: एक GFI इश्यू (Good First Issue लेबल) खोजें और उसे हल करें। या, सिर्फ़ प्यार के कारण किसी प्रोजेक्ट में योगदान दें।
यह सब अच्छी नीयत से किया जाता है, लेकिन वास्तविकता में GFI लेबल बहुत ही व्यक्तिपरक होते हैं, और अक्सर आश्चर्यजनक मात्रा में काम की माँग करते हैं।
अगर मैं कहूँ कि सबसे अच्छा स्थान वह समाधान हैं जो आपने पहले ही खोजे हैं?
एक बेहतर तरीका
✅ अपने प्रोजेक्ट की डिपेंडेंसी फ़ाइल(ओं) को स्कैन करें। कौन‑सी लाइब्रेरीज़ ने गुस्सा दिलाया? किस कारण से डेडलाइन छूट गई? आपने इसे कैसे हल किया?
💪 पहले से हल की गई चीज़ से शुरू करके, आपको यह सोचने की ज़रूरत नहीं कि क्या आप कर सकते हैं। आप पहले से ही परिप्रेक्ष्य में निपुण और परिचित हैं!
चूँकि आपने वह समस्या पहले ही हल कर ली है, अधिकांश काम हो चुका है। अब आपको यह तय करना है कि दूसरों को आपकी कठिनाई से पूरी तरह बचने में कैसे मदद करें।
शायद एक ट्वीट या Stack Overflow उत्तर से काम चल जाए, लेकिन अगर आप दीर्घकालिक प्रभाव चाहते हैं, तो contribute सीधे प्रोजेक्ट में करें।
द ब्रेनस्टॉर्म
जब अनुभव अभी भी थोड़ा ताज़ा हो, तो सोचें कि आपका dumb dumb दिमाग पहले क्यों भटक गया।
आपने सबसे पहले क्या आज़माया? और क्यों? आपने क्या मान लिया? या कहाँ गलत समझा?
💪 आपको परफेक्ट समाधान निकालने की ज़रूरत नहीं है, अक्सर README या दस्तावेज़ में छोटे‑छोटे अपडेट दूसरों को अनगिनत घंटे की झंझट से बचा सकते हैं।
- पुराना README? मिसिंग या ख़राब उदाहरण? सेटअप स्टेप्स छूट गए? सादा समाधान, कोई भी छूटी जानकारी जोड़ें!
- API दस्तावेज़ आपके Google परिणामों में नहीं दिख रहा था। बहुत तकनीकी भाषा को समायोजित या अनुवाद करें।
- शायद यह तकनीकी चूक है, और docs साइट में आवश्यक
<meta/>टैग नहीं हैं। अगर आप जानते हैं तो ठीक करें, या अपनी खोजों के साथ एक टिकट लिखें। - अगर यह स्किल इश्यू है… उन स्किल्स पर काम करें!
इन प्रकारकी समस्याओं को मेंटेनर अक्सर नजरअंदाज़ कर देते हैं! और यह प्रोजेक्ट तथा उसके उपयोगकर्ताओं पर आश्चर्यजनक रूप से बड़ा असर डाल सकती हैं।
अगली बार जब आप कोई चुनौती जीतें, अपने निराशाजनक हैक्स को रीबेस करके न हटाएँ! बल्कि अपनी कठिनाई पर विचार करें और अपना समाधान सार्वजनिक रूप से साझा करें!
Fine, Fine Print
हमेशा प्रोजेक्ट के दिशानिर्देशों का पालन करें, और कभी भी असभ्य न बनें। ✨
सब कुछ सार्वजनिक है। इसलिए, विनम्र, उत्कृष्ट और आभारी रहें।
यदि आपको और प्रेरणा चाहिए: contribute सीखने के लिए! नई प्रक्रियाएँ, भाषाएँ, फ्रेमवर्क, ऑटोमेशन!
🚀
यदि आपको यह उपयोगी लगा, तो कृपया अपने योगदान टिप्पणियों में साझा करें या उन्हें ट्विटर पर पोस्ट करें और मुझे टैग करें @justsml पर डालें।