सीखें कि कैसे स्पष्ट वर्कफ़्लो, समीक्षा चरण और विश्वसनीय प्रकाशन के साथ समुदाय‑योगदानों का स्वागत करने वाली एक ओपन‑सोर्स प्रोजेक्ट वेबसाइट की योजना बनाएं, बनाएं और रखरखाव करें।
किसी थीम या होमपेज वायर्फ्रेम को चुनने से पहले यह तय करें कि साइट किस लिए है। ओपन‑सोर्स वेबसाइट अक्सर एक साथ सब कुछ करने की कोशिश करती हैं — डॉक पोर्टल, मार्केटिंग पेज, कम्युनिटी हब, ब्लॉग, डोनेशन फ़नल — और किसी में भी अच्छी नहीं रहतीं।
साइट को जिन शीर्ष 1–3 कामों को पूरा करना चाहिए, उन्हें लिखें। आम उदाहरण:
अगर आप साइट का उद्देश्य एक वाक्य में समझा नहीं सकते, तो विज़िटर भी नहीं कर पाएंगे।
मुख्य ऑडियंस की सूची बनाएं और हर समूह के लिए वह “पहला क्लिक” लिखें जो आप चाहते हैं कि वे करें:
एक उपयोगी अभ्यास: हर ऑडियंस के लिए शीर्ष 3 प्रश्न लिखें जिनके साथ वे आते हैं (उदाहरण: “कैसे इंस्टॉल करूँ?”, “क्या यह सक्रिय रूप से मेंटेन्ड है?”, “बग कहाँ रिपोर्ट करूँ?”)।
अपने लक्ष्यों से जुड़ी सरल मीट्रिक चुनें जो ट्रैक करना व्यावहारिक हो:
स्पष्ट रूप से लिखें कि साइट क्या नहीं करेगी (अभी के लिए): कस्टम वेब ऐप्स, जटिल अकाउंट सिस्टम, भारी इंटीग्रेशन या बेस्पोक CMS फीचर। यह मेंटेनर्स के समय की रक्षा करता है और प्रोजेक्ट को शिप करने योग्य बनाता है।
कंटेंट को दो बाल्टियों में बाँटें:
यह एक निर्णय बाद में आपके टूल चयन, समीक्षा वर्कफ़्लो और योगदानकर्ता अनुभव को आकार देगा।
यदि आप यह तय नहीं करते कि साइट पर क्या «होता है» और क्या रिपॉजिटरी में होना चाहिए, तो सामुदायिक वेबसाइट जल्दी गड़बड़ हो जाती है। टूल्स और थीम से पहले, एक सरल संरचना और स्पष्ट कंटेंट मॉडल पर सहमति बनाएं — ताकि योगदानकर्ता जानें कहाँ जोड़ना है और मेंटेनर जानें कैसे समीक्षा करनी है।
प्राइमरी नेविगेशन को जानबूझकर साधारण रखें। ओपन‑सोर्स प्रोजेक्ट वेबसाइट के लिए एक अच्छा डिफ़ॉल्ट साइटमैप:
अगर कोई पेज इनमें से किसी में फिट नहीं बैठता, तो यह संकेत है कि वह या तो रिपॉजिटरी के लिए बेहतर है या उसे अपना कंटेंट टाइप चाहिए।
README को डेवलपर‑फेसिंग अनिवार्यताओं के लिए रखें: बिल्ड निर्देश, लोकल डेव सेटअप, टेस्टिंग और त्वरित प्रोजेक्ट स्थिति। वेबसाइट पर रखें:
यह अलगाव डुप्लिकेशन को रोकता है जो समय के साथ डिफर कर जाता है।
क्षेत्र के हिसाब से कंटेंट ओनर्स असाइन करें (डॉक्स, ब्लॉग/न्यूज़, अनुवाद)। ओनरशिप एक छोटे समूह में हो सकती है जिसमें स्पष्ट समीक्षा जिम्मेवारी हो—एक सिंगल गेटकीपर नहीं।
एक छोटा टोन और स्टाइल गाइड लिखें जो वैश्विक समुदाय के अनुकूल हो: सादा भाषा, सुसंगत शब्दावली और गैर‑मूल अंग्रेज़ी लेखकों के लिए मार्गदर्शन।
यदि आपकी परियोजना रिलीज़ भेजती है, तो पहले से वर्ज़न्ड डॉक की योजना बनाएं (उदा.: “latest” और समर्थित वर्जन)। इसे बाद में बदलना मुश्किल होता है।
आपका स्टैक ऐसा होना चाहिए कि कोई टाइपो ठीक कर सके, नया पेज जोड़ सके या डॉक्स सुधार सके बिना बड़े बिल्ड इंजीनियर बने। अधिकांश ओपन‑सोर्स प्रोजेक्ट्स के लिए इसका मतलब है: Markdown‑फर्स्ट कंटेंट, तेज़ लोकल सेटअप, और स्मूथ PR वर्कफ़्लो के साथ प्रीव्यूज़।
अगर आप लेआउट और नेविगेशन पर जल्दी इटरेट करने की उम्मीद करते हैं, तो लंबे समय के स्टैक पर कमिट करने से पहले साइट एक्सपीरियंस का प्रोटोटाइप बनाना विचार करें। ऐसे प्लेटफ़ॉर्म जैसे Koder.ai मदद कर सकते हैं: चैट के जरिए डॉक/मार्केटिंग साइट स्केच करें, React‑आधारित UI जेनरेट करें और ज़रूरत होने पर बैकएंड के साथ एक्सपोर्ट कर दें—इससे सूचना आर्किटेक्चर और योगदान प्रक्रियाएँ कुछ हफ़्तों की सेटअप न लेकर एक्सप्लोर की जा सकती हैं।
सामान्य विकल्प और इनके लाभ:
mkdocs.yml एडिट करें और एक कमांड चलाएँ। सर्च तेज़ और मजबूत।ऐसी होस्टिंग चुनें जो प्रीव्यू बिल्ड्स का समर्थन करती हो ताकि योगदानकर्ता अपने बदलाव लाइव देख सकें:
यदि संभव हो, डिफ़ॉल्ट पथ बनाएं: “एक PR खोलें, प्रीव्यू लिंक पाएं, समीक्षा माँगें, मर्ज करें।” इससे मेंटेनर का बैक‑एंड‑फोर्थ कम होगा और योगदानकर्ताओं का आत्मविश्वास बढ़ेगा।
एक छोटा docs/website-stack.md (या README.md में सेक्शन) जोड़ें जिसमें लिखा हो कि आपने क्या चुना और क्यों: साइट लोकली कैसे चलाएँ, प्रीव्यू कहाँ दिखते हैं, और किस तरह के परिवर्तन साइट रिपॉजिटरी में होने चाहिए।
एक स्वागतयोग्य रिपॉज़िटरी "ड्राइव‑बाय एडिट्स" और सतत योगदान में फर्क करती है। ऐसी संरचना रखें जो नेविगेट करने में आसान, रिव्यूअर के लिए अनुमानित, और लोकल चलाने में सरल हो।
वेब‑संबंधी फाइलों को समूहबद्ध और स्पष्ट नामित रखें। एक सामान्य उपागम:
/
/website # मार्केटिंग पेज, लैंडिंग, नेविगेशन
/docs # दस्तावेज़ स्रोत (रिफरेंस, गाइड)
/blog # रिलीज नोट्स, घोषणाएँ, कहानियाँ
/static # इमेजेस, आइकन, डाउनलोडेबल असेट्स
/.github # इश्यू टेम्पलेट्स, वर्कफ़्लोज़, CODEOWNERS
README.md # रिपॉजिटरी अवलोकन
अगर आपकी परियोजना में पहले से एप्लिकेशन कोड है, तो साइट को /website (या /site) में रखें ताकि योगदानकर्ता न जानें कहाँ से शुरू करें।
/website में एक फ़ोकस्ड README जोड़ें/website/README.md बनाएं जो जवाब दे: “मैं अपना बदलाव कैसे प्रीव्यू करूँ?” इसे छोटा और कॉपी‑पेस्ट‑फ्रेंडली रखें।
उदाहरण क्विकस्टार्ट (अपने स्टैक के अनुसार समायोजित करें):
# Website quickstart
## Requirements
- Node.js 20+
## Install
npm install
## Run locally
npm run dev
## Build
npm run build
## Lint (optional)
npm run lint
साथ ही प्रमुख फाइलें कहाँ हैं (नेविगेशन, फुटर, रेडायरेक्ट्स) और नया पेज कैसे जोड़ना है, यह बताएं।
टेम्पलेट्स फ़ॉर्मैट विवाद कम करते हैं और रिव्यूज़ तेज़ करते हैं। /templates फ़ोल्डर जोड़ें (या टेम्पलेट्स /docs/CONTRIBUTING.md में दस्तावेज़ करें)।
/templates
docs-page.md
tutorial.md
announcement.md
एक न्यूनतम डॉक पेज टेम्पलेट ऐसा दिख सकता है:
---
title: 'Page title'
description: 'One-sentence summary'
---
## What you’ll learn
## Steps
## Troubleshooting
अगर आपके पास क्षेत्र‑विशेष मेंटेनर्स हैं, तो /.github/CODEOWNERS जोड़ें ताकि सही लोगों से ऑटोमेटिक रिक्वेस्ट हो:
/docs/ @docs-team
/blog/ @community-team
/website/ @web-maintainers
हर टूल के लिए एक canonical कॉन्फ़िग फ़ाइल रखें और “क्यों” बताने वाली छोटी टिप्पणियाँ डालें। लक्ष्य यह है कि नया योगदानकर्ता आत्मविश्वास से मेनू आइटम बदल सके या टाइपो ठीक कर सके बिना पूरे बिल्ड सिस्टम को सीखने के।
वेबसाइट पर योगदान कोडबेस से अलग तरह का होता है: कॉपी एडिट्स, नए उदाहरण, स्क्रीनशॉट, अनुवाद, और छोटे UX ट्वीक। अगर आपकी CONTRIBUTING.md केवल डेवलपर्स के लिए लिखी है, तो आप बहुत सारे संभावित योगदान खो देंगे।
एक CONTRIBUTING.md बनाएं (या अलग करें) जो वेबसाइट बदलावों पर फोकस करे: कंटेंट कहाँ रहता है, पेज कैसे जनरेट होते हैं, और “किया हुआ” क्या दिखता है। एक छोटा "common tasks" टेबल जोड़ें (टाइपो ठीक करें, नया पेज जोड़ें, नेविगेशन अपडेट करें, ब्लॉग पोस्ट प्रकाशित करें) ताकि नए लोग मिनटों में शुरू कर सकें।
यदि आपके पास गहरा मार्गदर्शन है, तो CONTRIBUTING.md से लिंक करें (उदा., /docs के तहत वॉकथ्रू)।
स्पष्ट लिखें कब इश्यू खोलें और कब डायरेक्ट PR भेजें:
एक "good issue template" स्निपेट शामिल करें: पेज URL, क्या बदलना है, क्यों यह पाठकों के लिए मददगार है, और कोई स्रोत।
अधिकांश निराशा चुप्पी से आती है, प्रतिक्रिया से नहीं। परिभाषित करें:
एक हल्का चेकलिस्ट बैक‑एंड‑फोरथ को रोकता है:
एक सामुदायिक वेबसाइट तब स्वस्थ रहती है जब योगदानकर्ताओं को पता होता है कि PR के बाद क्या होगा। लक्ष्य एक ऐसा वर्कफ़्लो बनाना है जो पूर्वानुमेय, कम‑रोक लगाने वाला और सुरक्षित हो।
एक पुल रिक्वेस्ट टेम्पलेट जोड़ें (.github/pull_request_template.md) जो केवल वे सवाल पूछे जो रिव्यूअरों को चाहिए:
यह संरचना रिव्यूज़ को तेज़ करती है और योगदानकर्ताओं को “अच्छा” दिखाना सिखाती है।
प्रीव्यू डिप्लॉयमेंट्स सक्षम करें ताकि रिव्यूअर्स चेंज को वास्तविक साइट पर देख सकें। यह नेविगेशन अपडेट, स्टाइलिंग और टूटे लेआउट के लिये विशेष रूप से मददगार है जो टेक्स्ट डिफ़ में नहीं दिखते।
सामान्य पैटर्न:
हर PR पर हल्के‑फुल्के गेट्स के लिए CI का उपयोग करें:
जल्दी फेल करें, स्पष्ट एरर संदेश दें, ताकि योगदानकर्ता बिना मेंटेनर हस्तक्षेप के ठीक कर सकें।
एक नियम लिखें: जब PR स्वीकृत हो और main में मर्ज हो, साइट ऑटोमेटिक तैनात हो जाती है। कोई मैन्युअल स्टेप्स नहीं, कोई सीक्रेट कमांड नहीं। सटीक व्यवहार /contributing में डालें ताकि अपेक्षाएँ स्पष्ट हों।
अगर आपका प्लेटफ़ॉर्म स्नैपशॉट/रोलबैक सपोर्ट करता है (कुछ होस्ट करते हैं, और Koder.ai भी जब आप उसके माध्यम से डिप्लॉय करते हैं), तो “last known good” बिल्ड कहाँ मिलेगा और कैसे restore करना है, यह दस्तावेज़ करें।
डिप्लॉयमेंट्स कभी‑कभी टूटते हैं। एक छोटा रोलबैक प्लेबुक लिखें:
पेज एक जैसे दिखें तो समुदाय अधिक स्वागतयोग्य महसूस करता है। एक हल्का डिजाइन सिस्टम योगदानकर्ताओं को तेज़ी से काम करने में मदद करता है, समीक्षा विवाद कम करता है, और पाठकों को साइट में ऑरिएंटेड रखता है—भले ही साइट बढ़े।
छोटे सेट के पेज टाइप पर टिके रहें: डॉक पेज, ब्लॉग/न्यूज़ पोस्ट, लैंडिंग पेज, रिफरेंस पेज। हर टाइप के लिए तय करें कि हमेशा क्या दिखेगा (टाइटल, समरी, last updated, टेबल ऑफ कंटेंट्स, फुटर लिंक्स) और क्या कभी नहीं दिखना चाहिए।
नेविगेशन नियम तय करें ताकि स्पष्टता बनी रहे:
sidebar_position या weight)।कॉन्ट्रिब्यूटर्स को “इसे कंसिस्टेंट बनाओ” कहने के बजाय बिल्डिंग ब्लॉक्स दें:
इन कंपोनेंट्स को /docs/style-guide जैसे एक छोटे पेज में डोक्यूमेंट करें जिसमें कॉपी‑पेस्ट उदाहरण हों।
न्यूनतम परिभाषा: लोगो उपयोग (कहाँ न खिंचाना या रंग बदलना है), 2–3 मुख्य रंग जिनका कंट्रास्ट एक्सेसिबिलिटी के अनुकूल हो, और एक‑दो फ़ॉन्ट। लक्ष्य “अच्छा‑काफी” को आसान बनाना है, न कि रचनात्मकता पर कड़ा नियंत्रण रखना।
रिवाइज़ के लिए कन्वेंशन तय करें: फिक्स्ड विड्थ, सुसंगत पैडिंग, और नामकरण जैसे feature-name__settings-dialog.png। आरेखों के स्रोत फाइल्स रखें (उदा., Mermaid या एडिटेबल SVG) ताकि अपडेट करने के लिए डिजाइनर की ज़रूरत न पड़े।
PR टेम्पलेट में छोटा चेक जोड़ें: “क्या पहले से इसी के लिए कोई पेज है?”, “क्या शीर्षक उस सेक्शन से मेल खाता है जिसमें यह है?”, और “क्या यह एक नया टॉप‑लेवल कैटेगरी बना देगा?” इससे कंटेंट स्प्रॉल रोका जाता है और योगदानों को बढ़ावा मिलता है।
एक सामुदायिक वेबसाइट तभी काम करती है जब लोग इसे असिस्टिव टेक्नोलॉजी पर, धीमी कनेक्शन पर और सर्च के जरिए उपयोग कर सकें। एक्सेसिबिलिटी, प्रदर्शन और SEO को डिफ़ॉल्ट माना जाए, न कि बाद में जोड़ा जाने वाला प्रभाव।
सैमान्टिक संरचना से शुरू करें। हेडिंग्स को क्रम में उपयोग करें (पेज पर H1, फिर H2/H3) और बड़े फॉन्ट के लिए लेवल स्किप न करें।
नॉन‑टेक्स्ट कंटेंट के लिए अर्थपूर्ण alt टेक्स्ट चाहिए। नियम: अगर इमेज जानकारी देती है तो उसका वर्णन करें; अगर सिर्फ सजावटी है तो खाली alt (alt="") रखें ताकि स्क्रीन रीडर उसे स्किप कर दे।
रंग कंट्रास्ट और फोकस स्टेट्स को डिज़ाइन टोकन्स में चेक करें ताकि योगदानकर्ताओं को अंदाज़ा न लगाना पड़े। हर इंटरैक्टिव एलिमेंट कीबोर्ड से पहुंच योग्य होनी चाहिए और फोकस मेन्यूज़, डायलॉग या कोड उदाहरणों में फंसना नहीं चाहिए।
डिफ़ॉल्ट रूप से इमेज ऑप्टिमाइज़ करें: डिस्प्ले साइज के अनुसार रिसाइज़ करें, कम्प्रेस करें, और जहाँ बिल्ड सपोर्ट करे मॉडर्न फॉर्मेट पसंद करें। उन पृष्ठों के लिए बड़े क्लाइंट‑साइड बंडल लोड करने से बचें जो ज्यादातर टेक्स्ट हैं।
थर्ड‑पार्टी स्क्रिप्ट्स को न्यून रखें—हर अतिरिक्त विजेट वजन बढ़ाता है और साइट को धीमा कर सकता है।
होस्ट के कैशिंग डिफ़ॉल्ट्स का उपयोग करें (उदा., हैश वाले इम्युटेबल असेट्स)। अगर आपका स्टैटिक साइट जेनरेटर सपोर्ट करता है तो मिनिफाइड CSS/JS जेनरेट करें और केवल वास्तव में आवश्यक क्रिटिकल को इनलाइन रखें।
हर पेज को साफ़ टाइटल और छोटा मेटा विवरण दें जो पेज क्या देता है उसके अनुरूप हो। क्लीन, स्थिर URLs रखें (तिथियाँ तब ही रखें जब मायने रखती हों) और सुसंगत canonical paths उपयोग करें।
साइटमैप जनरेट करें और सार्वजनिक डॉक्स के इंडेक्सिंग की अनुमति देने वाला robots.txt रखें। कई वर्जन के डॉक्स प्रकाशित करते समय duplicate content से बचने के लिए एक वर्जन को “current” बनाएं और दूसरों को स्पष्ट रूप से लिंक करें।
केवल तभी एनालिटिक्स जोड़ें जब आप उस डेटा पर कार्रवाई करेंगे। अगर जोड़ते हैं तो /privacy जैसी समर्पित पेज पर बताएं कि क्या कलेक्ट किया जाता है, क्यों, और कैसे ऑप्ट‑आउट करें।
अंत में, वेबसाइट कंटेंट के लिए स्पष्ट लाइसेंस नोटिस डालें (अगर आवश्यक हो तो कोड लाइसेंस से अलग)। इसे फुटर और रिपॉजिटरी README में रखें ताकि योगदानकर्ता जान सकें कि उनके टेक्स्ट और इमेजेज़ का पुन: उपयोग कैसे किया जा सकता है।
आपकी वेबसाइट के कोर पेज नए योगदानकर्ताओं के लिए “फ्रंट डेस्क” हैं। अगर वे साफ़‑साफ़ जवाब देते हैं—प्रोजेक्ट क्या है, इसे कैसे आज़माएँ, और मदद कहाँ चाहिए—तो लोग जिज्ञासा से कार्रवाई की ओर बढ़ेंगे।
एक सादा भाषा में ओवरव्यू पेज बनाएं जो बताये कि प्रोजेक्ट क्या करता है, किसके लिए है, और सफलता कैसी दिखती है। कुछ ठोस उदाहरण और “क्या यह आपके लिए है?” सेक्शन शामिल करें।
फिर एक Quickstart पेज जोड़ें जो मोमेंटम के लिए ऑप्टिमाइज़्ड हो: पहले सफल रन के लिए एक पाथ, कॉपी‑पेस्ट कमांड्स और एक छोटा ट्रबलशूटिंग ब्लॉक। अगर सेटअप प्लेटफ़ॉर्म अनुसार बदलता है, तो मुख्य पाथ संक्षिप्त रखें और विस्तृत गाइड्स के लिंक दें।
सुझाए गए पेज:
एकल /contribute पेज होना चाहिए जो बताए:
/docs/contributing)इसे विशिष्ट रखें: 3–5 काम नामित करें जिन्हें आप इस महीने वास्तव में चाहते हैं, और सटीक इश्यू(ज़) के लिंक दें।
मौलिक चीज़ें प्रमुख पेज पर प्रकाशित करें, रिपॉजिटरी में गहरे छुपी हुई नहीं:
/community/meetings)/changelog (या /releases) जोड़ें जिसमें सुसंगत फॉर्मैट हो: तिथि, हाइलाइट्स, अपग्रेड नोट्स, और PRs/इश्यूज़ के लिंक। टेम्पलेट मेंटेनर के समय को घटाते हैं और कम्युनिटी‑लिखित नोट्स को आसान बनाते हैं।
एक शोकेस पेज योगदान प्रेरित कर सकता है, पर पुरानी सूचियाँ विश्वसनीयता घटाती हैं। अगर आप /community/showcase जोड़ते हैं, तो एक हल्का नियम रखें (उदा., “त्रैमासिक समीक्षा”) और सबमिशन के लिए छोटा फॉर्म या PR टेम्पलेट दें।
एक समुदाय साइट तब हेल्दी रहती है जब अपडेट आसान, सुरक्षित और पुरस्कृत हों—यहाँ तक कि पहले‑बार योगदानकर्ताओं के लिए भी। आपका लक्ष्य "कहाँ क्लिक करें?" घर्षण को कम करना और छोटे सुधारों को सार्थक बनाना है।
डॉक्स, गाइड और FAQ पर एक स्पष्ट “Edit this page” लिंक जोड़ें। इसे सीधे रिपॉजिटरी की फ़ाइल पर पॉइंट करें ताकि यह मिनिमल स्टेप्स के साथ PR फ्लो खोल दे।
लिंक टेक्स्ट मैत्रीपूर्ण रखें (उदा., “टाइपो ठीक करें” या “इस पेज को सुधारें”) और सामग्री के शीर्ष या अंत में रखें। अगर आपके पास CONTRIBUTING गाइड है तो वहाँ भी लिंक करें (उदा., /contributing)।
लोकलाइज़ेशन तब सबसे अच्छा काम करता है जब फ़ोल्डर लेआउट एक नज़र में सवालों का जवाब दे। सामान्य उपागम:
समीक्षा चरणों को दस्तावेज़ करें: कौन अनुवाद को मंज़ूर कर सकता है, आंशिक अनुवादों को कैसे हैंडल करना है, और क्या पुराना हो गया यह कैसे ट्रैक करेंगे। जब अनुवाद स्रोत भाषा से पीछे हों तो शीर्ष पर छोटा नोट जोड़ने पर विचार करें।
अगर आपकी परियोजना रिलीज़ करती है, तो उपयोगकर्ताओं को स्पष्ट बताएं कि क्या पढ़ना चाहिए:
पूर्ण डॉक वर्ज़निंग न होने पर भी, एक छोटा बैनर या सेलेक्टर जो अंतर समझाए, भ्रम कम करता है और सपोर्ट लोड घटाता है।
FAQ को उसी कंटेंट सिस्टम में रखें जैसे डॉक्स (इश्यू टिप्पणियों में नहीं)। इसे प्रमुखता से /docs/faq पर लिंक करें और लोगों को समस्या आने पर सुधार करने के लिए प्रोत्साहित करें।
अस्पष्ट विजिताएँ (typo fixes, स्पष्ट उदाहरण, अपडेटेड स्क्रीनशॉट, "यह मेरे लिए काम किया" नोट्स) के लिये साफ़‑साफ़ निमंत्रण दें। ये नए योगदानकर्ताओं के लिए बेहतरीन प्रवेश बिंदु होते हैं—और सतत रूप से साइट में सुधार करते हैं।
यदि आप लेखन और रखरखाव के लिए प्रोत्साहन देना चाहते हैं, तो पारदर्शी रहें कि आप क्या पुरस्कृत करेंगे और क्यों। उदाहरण के लिए, कुछ टीम्स छोटे स्पॉन्सरशिप या क्रेडिट देती हैं; Koder.ai का "earn credits" प्रोग्राम प्रेरणा के रूप में अनुकूलित किया जा सकता है।
एक सामुदायिक साइट स्वागतयोग्य लगनी चाहिए—पर कुछ लोगों के लिए अनंत सफाई के कारण नहीं। लक्ष्य रखरखाव को पूर्वानुमेय, हल्का और साझा करने योग्य बनाना है।
एक ऐसी कैडेंस चुनें जिसे लोग याद रख सकें और जहाँ संभव हो ऑटोमेशन करें।
यदि आप इस शेड्यूल को /CONTRIBUTING.md में दस्तावेज़ करते हैं और संक्षिप्त रखते हैं, तो अन्य लोग आत्मविश्वास से कदम उठा सकेंगे।
कंटेंट संघर्ष सामान्य हैं: टोन, नामकरण, होमपेज पर क्या रहे, या क्या ब्लॉग पोस्ट "आधिकारिक" है। लंबी बहस से बचने के लिए लिखें:
यह नियंत्रण के बारे में नहीं, बल्कि स्पष्टता के बारे में है।
कैलेंडर भरा होना ज़रूरी नहीं। एक साधारण इश्यू (या एक साधारण markdown फ़ाइल) बनाएं जिसमें आने वाले आइटम हों:
इसे ब्लॉग/न्यूज़ प्लानिंग नोट्स से लिंक करें ताकि योगदानकर्ता स्वयं-आवंटित कर सकें।
दोहराए जाने वाले वेबसाइट इश्यूज़ (टाइपो, आउटडेटेड स्क्रीनशॉट, मिसिंग लिंक्स, एक्सेसिबिलिटी फिक्स) को "good first issue" लेबल दें और स्पष्ट स्वीकार्यता मानदंड रखें जैसे "एक पेज अपडेट + फॉर्मैटर चलाएँ + रिज़ल्ट का स्क्रीनशॉट"।
डॉक्स में एक छोटा "Common local setup issues" सेक्शन रखें। उदाहरण:
# clean install
rm -rf node_modules
npm ci
npm run dev
साथ ही ऊपर के 2–3 सामान्य ग़लतियाँ बताएं (गलत Node वर्जन, गायब Ruby/Python डिपेंडेंसी, पोर्ट पहले से उपयोग में होना)। इससे बैक‑एंड‑फोरथ कम होता है और मेंटेनर की ऊर्जा बचती है।
एक वाक्य में उद्देश्य लिखें, फिर साइट के शीर्ष 1–3 कामों की सूची बनाएं (उदाहरण के लिए: डॉक्स, डाउनलोड, समुदाय, अपडेट)। अगर कोई पेज या फीचर उन कामों का समर्थन नहीं करता है, तो अभी के लिए उसे नॉन-गोал मानें।
एक सरल जांच: अगर आप साइट का उद्देश्य एक वाक्य में नहीं बता सकते, तो विज़िटर भी नहीं बता पाएंगे।
अपनी मुख्य ऑडियंस की सूची बनाएं और हर समूह के लिए वह “पहला क्लिक” तय करें जो आप चाहते हैं:
हर ऑडियंस के लिए उनके शीर्ष 3 प्रश्न लिखें (जैसे “क्या यह सक्रिय रूप से मेंटेन्ड है?”, “बग कहाँ रिपोर्ट करूं?”) और सुनिश्चित करें कि नेविगेशन उन प्रश्नों का जल्दी जवाब दे।
लोगों के सोचने के तरीके से मेल खाने वाला एक साधारण, ‘जानबूझकर उबाऊ’ साइटमैप शुरू करें:
अगर नया कंटेंट इनमें फिट नहीं बैठता, तो यह संकेत है कि या तो आपको नया कंटेंट टाइप बनाना चाहिए (अकसर नहीं) या जानकारी रिपॉजिटरी में बेहतर रहती है।
README में डेवलपर-फेसिंग आवश्यकताएँ रखें और वेबसाइट पर पब्लिक-फेसिंग ऑनबोर्डिंग रखें।
README के लिए:
वेबसाइट के लिए:
वो स्टैक चुनें जो “Markdown-first” संपादन और त्वरित लोकल प्रीव्यू सपोर्ट करता हो.
सामान्य विकल्प:
आज की जरूरतों के लिए सबसे सरल उपकरण चुनें, न कि भविष्य की हर आवश्यकता के लिए सबसे लचीला।
डिफ़ॉल्ट मार्ग बनाएं: PR → preview → review → merge.
व्यवहारिक तरीका:
main deploys”)इससे रिव्यूअर और योगदानकर्ता दोनों को भरोसा मिलेगा कि बदलाव कैसा दिखेगा।
रचना और टेम्प्लेट से फ़ॉर्मैट विवाद कम करें।
सहायक बुनियादी बातें:
इसे “वेबसाइट-फर्स्ट” रखें और विशिष्ट बनाएं।
शामिल करें:
इसे इतना छोटा रखें कि लोग वास्तव में पढ़ें—और गहराई के लिए लिंक दें।
इन्हें डिफ़ॉल्ट समझें, न कि बाद की खूबसूरती:
alt=""जहां संभव हो ऑटोमेटेड चेक जोड़ें (लिंक चेकर, Markdown lint, फॉर्मैटर) ताकि रिव्यूअर मैनुअल काम न करें।
अपडेट को आसान और रखरखाव को पूर्वानुमेय बनाएं।
समुदाय अपडेट के लिए:
/docs/faq)/docs/en/..., /docs/es/...मेंटेनर टिकाऊपन के लिए:
यह डुप्लिकेट कंटेंट को रोकता है जो समय के साथ अलग हो जाता है।
/website, /docs, /blog, /.github/website/README.md जिसमें लोकल चलाने के कॉपी-पेस्ट कमांड हों/templates फ़ोल्डर (docs page, tutorial, announcement)CODEOWNERS ताकि रिव्यू क्षेत्र अनुसार जाएलक्ष्य यह है कि कोई व्यक्ति टाइपो ठीक कर सके या पेज जोड़ सके बिना बिल्ड एक्सपर्ट बने।
/privacy पर स्पष्ट विवरण दें