Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
275 lines (192 loc) · 29.4 KB

CONTRIBUTING.md

File metadata and controls

275 lines (192 loc) · 29.4 KB
Raw

English • Català • Deutsch • Español • Français • हिंदी • Italiano • Nederlands • Русский

日本語 • 한국어 • Polski • Português (BR) • Türkçe • Tiếng Việt • 简体中文 • 繁體中文

Roo Code में योगदान करें

Roo Code एक समुदाय-आधारित प्रोजेक्ट है और हम हर योगदान को बहुत महत्व देते हैं। सभी के लिए प्रक्रिया को आसान और प्रभावी बनाने के लिए, हम "Issue-First" पद्धति अपनाते हैं। इसका मतलब है कि हर काम को Pull Request सबमिट करने से पहले एक GitHub Issue से जोड़ा जाना चाहिए (विस्तार से जानने के लिए हमारी PR नीति देखें)। कृपया इस गाइड को ध्यान से पढ़ें ताकि आप समझ सकें कि कैसे योगदान करें। यह गाइड बताता है कि Roo Code में कैसे योगदान करें, चाहे आप बग फिक्स कर रहे हों, फीचर जोड़ रहे हों या डाक्यूमेंटेशन सुधार रहे हों।

विषय सूची

I. योगदान करने से पहले

सबसे पहले, हमारे समुदाय मानकों और प्रोजेक्ट की दिशा को समझें।

1. आचार संहिता

सभी योगदानकर्ताओं को हमारे आचार संहिता का पालन करना चाहिए। कृपया योगदान करने से पहले इसे पढ़ें।

2. प्रोजेक्ट रोडमैप समझें

Roo Code के पास एक स्पष्ट विकास रोडमैप है जो हमारी प्राथमिकताओं और भविष्य की दिशा को दर्शाता है। इसे समझने से आपको मदद मिलेगी:

  • अपने योगदान को प्रोजेक्ट के लक्ष्यों के साथ संरेखित करने में
  • उन क्षेत्रों की पहचान करने में जहां आपकी विशेषज्ञता सबसे अधिक उपयोगी हो सकती है
  • कुछ डिज़ाइन निर्णयों के पीछे का संदर्भ समझने में
  • नई विशेषताओं के लिए प्रेरणा पाने में जो हमारे विजन को सपोर्ट करती हैं

हमारा मौजूदा रोडमैप छह मुख्य स्तंभों पर केंद्रित है:

प्रोवाइडर सपोर्ट

हम अधिक से अधिक प्रोवाइडर्स को अच्छे से सपोर्ट करना चाहते हैं:

  • अधिक "OpenAI Compatible" सपोर्ट
  • xAI, Microsoft Azure AI, Alibaba Cloud Qwen, IBM Watsonx, Together AI, DeepInfra, Fireworks AI, Cohere, Perplexity AI, FriendliAI, Replicate
  • Ollama और LM Studio के लिए बेहतर सपोर्ट

मॉडल सपोर्ट

हम चाहते हैं कि Roo अधिक से अधिक मॉडलों (स्थानीय सहित) पर काम करे:

  • कस्टम सिस्टम प्रॉम्प्टिंग और वर्कफ़्लो के जरिए लोकल मॉडल सपोर्ट
  • बेंचमार्किंग, इवैल्स और टेस्ट केस

सिस्टम सपोर्ट

हम चाहते हैं कि Roo हर कंप्यूटर पर अच्छे से चले:

  • क्रॉस-प्लेटफॉर्म टर्मिनल इंटीग्रेशन
  • Mac, Windows और Linux के लिए मजबूत और स्थिर सपोर्ट

डाक्यूमेंटेशन

हम सभी यूजर्स और योगदानकर्ताओं के लिए व्यापक, सुलभ डाक्यूमेंटेशन चाहते हैं:

  • विस्तृत यूजर गाइड्स और ट्यूटोरियल्स
  • स्पष्ट API डाक्यूमेंटेशन
  • बेहतर योगदानकर्ता गाइडेंस
  • बहुभाषी डाक्यूमेंटेशन संसाधन
  • इंटरएक्टिव उदाहरण और कोड सैंपल्स

स्थिरता

हम बग्स की संख्या को काफी कम करना और ऑटोमेटेड टेस्टिंग बढ़ाना चाहते हैं:

  • डिबग लॉगिंग स्विच
  • बग/सपोर्ट अनुरोधों के लिए "मशीन/टास्क जानकारी" कॉपी बटन

अंतरराष्ट्रीयकरण

हम चाहते हैं कि Roo हर किसी की भाषा बोले:

  • 我们希望 Roo Code 说每个人的语言
  • Queremos que Roo Code hable el idioma de todos
  • हम चाहते हैं कि Roo Code हर किसी की भाषा बोले
  • نريد أن يتحدث Roo Code لغة الجميع

हम उन योगदानों का विशेष स्वागत करते हैं जो हमारे रोडमैप लक्ष्यों को आगे बढ़ाते हैं। यदि आप किसी ऐसे काम पर हैं जो इन स्तंभों से मेल खाता है, तो कृपया इसे अपने PR विवरण में उल्लेख करें।

3. Roo Code कम्युनिटी से जुड़ें

Roo Code कम्युनिटी से जुड़ना शुरू करने का एक शानदार तरीका है:

  • मुख्य तरीका:
    1. Roo Code Discord कम्युनिटी से जुड़ें।
    2. जुड़ने के बाद, Hannes Rudolph (Discord: hrudolph) को डायरेक्ट मैसेज (DM) भेजें, अपनी रुचि बताएं और मार्गदर्शन पाएं।
  • अनुभवी योगदानकर्ताओं के लिए विकल्प: यदि आप Issue-First एप्रोच में सहज हैं, तो सीधे GitHub पर Kanban बोर्ड फॉलो करें और Issues व Pull Requests के जरिए संवाद करें।

II. अपना योगदान ढूंढना और योजना बनाना

यह तय करें कि आप क्या करना चाहते हैं और कैसे करेंगे।

1. योगदान के प्रकार

हम कई तरह के योगदान का स्वागत करते हैं:

  • बग फिक्स: मौजूदा कोड में समस्याओं को ठीक करना
  • नई विशेषताएं: नई कार्यक्षमता जोड़ना
  • डाक्यूमेंटेशन: गाइड्स सुधारना, उदाहरण जोड़ना या टाइपो ठीक करना

2. मुख्य सिद्धांत: Issue-First एप्रोच

हर योगदान GitHub Issue से शुरू होना चाहिए। यह कदम संरेखण सुनिश्चित करने और बेकार मेहनत से बचने के लिए जरूरी है।

  • Issue खोजें या बनाएं:
    • शुरू करने से पहले, GitHub Issues में देखें कि आपके योगदान के लिए कोई Issue पहले से है या नहीं।
    • अगर है और असाइन नहीं है, तो उस पर कमेंट करें कि आप इसे लेना चाहते हैं। एक मेंटेनर आपको असाइन करेगा।
    • अगर नहीं है, तो हमारी Issues पेज पर उपयुक्त टेम्पलेट से नया Issue बनाएं:
      • बग के लिए "Bug Report" टेम्पलेट
      • नई विशेषता के लिए "Detailed Feature Proposal" टेम्पलेट। कार्य शुरू करने से पहले मेंटेनर (खासकर @hannesrudolph) की मंजूरी का इंतजार करें।
      • नोट: फीचर के लिए सामान्य विचार या शुरुआती चर्चा GitHub Discussions में शुरू हो सकती है। जब विचार ठोस हो जाए, तो "Detailed Feature Proposal" Issue बनाएं।
  • क्लेम और असाइनमेंट:
    • किसी Issue पर काम करने की इच्छा स्पष्ट रूप से कमेंट करके बताएं।
    • मेंटेनर के GitHub में Issue को औपचारिक रूप से असाइन करने का इंतजार करें। इससे एक ही काम पर कई लोग नहीं लगते।
  • नहीं मानने के परिणाम:
    • बिना संबंधित, पूर्व-अनुमोदित और असाइन किए गए Issue के सबमिट किए गए Pull Requests (PRs) बिना पूरी समीक्षा के बंद किए जा सकते हैं। यह नीति यह सुनिश्चित करने के लिए है कि योगदान प्रोजेक्ट की प्राथमिकताओं के अनुरूप हों और सभी का समय सम्मानित हो।

यह तरीका हमें काम ट्रैक करने, बदलावों की जरूरत सुनिश्चित करने और प्रयासों का समन्वय करने में मदद करता है।

3. क्या काम करें चुनना

  • Good First Issues: हमारे Roo Code Issues प्रोजेक्ट के "Issue [Unassigned]" सेक्शन को देखें।
  • डाक्यूमेंटेशन: यह CONTRIBUTING.md कोड योगदान के लिए मुख्य गाइड है, लेकिन अगर आप अन्य डाक्यूमेंटेशन (जैसे यूजर गाइड या API डाक्यूमेंटेशन) में योगदान करना चाहते हैं, तो Roo Code Docs रिपॉजिटरी देखें या Discord कम्युनिटी में पूछें।
  • नई विशेषताएं प्रस्तावित करना:
    1. प्रारंभिक विचार/चर्चा: सामान्य या शुरुआती फीचर विचारों के लिए GitHub Discussions में चर्चा शुरू करें।
    2. औपचारिक प्रस्ताव: ठोस, लागू करने योग्य फीचर प्रस्तावों के लिए हमारी Issues पेज पर "Detailed Feature Proposal" टेम्पलेट से Issue बनाएं। यह हमारे Issue-First एप्रोच का मुख्य हिस्सा है।

4. बग या समस्या रिपोर्ट करना

अगर आपको कोई बग मिले:

  1. मौजूदा Issues खोजें: GitHub Issues में देखें कि क्या पहले से रिपोर्ट है।
  2. नया Issue बनाएं: अगर यूनिक है, तो हमारी Issues पेज पर "Bug Report" टेम्पलेट का उपयोग करें।

🔐 सुरक्षा कमजोरियां: अगर आप कोई सुरक्षा कमजोरी पाते हैं, तो कृपया GitHub की Security Advisory Tool से निजी तौर पर रिपोर्ट करें। सुरक्षा कमजोरियों के लिए सार्वजनिक Issue न बनाएं।

III. विकास और सबमिशन प्रक्रिया

कोडिंग और सबमिट करने के लिए इन स्टेप्स को फॉलो करें।

1. विकास सेटअप

  1. Fork & Clone:
    • GitHub पर रिपॉजिटरी को फोर्क करें।
    • अपने फोर्क को लोकली क्लोन करें: git clone https://github.com/आपका_यूज़रनेम/Roo-Code.git
  2. डिपेंडेंसी इंस्टॉल करें: npm run install:all
  3. Webview (Dev Mode) चलाएं: npm run dev (Vite/React ऐप के लिए HMR के साथ)
  4. एक्सटेंशन डिबग करें: VS Code में F5 दबाएं (या Run → Start Debugging) ताकि Roo Code के साथ नया Extension Development Host विंडो खुले।

Webview (webview-ui) में बदलाव तुरंत Hot Module Replacement के साथ दिखेंगे। कोर एक्सटेंशन (src) में बदलाव के लिए Extension Development Host को रीस्टार्ट करना होगा।

वैकल्पिक रूप से, .vsix पैकेज बनाने और इंस्टॉल करने के लिए:

npm run build
code --install-extension bin/roo-cline-<version>.vsix

(<version> को बिल्ट फाइल के असली वर्शन नंबर से बदलें।)

2. कोड लिखने के दिशा-निर्देश

  • फोकस्ड PRs: एक फीचर/बग फिक्स प्रति PR।
  • कोड क्वालिटी:
    • CI चेक्स पास करें (लिंटिंग, फॉर्मेटिंग)
    • ESLint वार्निंग्स या एरर ठीक करें (npm run lint)
    • ऑटोमेटेड कोड रिव्यू टूल्स के फीडबैक का जवाब दें
    • TypeScript बेस्ट प्रैक्टिस फॉलो करें और टाइप सेफ्टी बनाए रखें
  • टेस्टिंग:
    • नए फीचर्स के लिए टेस्ट जोड़ें
    • npm test चलाएं ताकि सभी टेस्ट पास हों
    • अगर आपके बदलाव से मौजूदा टेस्ट प्रभावित होते हैं तो उन्हें अपडेट करें
  • कमिट मैसेज:
    • स्पष्ट, वर्णनात्मक कमिट मैसेज लिखें
    • संबंधित Issues को #issue-number (जैसे Fixes #123) से रेफर करें
  • PR सबमिट करने से पहले चेकलिस्ट:
    • अपनी ब्रांच को अपस्ट्रीम के लेटेस्ट main पर रीबेस करें
    • सुनिश्चित करें कि कोड बिल्ड होता है (npm run build)
    • सभी टेस्ट पास हों (npm test)
    • कोई भी डिबगिंग कोड या console.log हटा दें

3. कोड सबमिट करना: Pull Request (PR) प्रक्रिया

ड्राफ्ट Pull Requests

ऐसे काम के लिए ड्राफ्ट PRs का उपयोग करें जो अभी पूरी तरह से रिव्यू के लिए तैयार नहीं है, लेकिन जिसके लिए आप:

  • ऑटोमेटेड चेक्स (CI) चलाना चाहते हैं
  • मेंटेनर्स या अन्य योगदानकर्ताओं से जल्दी फीडबैक पाना चाहते हैं
  • दिखाना चाहते हैं कि काम प्रगति पर है

PR को "Ready for Review" तभी मार्क करें जब सभी चेक्स पास हों और आपको लगे कि यह "कोड लिखने के दिशा-निर्देश" और "Pull Request विवरण" के मानदंडों को पूरा करता है।

Pull Request विवरण

आपके PR का विवरण पूरा होना चाहिए और हमारी Pull Request टेम्पलेट की संरचना का पालन करना चाहिए। मुख्य बिंदु:

  • संबद्ध GitHub Issue का लिंक
  • किए गए बदलावों और उनके उद्देश्य का स्पष्ट विवरण
  • बदलावों को टेस्ट करने के लिए विस्तृत स्टेप्स
  • किसी भी ब्रेकिंग चेंज की सूची
  • UI बदलावों के लिए, पहले और बाद के स्क्रीनशॉट या वीडियो दें
  • जरूरी: बताएं कि क्या आपके PR से यूजर डाक्यूमेंटेशन अपडेट करना जरूरी है और कौन से डॉक्यूमेंट्स या सेक्शन प्रभावित हैं

Pull Request (PR) नीति

उद्देश्य

PR बैकलॉग को साफ, केंद्रित और प्रबंधनीय बनाए रखना।

Issue-First एप्रोच
  • आवश्यक: काम शुरू करने से पहले एक मौजूदा, अनुमोदित और असाइन किया गया GitHub Issue होना चाहिए ("Bug Report" या "Detailed Feature Proposal")।
  • अनुमोदन: Issues, खासकर बड़े बदलावों के लिए, मेंटेनर्स (खासकर @hannesrudolph) द्वारा कोडिंग शुरू करने से पहले रिव्यू और अप्रूव होना चाहिए।
  • संदर्भ: PRs को इन पूर्व-अनुमोदित Issues को अपनी विवरण में स्पष्ट रूप से संदर्भित करना चाहिए।
  • परिणाम: इस प्रक्रिया का पालन न करने पर PR बिना पूरी समीक्षा के बंद किया जा सकता है।
ओपन PR के लिए शर्तें
  • मर्ज के लिए तैयार: सभी CI टेस्ट पास करता है, रोडमैप से मेल खाता है (अगर लागू हो), अनुमोदित और असाइन किए गए Issue से जुड़ा है, स्पष्ट डाक्यूमेंटेशन/कमेंट्स हैं, UI बदलावों के लिए पहले/बाद की इमेज/वीडियो शामिल हैं
  • बंद करने के लिए: CI टेस्ट फेल, बड़े मर्ज कॉन्फ्लिक्ट, प्रोजेक्ट लक्ष्यों से मेल न खाना, या लंबे समय (>30 दिन) तक फीडबैक के बाद कोई अपडेट न होना
प्रक्रिया
  1. Issue क्वालिफिकेशन और असाइनमेंट: @hannesrudolph (या अन्य मेंटेनर्स) नए और मौजूदा Issues की समीक्षा करते हैं और उन्हें असाइन करते हैं।
  2. प्रारंभिक PR ट्रायज (रोजाना): मेंटेनर्स नए PRs की जल्दी समीक्षा करते हैं ताकि जरूरी या गंभीर मुद्दों को छांटा जा सके।
  3. विस्तृत PR रिव्यू (साप्ताहिक): मेंटेनर्स PRs की गहराई से समीक्षा करते हैं ताकि उनकी तैयारी, अनुमोदित Issue से मेल और गुणवत्ता का आकलन किया जा सके।
  4. विस्तृत फीडबैक और पुनरावृत्ति: रिव्यू के आधार पर मेंटेनर्स फीडबैक देते हैं (Approve, Request Changes, या Reject)। योगदानकर्ताओं से अपेक्षा है कि वे फीडबैक का जवाब दें और जरूरत के अनुसार सुधार करें।
  5. निर्णय चरण: अनुमोदित PRs मर्ज किए जाते हैं। जिन PRs में अनसुलझी समस्याएं हैं या जो मेल नहीं खाते, उन्हें स्पष्ट कारण के साथ बंद किया जा सकता है।
  6. फॉलो-अप: बंद किए गए PRs के लेखक फीडबैक के अनुसार सुधार कर सकते हैं और अगर समस्याएं हल हो जाएं या प्रोजेक्ट की दिशा बदल जाए तो नए PRs खोल सकते हैं।
जिम्मेदारियां
  • Issue क्वालिफिकेशन और प्रक्रिया अनुपालन (@hannesrudolph & मेंटेनर्स): सुनिश्चित करें कि सभी योगदान Issue-First एप्रोच का पालन करें। योगदानकर्ताओं को प्रक्रिया में मार्गदर्शन दें।
  • मेंटेनर्स (डेव टीम): PRs की समीक्षा करें, तकनीकी फीडबैक दें, अप्रूवल/रिजेक्शन के फैसले लें, PRs मर्ज करें।
  • योगदानकर्ता: PRs को अनुमोदित और असाइन किए गए Issue से लिंक करें, गुणवत्ता दिशानिर्देशों का पालन करें, फीडबैक का तुरंत जवाब दें।

यह नीति स्पष्टता और कुशल एकीकरण सुनिश्चित करती है।

IV. कानूनी

योगदान समझौता

Pull Request सबमिट करके, आप सहमत होते हैं कि आपके योगदान Apache 2.0 लाइसेंस (या प्रोजेक्ट की मौजूदा लाइसेंस) के तहत होंगे, जैसे कि प्रोजेक्ट है।