From 4652954fbe844421ea1520951a5c11392cabd11b Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Mon, 18 Mar 2024 20:15:11 +0530 Subject: [PATCH 1/8] translation: init for steward guidelines --- contributor_docs/hi/steward_guidelines.md | 342 ++++++++++++++++++++++ 1 file changed, 342 insertions(+) create mode 100644 contributor_docs/hi/steward_guidelines.md diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md new file mode 100644 index 0000000000..fd35f1e7af --- /dev/null +++ b/contributor_docs/hi/steward_guidelines.md @@ -0,0 +1,342 @@ +# स्टीवर्ड दिशानिर्देश + +चाहे आप हाल ही में हमारे साथ स्टीवर्ड के रूप में शामिल हुए हों, p5.js के अनुभवी रखरखावकर्ता हों, या कहीं बीच में हों, यह गाइड जानकारी के साथ-साथ उन सुझावों और ट्रिक्स को शामिल करता है जो आपको p5.js में प्रभावी योगदान देने में मदद करेगा। यहां लिखा गया अधिकांश दिशानिर्देश हैं, अगर कुछ और नहीं बताया गया है, तो इसका अर्थ है कि आप यहां दिखाए गए अभ्यासों को अपने काम के लिए अनुकूल बना सकते हैं। + +## विषय सूची + +- [Issues](steward_guidelines.md#issues) + - [Bug report](steward_guidelines.md#bug-report) + - [Feature request](steward_guidelines.md#feature-request) + - [Feature enhancement](steward_guidelines.md#feature-enhancement) + - [Discussion](steward_guidelines.md#discussion) +- [Pull Requests](steward_guidelines.md#pull-requests) + - [Simple fix](steward_guidelines.md#simple-fix) + - [Bug fix](steward_guidelines.md#bug-fix) + - [New feature/feature enhancement](steward_guidelines.md#new-feature-feature-enhancement) + - [Dependabot](steward_guidelines.md#dependabot) +- [Build Process](steward_guidelines.md#build-process) + - [Main build task](steward_guidelines.md#main-build-task) + - [Miscellaneous tasks](steward_guidelines.md#miscellaneous-tasks) +- [Release Process](steward_guidelines.md#release-process) +- [Tips & Tricks](steward_guidelines.md#tips--tricks) + - [Reply templates](steward_guidelines.md#reply-templates) + - [GitHub CLI](steward_guidelines.md#github-cli) + - [Managing notifications](steward_guidelines.md#managing-notifications) + +--- + +## समस्याएँ + +हम अधिकांश स्रोत कोड योगदानों को एक समस्या के साथ शुरू करने की प्रोत्साहना करते हैं, और इस तरह, समस्याओं में अधिकांश चर्चाएँ होंगी। समस्या को समीक्षा करने के लिए लेने के चरण वास्तव में यह निर्भर करेगा कि यह कैसी समस्या है। रेपो विभिन्न प्रकार की समस्याओं को बेहतर ढंग से व्यवस्थित करने और समस्या लेखकों को अपनी समस्याओं के बारे में सभी प्रासंगिक जानकारी प्रदान करने के लिए [गिटहब समस्या टेम्पलेट](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) का उपयोग करता है। समस्या की समीक्षा की पहली कदम अक्सर भरे गए टेम्पलेट को देखना होगा और यह तय करना होगा कि क्या आपको अतिरिक्त जानकारी की आवश्यकता है (जैसे कि कुछ क्षेत्र भरे नहीं गए हों या गलत टेम्पलेट का प्रयोग किया गया हो)। + +### बग रिपोर्ट + +Bबग रिपोर्ट समस्याओं को "बग मिला" (Found a bug) समस्या टेम्पलेट का प्रयोग करना चाहिए। बग रिपोर्ट को समाधान करने के लिए निम्नलिखित कार्यक्रम सामान्य होता है: + +1. बग को अनुकृत करें + - टेम्पलेट का उद्देश्य एक समीक्षक को समस्या को श्रद्धापूर्वक प्रयास करने के लिए पर्याप्त जानकारी प्रदान करना है। + - यदि रिपोर्ट की गई समस्या प्राथमिकता सूची में नहीं है (p5.js, p5.js-वेबसाइट, या अन्यत्र): + - यदि आपके पास इसका उपयोगकर्ता है, तो बग रिपोर्ट को संबंधित रेपो में स्थानांतरित करें। + - अन्यथा, एक टिप्पणी छोड़ें जिसमें बग रिपोर्ट को कहां फाइल किया जाना चाहिए (सीधा लिंक सहित) और समस्या को बंद करें। + - बग रिपोर्ट का समीक्षा करने का पहला कदम यह है कि क्या एक बग प्रतिरूपण के लिए पर्याप्त जानकारी प्रदान की गई है, और यदि हां, तो समान रूप से बग को जैसा वर्णित किया गया है उसी रूप में प्रतिरूपित करने का प्रयास करें। +2. अगर बग प्रतिरूपित किया जा सकता है: + - किसी विशेष बग को सही करने का सबसे अच्छा तरीका निर्धारित करने के लिए कुछ चर्चा की जा सकती है। कभी-कभी, यह सीधा हो सकता है; कभी-कभी, यह कठिन हो सकता है। कृपया इस निर्णय को एक मामला-दर-मामला आधार पर लेते समय [p5.js' डिज़ाइन सिद्धांतों](design_principles.md) का उल्लेख करें। + - यदि समस्या लेखक ने समस्या में इस संकेत किया है कि वे एक सुधार योगदान देने के लिए तत्पर हैं: + - कॉमेंट छोड़कर समस्या को सुधारने के लिए समस्या लेखक को स्वीकृत करें और उन्हें समस्या के लिए असाइन करें। "असाइनी" के बगल में "टोलिया" का उपयोग करें। + - यदि समस्या लेखक कोई सुधार नहीं करना चाहते हैं: + - बग प्रतिरूपित होने का स्वीकृति छोड़ें। + - खुद को सुधारने का प्रयास करें या बग को ठीक करने की आवश्यकता होने पर मदद की जरूरत के लिए `मदद चाहिए (help wanted)` लेबल जोड़ें। +3. यदि बग प्रतिरूपित नहीं हो सकता है: + - अतिरिक्त जानकारी के लिए पूछें यदि पहले से ही टेम्पलेट में नहीं शामिल किया गया है (p5.js संस्करण, ब्राउज़र संस्करण, ओएस संस्करण आदि)। + - यदि आपका परीक्षण पर्याप्त नहीं है जो समस्या में रिपोर्ट किया गया है (उदाहरण के लिए, एक अलग ब्राउज़र या ओएस): + - एक टिप्पणी छोड़ें कि आप अपने विशिष्ट पर्यावरण में प्रतिरूपित नहीं कर सकते हैं। + - बग को प्रतिरूपित करने के लिए `मदद चाहिए (help wanted)` लेबल जोड़ें और समस्या को जिन निर्दिष्ट सेटअप के साथ प्रतिरूपित किया गया है, उनसे बग को प्रतिरूपित करने के लिए कहें। + - कभी-कभी, बग केवल वेब संपादक का उपयोग करते समय ही होते हैं और स्थानीय टेस्ट करते समय नहीं। इस मामले में, समस्या को [वेब संपादक रेपो](https://github.com/processing/p5.js-web-editor) की ओर पुनर्निर्देशित किया जाना चाहिए। + - यदि प्रतिरूपण बाद में संभव है, तो कदम 2 पर वापस जाएं। +4. यदि बग उपयोगकर्ता द्वारा प्रदान किए गए कोड से आता है और p5.js' व्यवहार नहीं: + - यह निर्धारित करें कि क्या p5.js' दस्तावेज़ीकरण, कोड कार्यान्वयन, या मित्रसंपर्क त्रुटि प्रणाली को सुधारा जा सकता है ताकि वही गलती फिर से न हो। + - कृपया आगे किसी भी परिवर्तन के लिए [मंच](https://discourse.processing.org/) या [डिस्कॉर्ड](https://discord.com/invite/SHQ8dH25r9) पर और अधिक प्रश्न अद्यतन करें और यदि p5.js में कोई अधिक परिवर्तन नहीं करना है, तो समस्या को बंद करें। + +### सुविधा अनुरोध + +सुविधा अनुरोध समस्याएँ "नई सुविधा अनुरोध" समस्या टेम्पलेट का उपयोग करना चाहिए। सुविधा अनुरोध को सम्बोधित करने के लिए निम्नलिखित वर्कफ़्लो सामान्य है: + +1. p5.js की पहुंच बढ़ाने के रूप में, सुविधा अनुरोध को यह साबित करना होगा कि यह प्रोजेक्ट कैसे p5.js के इतिहास में तब भी समुदायों के लिए पहुंच को बढ़ाता है जब वे इस क्षेत्र में नाज़िम किए गए हैं। अधिक विवरण [यहां](access.md) उपलब्ध हैं। + - यदि कोई सुविधा अनुरोध "पहुंच बढ़ाने" क्षेत्र को पर्याप्त रूप से भरा नहीं है, तो आप समस्या लेखक से सुविधा कैसे पहुंच बढ़ाती है, इसके बारे में पूछ सकते हैं। + - सुविधा का पहुंच का बयान किसी अलग समुदाय सदस्य, समस्या समीक्षकों सहित, द्वारा प्रदान किया जा सकता है। +2. नई सुविधा अनुरोध को निम्नलिखित मानकों के आधार पर समाविष्टि के लिए मूल्यांकन किया जा सकता है। + - क्या सुविधा परियोजना के धारा और [डिज़ाइन सिद्धांतों](design_principles.md) में फिट है? + - उदाहरण के लिए, एक नई आकृति जोड़ने का अनुरोध किया जा सकता है, लेकिन ब्राउज़र-आधारित आईओटी प्रोटोकॉल को ग्रहण करने का अनुरोध असंगत होगा। + - सम्पूर्ण रूप से, p5.js का धारा संक्षिप्त होना चाहिए ताकि अनियमित उपयोग की सुविधाओं से बचा जा सके। + - यदि कोई सुविधा p5.js के धारा में फिट नहीं होती है, तो सुझाव दें कि समस्या लेखक सुविधा को एक ऐड-ऑन पुस्तकालय के रूप में अमल करें। + - यदि स्पष्ट नहीं है कि यह फिट है या नहीं, तो एक प्रमाण-प्रतिसाद के रूप में एक ऐड-ऑन पुस्तकालय बनाने का सुझाव देना एक अच्छा विचार हो सकता है। यह प्रयोक्ताओं को सुविधा का उपयोग करने का एक तरीका देता है, इसका उपयोग और महत्ता का एक अधिक स्पष्ट उदाहरण प्रदान करता है, और पूरी तरह से एक स्थायी समाधान की तरह पूरा नहीं होना चाहिए। यह परियोजना की मूल धारा में बाद में शामिल किया जा सकता है। + - Is the feature likely to cause a breaking change? + - Will it conflict with existing p5.js functions and variables? + - Will it conflict with typical sketches already written for p5.js? + - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। + - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? + - For example, instead of providing a p5.js function to join an array of strings such as `join(["Hello", "world!"])`, the native JavaScript `["Hello", "world!"].join()` should be preferred instead. +3. यदि पहुँच आवश्यकता और अन्य विचारों को पूरा किया गया है, तो नई सुविधा अनुरोध को प्रारंभ किया जाना चाहिए जब तक कि कार्य पीआर की ओर न हो। नई सुविधाओं के पीआर की समीक्षा प्रक्रिया नीचे विवरणित है। + +### सुविधा विस्तार + +सुविधा विस्तार समस्याओं का उपयोग करना चाहिए "मौजूदा सुविधा विस्तार" समस्या टेम्प्लेट का। प्रक्रिया नई सुविधा अनुरोधों के साथ बहुत समान है। नई सुविधा अनुरोध और सुविधा विस्तार के बीच का अंतर कभी-कभी कम हो सकता है। सुविधा विस्तार मुख्य रूप से p5.js के मौजूदा कार्यों के साथ संबंधित होता है जबकि नई सुविधा अनुरोध पूरी तरह से नए कार्यों को जोड़ने का अनुरोध कर सकता है। + +1. नई सुविधा अनुरोधों की तरह, सुविधा विस्तार को केवल उन्हें स्वीकार किया जाना चाहिए अगर वे p5.js के पहुँच को बढ़ाते हैं। कृपया [ऊपर दिए गए खंड](./steward_guidelines.md/#सुविधा-अनुरोध) का बिंदु 1 देखें। +2. सुविधा विस्तारों के समावेश की मान्यता देने की मानदंड नए सुविधा अनुरोधों के लिए तुलनात्मक होती हैं, लेकिन भिन्नता तब की जाती है जब संभावित ब्रेकिंग बदलावों पर विशेष ध्यान दिया जाता है। + +- मौजूदा कार्यों को संशोधित करते समय, सभी पिछले मान्य और दस्तावेजित कार्य साकार तरीके से बर्ताव करने चाहिए। + +3. सुविधा विस्तारों को कम से कम एक स्टीवर्ड या मेंटेनर द्वारा मंजूर किया जान| चाहिए जब काम की ओर प्रीआर किया जाना चाहिए। सुविधा विस्तार के लिए पीआर समीक्षा प्रक्रिया नीचे विवरणित है। + +### चर्चा + +इस प्रकार की समस्या के पास एक न्यूनतम टेम्प्लेट ("चर्चा" (discussion)) होता है और इसका उपयोग विषय के चारों ओर संवाद जमा करने के लिए किया जाना चाहिए, जो बाद में किसी विशेष मुद्दे में एकत्रित किया जाता है, जैसे कि एक सुविधा अनुरोध। इन प्रकार की चर्चा समस्याओं को समाप्त होने पर बंद किया जा सकता है और परिणामी अधिक विशिष्ट समस्याएं बना दी गई हैं: + +- If an issue is opened as a discussion but should be, for example, a bug report, the correct label should be applied and the "discussion" label removed. Additional info about the bug should also be requested from the author if not already included. +- If an issue is opened as a discussion but isn't relevant to source code contribution or otherwise relevant to the GitHub repositories/contribution process/contribution community, they should be redirected to the forum or Discord and the issue closed. +- यदि लागू हो, तो चर्चा इस्स्यूज के लिए अतिरिक्त लेबल जोड़े जा सकते हैं ताकि एक नजर में यह देखा जा सके कि यह किस प्रकार की चर्चा है। + +--- + +## पुल रिक्वेस्ट + +प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। स्टीवर्ड और मेंटेनर्स रिपॉजिट्रीज के पुश एक्सेस रख सकते हैं लेकिन जब भी कोड योगदान किया जाता है, तो वे पुल रिक्वेस्ट की समीक्षा करने को प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: + +- पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)| +- लगभग सभी पुल रिक्वेस्ट के साथ संबंधित इस्स्यूज खोले और पहले चर्चा की जानी चाहिए, अर्थात पुश संबंधित इस्स्यूज के पहले पीआर की समीक्षा किया जाना चाहिए किसी भी स्टीवर्ड या मेंटेनर द्वारा। [issue workflow](steward_guidelines.md#issues) must have been followed first + - The only instances where this does not apply are very minor typo fixes, which do not require an open issue and can be merged by anyone with merge access to the repo, even if they are not stewards of a particular area. + - While this exception exists, we will apply it in practice only while contributors are still encouraged to open new issues first. In other words, if in doubt about whether this exception applies, just open an issue anyway. +- If a pull request does not fully solve the referenced issue, you can edit the original post and change "Resolves #OOOO" to "Addresses #OOOO" so that it does not automatically close the original issue when the PR is merged. + +### सरल सुधार + +Simple fixes, such as a small typo fix, can be merged directly by anyone with merge access.  Check on the PR "Files Changed" tab to ensure  that the automated CI test passes. + +![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png) + +![The "All checks have passed" indicator on a GitHub pull request, highlighted above the merge button](images/all-checks-passed.png) + +### बग फ़िक्स + +1. बग फ़िक्स का समीक्षा उस संबंधित क्षेत्र के स्टीवर्ड द्वारा किया जाना चाहिए, आदर्शतः उसी जिसने संदर्भित मुद्दे को फ़िक्स के लिए स्वीकृति दी थी। +2. पीआर "फ़ाइल बदले" टैब का उपयोग प्रारंभिक रूप से इसकी समीक्षा करने के लिए किया जा सकता है कि क्या फ़िक्स मुद्दे के चर्चा में वर्णित रूप में लागू किया गया है। +3. पीआर को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI प्रक्रिया के कुछ हिस्सों को समीक्षा करने में मदद कर सकता है। (यहाँ और [टिप्स और ट्रिक्स](Add link to tips and trick) में अधिक देखें). + - [ ] फ़िक्स को मूल मुद्दे को पर्याप्त रूप से संबोधित करना चाहिए। + - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल मुद्दे में सहमति न हो। + - [ ] फ़िक्स पर p5.js पर कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए। + - [ ] फ़िक्स पर p5.js की पहुँच कोई प्रभाव नहीं होना चाहिए। + - [ ] फ़िक्स को जावास्क्रिप्ट कोडिंग के आधुनिक मानक का उपयोग करना चाहिए। + - [ ] फ़िक्स को सभी स्वचालित परीक्षणों को पार करना चाहिए और यदि योग्य हो, तो नए परीक्षण शामिल करना चाहिए। +4. यदि कोई अतिरिक्त परिवर्तन आवश्यक हो, तो पंक्ति टिप्पणियाँ यहाँ जोड़ी [जानी चाहिए](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)। + - एक सुझाव ब्लॉक का उपयोग किया जा सकता है विशिष्ट परिवर्तनों का सुझाव देने के लिए: + ![The Suggest Change button while writing a comment on code in a GitHub pull request](images/suggest-change.png)\ + ![A suggested change appearing within code fences with the "suggestion" tag](images/suggested-value-change.png)\ + ![A suggested change previewed as a diff](images/suggestion-preview.png) + - यदि कई परिवर्तन की आवश्यकता है, तो एकाधिक बार एकल-लाइन टिप्पणियाँ न जोड़ें। बजाय इसके, कई-लाइन टिप्पणियाँ और एक ही परिवर्तन के लिए एक मांग करने के लिए यहाँ दस्तावेज़ की प्रक्रिया का [पालन करें](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)। + - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ + ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) +5. एक बार पीआर की समीक्षा की गई है और कोई अतिरिक्त परिवर्तन आवश्यक नहीं है, तो एक स्टीवर्ड पिछले चरण में "मंजूर" चयन करके पीआर को "मंजूर" चिह्नित कर सकता है, जिसमें अतिरिक्त टिप्पणियों के साथ या बिना चयन किया जा सकता है। स्टीवर्ड फिर अगर चाहें तो एक अन्य स्टीवर्ड या रक्षक से अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज पहुंच है, तो पीआर को मर्ज कर सकता है, या रक्षक से मर्ज का अनुरोध कर सकता है। + +6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) बॉट को बुलाया जाना चाहिए ताकि `README.md` फ़ाइल में नए योगदानकर्ताओं को योगदानकर्ताओं की सूची में जोड़ा जा सके। `[योगदान के प्रकार]` के स्थान पर हर प्रकार का योगदान निर्दिष्ट किया जा सकता है, योगदान के उपलब्ध प्रकार की पूरी सूची ऊपर दी गई लिंक में मिलेगी। + +`@all-contributors` `please` `add` `@[गिटहब हैंडल]` `for` `[योगदान के प्रकार]` + +### नई सुविधा/सुविधा वृद्धि + +नई सुविधा या सुविधा वृद्धि पीआर के लिए परिक्रिया बग निवारण के साथ मिलती जुलती है, केवल एक विशेष अंतर है: + +- एक नई सुविधा/सुविधा वृद्धि पीआर को मर्ज करने से पहले कम से कम दो स्टीवर्ड या रक्षक द्वारा समीक्षित और मंजूर किया जाना चाहिए। + +### डिपेंडेबॉट + +डिपेंडेबॉट पीआर आमतौर पर केवल रिपो व्यवस्थापकों को ही दिखाई जाती हैं, इसलिए यदि यह आपके लिए लागू नहीं होता है, तो कृपया इस खंड को छोड़ें। + +- डिपेंडेबॉट पीआर [सीमवर पैच](https://semver.org/) संस्करण है और स्वचालित सीआई परीक्षण पास हो जाता है तो सीधे मर्ज किए जा सकते हैं। +- सेमवर माइनर संस्करण परिवर्तन के साथ डिपेंडेबॉट पीआर आमतौर पर स्वचालित सीआई परीक्षण पास होने के तुरंत बाद सीधे मर्ज किए जा सकते हैं। अपडेट की गई आवश्यकता के चेकलिस्ट पर एक त्वरित जांच की जाती है। +- Dependabot PRs with semver major version changes may likely affect either the build process or p5.js functionalities. The reviewer, in this case, is encouraged to review the changelog from the current version to the target version if possible and test the PR locally to ensure all processes are functioning and make any required changes due to potential breaking changes in the dependencies. + - कई निर्भरताओं ने मुख्य संस्करण संख्याओं को केवल इसलिए बढ़ाया है क्योंकि वे बहुत पुराने संस्करणों के लिए आधिकारिक समर्थन को हटा देते हैं। बहुत से मामलों में, मुख्य संस्करण परिवर्तन निर्भरता एपीआई परिवर्तन से होने वाले तोड़फोड़ को नहीं अवश्य मतलब है। + +--- + +## निर्माण प्रक्रिया + +यह खंड सामान्य निर्माण सेटअप या आदेश का विवरण नहीं करेगा, बल्कि विवरणों के पीछे क्या हो रहा है उसके बारे में जानकारी देगा। कृपया अधिक विस्तृत निर्माण जानकारी के लिए [योगदानकर्ता दिशानिर्देश](Add link to contributor guidlines) देखें। + +`Gruntfile.js` फ़ाइल p5.js के मुख्य निर्माण परिभाषणों को संबोधित करती है। पुस्तकालय और दस्तावेज़ीकरण निर्माण के लिए उपयोग किए जाने वाले विभिन्न उपकरणों में `Grunt`, `Browserify`, `YUIDoc`, `ESLint`, `Babel`, `Uglify`, और `Mocha` शामिल हैं। यह हमारे लिए `डिफ़ॉल्ट` टास्क के साथ शुरू करने और वहां से पिछले काम करने में मददगार हो सकता है। इस विवरण के दौरान `Gruntfile.js` दस्तावेज़ को खोलना भी उपयोगी हो सकता है। + +### मुख्य निर्माण कार्य + +``` +grunt.registerTask('default', ['lint', 'test']); +``` + +जब हम `grunt` या `npm` स्क्रिप्ट npm `test` चलाते हैं, तो हम लिंट फिर परीक्षण के रूप में लिंट का डिफ़ॉल्ट टास्क चलाते हैं। + +#### `lint` कार्य + +``` +grunt.registerTask('lint', ['lint:source', 'lint:samples']); +``` + +लिंट कार्य में दो उप-कार्य होते हैं: `lint:source` और `lint:samples`। `lint:source` को तीन और उप-कार्यों में विभाजित किया गया है `eslint:build`, `eslint:source`, और `eslint:test`, जो ESLint का उपयोग निर्माण स्क्रिप्ट, सोर्स कोड, और परीक्षण स्क्रिप्ट की जाँच करने के लिए करता है। + +The `lint:samples` task will first run the `yui` task which itself consists of `yuidoc:prod`, `clean:reference`, and `minjson`, which extract the documentation from the source code into a JSON document, remove unused files from the previous step, and minify the generated JSON file into `data.min.json` respectively. + +Next in `lint:samples` is `eslint-samples:source`, which is a custom written task whose definition is in [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js); it will run ESLint to check the documentation example code to make sure they follow the same coding convention as the rest of p5.js (`yui` is run first here because we need the JSON file to be built first before we can lint the examples). + +#### `test` कार्य + +```js +grunt.registerTask("test", ["build", "connect:server", "mochaChrome", "mochaTest", "nyc:report"]); +``` + +सबसे पहले अपने तहत `test` के नीचे `build` कार्य को देखते हैं। + +```js +grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browserify:test"]); +``` + +`browserify` से शुरू होने वाले कार्य [./tasks/build/browserify.js](tasks/build/browserify.js) में परिभाषित होते हैं। इनमें सभी मुख्य कदम होते हैं जो बहुत से उपयोगकर्ता कोड फ़ाइलों को संग्रहीत और एक में बनाने के लिए हैं: + +- `browserify` p5.js बनाता है जबकि `browserify:min` अगले कदम में संक्षिप्त किए जाने वाले एक बीच की फ़ाइल को बनाता है। `browserify` और `browserify:min` के बीच अंतर यह है कि `browserify:min` FES के लिए कार्यात्मक नहीं होने वाले डेटा को नहीं समाहित करता। +- `uglify` `browserify:min` की उत्पादित फ़ाइल को छोटा करता है और अंतिम `p5.min.js` में इसे छोटा करता है (इस कदम की विन्यासिकता मुख्य `Gruntfile.js` में है)। +- `browserify:test` एक पूरे p5.js के संग्रह को बनाता है, लेकिन परीक्षण कोड कवरेज रिपोर्टिंग के लिए जोड़ा गया कोड जोड़ता है ([Istanbul](https://istanbul.js.org/) का उपयोग करके)। + +पहले, नोड.जेएस के `fs.readFileSync()` का उपयोग फाइल की वास्तविक सामग्री के साथ प्रतिस्थापित किया जाता है जिसे `brfs-babel` का उपयोग किया जाता है। यह मुख्य रूप से वेबजीएल कोड के लिए उपयोग किया जाता है जो अलग फ़ाइलों के रूप में लिखा गया है। + +Next, the source code, including all dependencies from node_modules, is transpiled using Babel to match the [Browserslist](https://browsersl.ist/) requirement defined in package.json as well as to make the ES6 import statements into CommonJS `require()` that browserify understands. This also enables us to use newer syntax available in ES6 and beyond without worrying about browser compatibility. + +बंडलिंग के बाद, लेकिन फ़ाइल में लिखा जाने से पहले, कोड को `pretty-fast` के माध्यम से पार किया जाता है, यदि यह न्यूनतम नहीं है, तो इसे साफ कर दिया जाता है ताकि अंतिम स्वरूपण कुछ संरचनात्मक रूप से अधिक संबंधित हो (हम उम्मीद करते हैं कि p5.js स्रोत कोड पढ़ा और जांचा जा सकता है यदि इच्छित है)। + +यहां कुछ छोटे विस्तृत कदम छोड़े गए हैं; आप नीचे दिए गए ब्राउज़रीफ़ाई निर्माण परिभाषण फ़ाइल की जांच करने के लिए सब कुछ को और करीब से देख सकते हैं। + +``` +connect:server +``` + +यह कदम स्थानीय सर्वर को स्पिन करता है जो परीक्षण फ़ाइलों और निर्मित स्रोत कोड फ़ाइलों को होस्ट करता है ताकि क्रोम में स्वचालित परीक्षण चलाया जा सके। + +``` +mochaChrome +``` + +यह कदम [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js) में परिभाषित है। यह प्यूपिटीयर का उपयोग करता है जो क्रोम का एक हेडलेस संस्करण स्पिन करता है जिसे रिमोट नियंत्रित किया जा सकता है और `./test` फ़ोल्डर में `HTML` फ़ाइलों के साथ जुड़े परीक्षणों को चलाता है, जिसमें लाइब्रेरी के अनमिनिफ़ाइड और मिनिफ़ाइड संस्करणों को यूनिट परीक्षण सुइटों के साथ परीक्षण किया जाता है साथ ही सभी संदर्भ उदाहरणों का परीक्षण किया जाता है। + +``` +mochaTest +``` + +This step differs from `mochaChrome` in that it is run in node.js instead of in Chrome and only tests a small subset of features in the library. Most features in p5.js will require a browser environment, so this set of tests should only be expanded if the new tests really don't need a browser environment. + +``` +nyc:report +``` + +आखिरकार, सभी निर्माण और परीक्षण पूर्ण होने के बाद, यह कदम परीक्षण कवरेज रिपोर्ट इकट्ठा करेगा जबकि `mochaChrome` ने पुस्तकालय का पूर्ण संस्करण परीक्षण किया था और परीक्षण कवरेज डेटा को कंसोल में प्रिंट करेगा। p5.js के परीक्षण कवरेज को मुख्यतः मॉनिटरिंग और कुछ अतिरिक्त डेटा बिंदुओं के लिए है; 100% परीक्षण कवरेज का उद्देश्य नहीं है। + +और यही `Gruntfile.js` कॉन्फ़िगरेशन में डिफ़ॉल्ट कार्य को कवर करता है! + +### विविध कार्य + +सभी कदमों को `npx grunt [कदम]` के साथ सीधे चलाया जा सकता है। ऊपर नहीं चित्रित कुछ कार्य हैं जो ऊपर नहीं शामिल हैं लेकिन कुछ विशेष प्रकार के मामलों में उपयोगी हो सकते हैं। + +``` +grunt yui:dev +``` + +यह कार्य ऊपर विवरणित दस्तावेज़ और पुस्तकालय निर्माण को चलाएगा, उसके बाद उसी कोड के स्रोत में चिलम करने के लिए एक वेब सर्वर को स्पिन करेगा जिसका आप वेबसाइट पर [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/) पर संदर्भ पृष्ठ के संविदानी संस्करण के रूप में प्राप्त कर सकते हैं। फिर, यह स्रोत कोड के लिए बदलावों का मॉनिटर करेगा और संदर्भ और पुस्तकालय को फिर से निर्माण करेगा। + +`grunt` `yui:dev` उस समय उपयोगी है जब आप इनलाइन दस्तावेज़ में संदर्भ पर काम कर रहे हों क्योंकि आपको प्रति बार जब आप एक परिवर्तन करते हैं, तो आपको पिछले p5.js रिपॉजिटरी से निर्मित फ़ाइलों को स्थानीय p5.js-वेबसाइट रिपॉजिटरी में ले जाने और वेबसाइट को पुनः निर्मित करने की आवश्यकता नहीं होती है, और आप बस अपने परिवर्तनों को अपने ब्राउज़र में संदर्भ के इस संविदानी संस्करण की एकदम साधारित रूप में पूर्वावलोकन कर सकते हैं। इस तरह, आपको यह भी अधिक विश्वसनीय हो सकता है कि आपके द्वारा किए गए परिवर्तनों का सही रूप से वेबसाइट पर प्रकट होने की संभावना है। ध्यान दें कि यह केवल इनलाइन दस्तावेज़ के संशोधनों के लिए है; संदर्भ पृष्ठ इसका हिस्सा, संशोधन और लेआउट सहित, वेबसाइट रिपॉजिटरी पर बनाए और परीक्षण किए जाने चाहिए। + +``` +grunt watch +grunt watch:main +grunt watch:quick +``` + +वॉच कार्य विभिन्न फ़ाइलों के लिए बदलावों की निगरानी करेंगे और कौन से फ़ाइलों में क्या परिवर्तन हुआ है, उस अनुसार संबंधित कार्यों को चलाएगे। ये सभी कार्य एक ही चीज़ करते हैं, जिसका केवल विस्तार है। + +The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code. + +The `watch:main` task will run the library build and tests but not rebuild the reference on detecting changes in the source code. + +The `watch:quick` task will run the library build only on detecting changes in the source code. + +Depending on what you are working on, choosing the most minimal watch task here can save you from having to manually run a rebuild whenever you want to make some changes. + +--- + +## Release process + +कृपया रिलीज [`release_process.md`](release_process.md) देखें। + +--- + +## युक्तियाँ और ट्रिक्स + +कभी-कभी, समीक्षा के लिए जितने भी जटिल पीआर हैं, उन्हें स्थानीय रूप से परीक्षण करने के लिए गिट के जटिल कमांड की आवश्यकता हो सकती है। भाग्य से, गिटहब सीएलआई टूल इस प्रक्रिया और अधिक के साथ बहुत मदद कर सकता है। + +### Reply templates + +A handy GitHub feature that you can use is the [Saved Replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) feature, which is available to use when authoring a reply to issues or pull requests. Some of the workflow described above may require responding to issues or PRs with identical or very similar replies (redirecting questions to the forum, accepting an issue for fixing, etc.), and using Saved Replies can just ever so slightly make this more efficient. + +Below are some of the Saved Replies that are being used by p5.js maintainers. You can use them yourself or create your own! + +##### Closing: Can’t Reproduce + +> We're not able to reproduce this, but please feel free to reopen if you can provide a code sample that demonstrates the issue. Thanks! + +##### Closing: Need Snippet + +> I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks! + +##### Closing: Use the Forum + +> The GitHub issues here are a good place for bugs and issues with the p5.js library itself. For questions about writing your own code, tests, or following tutorials, the [forum](https://discourse.processing.org/) is the best place to post. Thanks! + +##### Closing: GSOC + +> Thanks! The best place to discuss GSOC proposals is on our [forum](https://discourse.processing.org/c/summer-of-code). + +##### Closing: Access + +> I'm not seeing a lot of interest in this feature, and we don't have a clear explanation of how it [expands access](access.md), so I will close this for now. If an access statement can be added to the issue request, please feel welcome to reopen. + +> We do not see a further explanation of how this issue [expands access](access.md), so I will close this issue for now. If a more detailed access statement can be added to the feature request, please feel welcome to reopen it. Thank you! + +##### Closing: Addon + +> I think this function is beyond the scope of the p5.js API (we try to keep it as minimal as possible), but it could be a great starting point for an addon library. See the docs here for how to create an addon: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) + +##### Closing PR: Need Issue First + +> Thank you. As a reminder, issues need to be opened before pull requests are opened and tagged with the issue. This is necessary for tracking development and keeping discussion clear. Thanks! + +##### Approve issue for fixing + +> You can go ahead with a fix. Thanks. + +##### Merged PR + +> Looks good. Thanks! + +### GitHub CLI + +Reviewing a complex PR can be difficult with complex git commands required to get the PR's version of code locally for you to test. Fortunately, the [GitHub CLI](https://cli.github.com/) tool can help greatly with this process and more. + +क्लाइंट को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पीआर की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout` मेन। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पीआर में से! + +गिटहब एसईएलआई में बहुत सारे अन्य कमांड भी उपलब्ध हैं जो आपको उपयोगी हो सकते हैं या नहीं मिल सकते हैं, लेकिन यह एक अच्छा उपकरण है जिसका आपके आसपास होना है किसी भी मामले में। + +### सूचनाओं का प्रबंधन + +नए मुद्दों या पीआर के लिए "मुद्दे" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। + +![Cropped screenshot of the top right corner of a GitHub repository page showing a series of buttons in the center from left to right: Sponsor, Watch, Fork, Starred.](images/github-repo-metrics.png) + +रेपो को देखकर, नई समस्याएं, नई पुल रिक्वेस्ट्स, आपके उपयोगकर्ता हैंडल का उल्लेख, और अन्य गतिविधियां, जिनकी आपने रेपो में सब्सक्राइब की हैं, इन घटनाओं को आपके [सूचना पृष्ठ](https://github.com/notifications) पर सूचनाएं के रूप में भेजी जाती हैं, जिन्हें आप स्वीकार कर सकते हैं या उन्हें ईमेल इनबॉक्स की तरह पढ़कर या खारिज कर सकते हैं। + +कई मामलों में, आपको GitHub से रेपो में हो रही घटनाओं के बारे में ईमेल भी मिल सकते हैं, और आप इन्हें अपनी [सूचना सेटिंग्स पेज](https://github.com/settings/notifications) से कस्टमाइज़ कर सकते हैं (पूरी तरह से उनका अनसब्सक्राइब करके समेत)। + +आपके काम करने के तरीके को ध्यान में रखते हुए इन्हें सेट करना, समस्याओं/पीआर समीक्षा को मैन्युअली से खोजने की आवश्यकता न हो और GitHub से अंतहीन सूचनाओं से अधिक भरी होने से बचाने में अंतर हो सकता है। यहां एक अच्छा संतुलन आवश्यक है। एक शुरुआती सुझाव के रूप में, स्टीवर्ड्स को इस रेपो के लिए "समस्याएँ" और "पुल रिक्वेस्ट्स" के लिए देखना चाहिए और इसे "भाग लेना, @मेंशन्स और कस्टम (Participating, @mentions and custom)" पर सेट करना चाहिए। From 5bb0f5d3ca14511183aa015185fc7bf1157d1029 Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Mon, 18 Mar 2024 22:43:53 +0530 Subject: [PATCH 2/8] complete translation --- contributor_docs/hi/steward_guidelines.md | 183 ++++++++++++---------- 1 file changed, 96 insertions(+), 87 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index fd35f1e7af..b857633c35 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -4,24 +4,30 @@ ## विषय सूची -- [Issues](steward_guidelines.md#issues) - - [Bug report](steward_guidelines.md#bug-report) - - [Feature request](steward_guidelines.md#feature-request) - - [Feature enhancement](steward_guidelines.md#feature-enhancement) - - [Discussion](steward_guidelines.md#discussion) -- [Pull Requests](steward_guidelines.md#pull-requests) - - [Simple fix](steward_guidelines.md#simple-fix) - - [Bug fix](steward_guidelines.md#bug-fix) - - [New feature/feature enhancement](steward_guidelines.md#new-feature-feature-enhancement) - - [Dependabot](steward_guidelines.md#dependabot) -- [Build Process](steward_guidelines.md#build-process) - - [Main build task](steward_guidelines.md#main-build-task) - - [Miscellaneous tasks](steward_guidelines.md#miscellaneous-tasks) -- [Release Process](steward_guidelines.md#release-process) -- [Tips & Tricks](steward_guidelines.md#tips--tricks) - - [Reply templates](steward_guidelines.md#reply-templates) - - [GitHub CLI](steward_guidelines.md#github-cli) - - [Managing notifications](steward_guidelines.md#managing-notifications) +- [समस्याएँ](./steward_guidelines.md#समस्याएँ) + + - [बग रिपोर्ट](./steward_guidelines.md#बग-रिपोर्ट) + - [सुविधा अनुरोध](./steward_guidelines.md#सुविधा-अनुरोध) + - [सुविधा विस्तार](./steward_guidelines.md#सुविधा-विस्तार) + - [चर्चा](./steward_guidelines.md#चर्चा) + +- [पुल-रिक्वेस्ट](./steward_guidelines.md#पुल-रिक्वेस्ट) + + - [सरल सुधार](./steward_guidelines.md#सरल-सुधार) + - [बग फ़िक्स](./steward_guidelines.md#बग-फ़िक्स) + - [नई सुविधा/सुविधा वृद्धि](./steward_guidelines.md#नई-सुविधासुविधा-वृद्धि) + - [डिपेंडेबॉट](./steward_guidelines.md#डिपेंडेबॉट) + +- [निर्माण प्रक्रिया](./steward_guidelines.md#निर्माण-प्रक्रिया) + + - [मुख्य निर्माण कार्य](./steward_guidelines.md#मुख्य-निर्माण-कार्य) + - [विविध कार्य](./steward_guidelines.md#विविध-कार्य) + +- [युक्तियाँ और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) + + - [उत्तर टेम्पलेट](./steward_guidelines.md#उत्तर-टेम्पलेट) + - [गिटहब सीएलआई](./steward_guidelines.md#गिटहब-सीएलआई) + - [सूचनाओं का प्रबंधन](./steward_guidelines.md#सूचनाओं-का-प्रबंधन) --- @@ -70,12 +76,12 @@ Bबग रिपोर्ट समस्याओं को "बग मिल - सम्पूर्ण रूप से, p5.js का धारा संक्षिप्त होना चाहिए ताकि अनियमित उपयोग की सुविधाओं से बचा जा सके। - यदि कोई सुविधा p5.js के धारा में फिट नहीं होती है, तो सुझाव दें कि समस्या लेखक सुविधा को एक ऐड-ऑन पुस्तकालय के रूप में अमल करें। - यदि स्पष्ट नहीं है कि यह फिट है या नहीं, तो एक प्रमाण-प्रतिसाद के रूप में एक ऐड-ऑन पुस्तकालय बनाने का सुझाव देना एक अच्छा विचार हो सकता है। यह प्रयोक्ताओं को सुविधा का उपयोग करने का एक तरीका देता है, इसका उपयोग और महत्ता का एक अधिक स्पष्ट उदाहरण प्रदान करता है, और पूरी तरह से एक स्थायी समाधान की तरह पूरा नहीं होना चाहिए। यह परियोजना की मूल धारा में बाद में शामिल किया जा सकता है। - - Is the feature likely to cause a breaking change? - - Will it conflict with existing p5.js functions and variables? - - Will it conflict with typical sketches already written for p5.js? + - क्या इस सुविधा के कारण ब्रेकिंग परिवर्तन होने की संभावना है? + - क्या यह मौजूदा p5.js फ़ंक्शंस और वेरिएबल्स के साथ विरोध करेगा? + - क्या यह p5.js के लिए पहले से लिखे गए विशिष्ट रेखाचित्रों के साथ टकराव करेगा? - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? - - For example, instead of providing a p5.js function to join an array of strings such as `join(["Hello", "world!"])`, the native JavaScript `["Hello", "world!"].join()` should be preferred instead. + - उदाहरण के लिए, `join(["hello", "world!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। 3. यदि पहुँच आवश्यकता और अन्य विचारों को पूरा किया गया है, तो नई सुविधा अनुरोध को प्रारंभ किया जाना चाहिए जब तक कि कार्य पीआर की ओर न हो। नई सुविधाओं के पीआर की समीक्षा प्रक्रिया नीचे विवरणित है। ### सुविधा विस्तार @@ -93,8 +99,8 @@ Bबग रिपोर्ट समस्याओं को "बग मिल इस प्रकार की समस्या के पास एक न्यूनतम टेम्प्लेट ("चर्चा" (discussion)) होता है और इसका उपयोग विषय के चारों ओर संवाद जमा करने के लिए किया जाना चाहिए, जो बाद में किसी विशेष मुद्दे में एकत्रित किया जाता है, जैसे कि एक सुविधा अनुरोध। इन प्रकार की चर्चा समस्याओं को समाप्त होने पर बंद किया जा सकता है और परिणामी अधिक विशिष्ट समस्याएं बना दी गई हैं: -- If an issue is opened as a discussion but should be, for example, a bug report, the correct label should be applied and the "discussion" label removed. Additional info about the bug should also be requested from the author if not already included. -- If an issue is opened as a discussion but isn't relevant to source code contribution or otherwise relevant to the GitHub repositories/contribution process/contribution community, they should be redirected to the forum or Discord and the issue closed. +- यदि कोई मुद्दा चर्चा के रूप में खोला गया है, लेकिन उदाहरण के लिए, एक बग रिपोर्ट होना चाहिए, तो सही लेबल लागू किया जाना चाहिए और "चर्चा" लेबल हटा दिया जाना चाहिए। यदि पहले से शामिल नहीं है तो बग के बारे में अतिरिक्त जानकारी भी लेखक से मांगी जानी चाहिए। +- यदि कोई मुद्दा चर्चा के रूप में खोला गया है, लेकिन स्रोत कोड योगदान के लिए प्रासंगिक नहीं है या अन्यथा गिटहब रिपॉजिटरी/योगदान प्रक्रिया/योगदान समुदाय के लिए प्रासंगिक नहीं है, तो उन्हें फ़ोरम या डिस्कॉर्ड पर पुनर्निर्देशित किया जाना चाहिए और मुद्दा बंद कर दिया जाना चाहिए। - यदि लागू हो, तो चर्चा इस्स्यूज के लिए अतिरिक्त लेबल जोड़े जा सकते हैं ताकि एक नजर में यह देखा जा सके कि यह किस प्रकार की चर्चा है। --- @@ -104,41 +110,44 @@ Bबग रिपोर्ट समस्याओं को "बग मिल प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। स्टीवर्ड और मेंटेनर्स रिपॉजिट्रीज के पुश एक्सेस रख सकते हैं लेकिन जब भी कोड योगदान किया जाता है, तो वे पुल रिक्वेस्ट की समीक्षा करने को प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: - पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)| -- लगभग सभी पुल रिक्वेस्ट के साथ संबंधित इस्स्यूज खोले और पहले चर्चा की जानी चाहिए, अर्थात पुश संबंधित इस्स्यूज के पहले पीआर की समीक्षा किया जाना चाहिए किसी भी स्टीवर्ड या मेंटेनर द्वारा। [issue workflow](steward_guidelines.md#issues) must have been followed first - - The only instances where this does not apply are very minor typo fixes, which do not require an open issue and can be merged by anyone with merge access to the repo, even if they are not stewards of a particular area. - - While this exception exists, we will apply it in practice only while contributors are still encouraged to open new issues first. In other words, if in doubt about whether this exception applies, just open an issue anyway. -- If a pull request does not fully solve the referenced issue, you can edit the original post and change "Resolves #OOOO" to "Addresses #OOOO" so that it does not automatically close the original issue when the PR is merged. +- लगभग सभी पुल रिक्वेस्ट के साथ संबंधित इस्स्यूज खोले और पहले चर्चा की जानी चाहिए, अर्थात पुश संबंधित इस्स्यूज के पहले पीआर की समीक्षा किया जाना चाहिए किसी भी स्टीवर्ड या मेंटेनर द्वारा। [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए + - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुले मुद्दे की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। + - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए मुद्दे खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक मुद्दा खोलें। +- यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पीआर विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। ### सरल सुधार -Simple fixes, such as a small typo fix, can be merged directly by anyone with merge access.  Check on the PR "Files Changed" tab to ensure  that the automated CI test passes. +सरल सुधार, जैसे कि छोटी टाइपो फिक्स, को मर्ज एक्सेस वाले किसी भी व्यक्ति द्वारा सीधे मर्ज किया जा सकता है। यह सुनिश्चित करने के लिए कि स्वचालित सीआई परीक्षण पास हो गया है, पीआर "फ़ाइलें परिवर्तित (files changed)" टैब पर जांचें। -![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png) +![गिटहब पर पुल अनुरोध देखते समय "फ़ाइलें परिवर्तित (Files changed)" टैब](images/files-changed.png) -![The "All checks have passed" indicator on a GitHub pull request, highlighted above the merge button](images/all-checks-passed.png) +![गिटहब पुल अनुरोध पर "सभी चेक पास हो गए हैं (All checks have passed)" संकेतक, मर्ज बटन के ऊपर हाइलाइट किया गया है](images/all-checks-passed.png) ### बग फ़िक्स -1. बग फ़िक्स का समीक्षा उस संबंधित क्षेत्र के स्टीवर्ड द्वारा किया जाना चाहिए, आदर्शतः उसी जिसने संदर्भित मुद्दे को फ़िक्स के लिए स्वीकृति दी थी। -2. पीआर "फ़ाइल बदले" टैब का उपयोग प्रारंभिक रूप से इसकी समीक्षा करने के लिए किया जा सकता है कि क्या फ़िक्स मुद्दे के चर्चा में वर्णित रूप में लागू किया गया है। -3. पीआर को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI प्रक्रिया के कुछ हिस्सों को समीक्षा करने में मदद कर सकता है। (यहाँ और [टिप्स और ट्रिक्स](Add link to tips and trick) में अधिक देखें). - - [ ] फ़िक्स को मूल मुद्दे को पर्याप्त रूप से संबोधित करना चाहिए। - - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल मुद्दे में सहमति न हो। - - [ ] फ़िक्स पर p5.js पर कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए। - - [ ] फ़िक्स पर p5.js की पहुँच कोई प्रभाव नहीं होना चाहिए। - - [ ] फ़िक्स को जावास्क्रिप्ट कोडिंग के आधुनिक मानक का उपयोग करना चाहिए। - - [ ] फ़िक्स को सभी स्वचालित परीक्षणों को पार करना चाहिए और यदि योग्य हो, तो नए परीक्षण शामिल करना चाहिए। -4. यदि कोई अतिरिक्त परिवर्तन आवश्यक हो, तो पंक्ति टिप्पणियाँ यहाँ जोड़ी [जानी चाहिए](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)। - - एक सुझाव ब्लॉक का उपयोग किया जा सकता है विशिष्ट परिवर्तनों का सुझाव देने के लिए: - ![The Suggest Change button while writing a comment on code in a GitHub pull request](images/suggest-change.png)\ - ![A suggested change appearing within code fences with the "suggestion" tag](images/suggested-value-change.png)\ - ![A suggested change previewed as a diff](images/suggestion-preview.png) - - यदि कई परिवर्तन की आवश्यकता है, तो एकाधिक बार एकल-लाइन टिप्पणियाँ न जोड़ें। बजाय इसके, कई-लाइन टिप्पणियाँ और एक ही परिवर्तन के लिए एक मांग करने के लिए यहाँ दस्तावेज़ की प्रक्रिया का [पालन करें](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)। - - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ - ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) -5. एक बार पीआर की समीक्षा की गई है और कोई अतिरिक्त परिवर्तन आवश्यक नहीं है, तो एक स्टीवर्ड पिछले चरण में "मंजूर" चयन करके पीआर को "मंजूर" चिह्नित कर सकता है, जिसमें अतिरिक्त टिप्पणियों के साथ या बिना चयन किया जा सकता है। स्टीवर्ड फिर अगर चाहें तो एक अन्य स्टीवर्ड या रक्षक से अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज पहुंच है, तो पीआर को मर्ज कर सकता है, या रक्षक से मर्ज का अनुरोध कर सकता है। - -6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) बॉट को बुलाया जाना चाहिए ताकि `README.md` फ़ाइल में नए योगदानकर्ताओं को योगदानकर्ताओं की सूची में जोड़ा जा सके। `[योगदान के प्रकार]` के स्थान पर हर प्रकार का योगदान निर्दिष्ट किया जा सकता है, योगदान के उपलब्ध प्रकार की पूरी सूची ऊपर दी गई लिंक में मिलेगी। +1. बग फ़िक्स का समीक्षा उस संबंधित क्षेत्र के स्टीवर्ड द्वारा किया जाना चाहिए, आदर्शतः उसी जिसने संदर्भित मुद्दे को फ़िक्स के लिए स्वीकृति दी थी। +2. पीआर "फ़ाइल बदले" टैब का उपयोग प्रारंभिक रूप से इसकी समीक्षा करने के लिए किया जा सकता है कि क्या फ़िक्स मुद्दे के चर्चा में वर्णित रूप में लागू किया गया है। +3. पीआर को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI प्रक्रिया के कुछ हिस्सों को समीक्षा करने में मदद कर सकता है। (यहाँ और [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). + - [ ] फ़िक्स को मूल मुद्दे को पर्याप्त रूप से संबोधित करना चाहिए। + - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल मुद्दे में सहमति न हो। + - [ ] फ़िक्स पर p5.js पर कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए। + - [ ] फ़िक्स पर p5.js की पहुँच कोई प्रभाव नहीं होना चाहिए। + - [ ] फ़िक्स को जावास्क्रिप्ट कोडिंग के आधुनिक मानक का उपयोग करना चाहिए। + - [ ] फ़िक्स को सभी स्वचालित परीक्षणों को पार करना चाहिए और यदि योग्य हो, तो नए परीक्षण शामिल करना चाहिए। +4. यदि कोई अतिरिक्त परिवर्तन आवश्यक हो, तो पंक्ति टिप्पणियाँ यहाँ जोड़ी [जानी चाहिए](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)। + + - एक सुझाव ब्लॉक का उपयोग किया जा सकता है विशिष्ट परिवर्तनों का सुझाव देने के लिए: + ![गिटहब पुल अनुरोध में कोड पर टिप्पणी लिखते समय परिवर्तन का सुझाव बटन](images/suggest-change.png)\ + ![एक सुझाया गया परिवर्तन "सुझाव (suggestion)" टैग के साथ कोड बाड़ के भीतर दिखाई देता है](images/suggested-value-change.png)\ + ![सुझाए गए परिवर्तन का पूर्वावलोकन अंतर के रूप में किया गया](images/suggestion-preview.png) + + - यदि कई परिवर्तन की आवश्यकता है, तो एकाधिक बार एकल-लाइन टिप्पणियाँ न जोड़ें। बजाय इसके, कई-लाइन टिप्पणियाँ और एक ही परिवर्तन के लिए एक मांग करने के लिए यहाँ दस्तावेज़ की प्रक्रिया का [पालन करें](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)। + - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ + ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) + +5. एक बार पीआर की समीक्षा की गई है और कोई अतिरिक्त परिवर्तन आवश्यक नहीं है, तो एक स्टीवर्ड पिछले चरण में "मंजूर" चयन करके पीआर को "मंजूर" चिह्नित कर सकता है, जिसमें अतिरिक्त टिप्पणियों के साथ या बिना चयन किया जा सकता है। स्टीवर्ड फिर अगर चाहें तो एक अन्य स्टीवर्ड या रक्षक से अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज पहुंच है, तो पीआर को मर्ज कर सकता है, या रक्षक से मर्ज का अनुरोध कर सकता है। + +6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) बॉट को बुलाया जाना चाहिए ताकि `README.md` फ़ाइल में नए योगदानकर्ताओं को योगदानकर्ताओं की सूची में जोड़ा जा सके। `[योगदान के प्रकार]` के स्थान पर हर प्रकार का योगदान निर्दिष्ट किया जा सकता है, योगदान के उपलब्ध प्रकार की पूरी सूची ऊपर दी गई लिंक में मिलेगी। `@all-contributors` `please` `add` `@[गिटहब हैंडल]` `for` `[योगदान के प्रकार]` @@ -154,7 +163,7 @@ Simple fixes, such as a small typo fix, can be merged directly by anyone with me - डिपेंडेबॉट पीआर [सीमवर पैच](https://semver.org/) संस्करण है और स्वचालित सीआई परीक्षण पास हो जाता है तो सीधे मर्ज किए जा सकते हैं। - सेमवर माइनर संस्करण परिवर्तन के साथ डिपेंडेबॉट पीआर आमतौर पर स्वचालित सीआई परीक्षण पास होने के तुरंत बाद सीधे मर्ज किए जा सकते हैं। अपडेट की गई आवश्यकता के चेकलिस्ट पर एक त्वरित जांच की जाती है। -- Dependabot PRs with semver major version changes may likely affect either the build process or p5.js functionalities. The reviewer, in this case, is encouraged to review the changelog from the current version to the target version if possible and test the PR locally to ensure all processes are functioning and make any required changes due to potential breaking changes in the dependencies. +- सेमेस्टर प्रमुख संस्करण परिवर्तनों के साथ डिपेंडाबॉट पीआर संभवतः निर्माण प्रक्रिया या पी5.जेएस कार्यक्षमता को प्रभावित कर सकते हैं। इस मामले में, समीक्षक को यदि संभव हो तो वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने और यह सुनिश्चित करने के लिए स्थानीय स्तर पर पीआर का परीक्षण करने के लिए प्रोत्साहित किया जाता है कि सभी प्रक्रियाएं कार्य कर रही हैं और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। - कई निर्भरताओं ने मुख्य संस्करण संख्याओं को केवल इसलिए बढ़ाया है क्योंकि वे बहुत पुराने संस्करणों के लिए आधिकारिक समर्थन को हटा देते हैं। बहुत से मामलों में, मुख्य संस्करण परिवर्तन निर्भरता एपीआई परिवर्तन से होने वाले तोड़फोड़ को नहीं अवश्य मतलब है। --- @@ -181,9 +190,9 @@ grunt.registerTask('lint', ['lint:source', 'lint:samples']); लिंट कार्य में दो उप-कार्य होते हैं: `lint:source` और `lint:samples`। `lint:source` को तीन और उप-कार्यों में विभाजित किया गया है `eslint:build`, `eslint:source`, और `eslint:test`, जो ESLint का उपयोग निर्माण स्क्रिप्ट, सोर्स कोड, और परीक्षण स्क्रिप्ट की जाँच करने के लिए करता है। -The `lint:samples` task will first run the `yui` task which itself consists of `yuidoc:prod`, `clean:reference`, and `minjson`, which extract the documentation from the source code into a JSON document, remove unused files from the previous step, and minify the generated JSON file into `data.min.json` respectively. +`lint:samples` कार्य पहले `yui` कार्य को चलाएगा जिसमें स्वयं `yuidoc: prod`, `clean:reference`, और `minjson` शामिल हैं, जो स्रोत कोड से दस्तावेज़ को JSON दस्तावेज़ में निकालते हैं, हटाते हैं पिछले चरण से अप्रयुक्त फ़ाइलें, और उत्पन्न JSON फ़ाइल को क्रमशः `data.min.json` में छोटा करें। -Next in `lint:samples` is `eslint-samples:source`, which is a custom written task whose definition is in [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js); it will run ESLint to check the documentation example code to make sure they follow the same coding convention as the rest of p5.js (`yui` is run first here because we need the JSON file to be built first before we can lint the examples). +`lint:samples` में अगला है `eslint-samples:source`, जो एक कस्टम लिखित कार्य है जिसकी परिभाषा [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js) में है ; यह दस्तावेज़ीकरण उदाहरण कोड की जांच करने के लिए ESLint चलाएगा ताकि यह सुनिश्चित किया जा सके कि वे बाकी p5.js के समान कोडिंग कन्वेंशन का पालन करते हैं (`yui` यहां पहले चलाया गया है क्योंकि हमें उदाहरणों को लिंट करने से पहले JSON फ़ाइल बनाने की आवश्यकता है ). #### `test` कार्य @@ -205,7 +214,7 @@ grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browseri पहले, नोड.जेएस के `fs.readFileSync()` का उपयोग फाइल की वास्तविक सामग्री के साथ प्रतिस्थापित किया जाता है जिसे `brfs-babel` का उपयोग किया जाता है। यह मुख्य रूप से वेबजीएल कोड के लिए उपयोग किया जाता है जो अलग फ़ाइलों के रूप में लिखा गया है। -Next, the source code, including all dependencies from node_modules, is transpiled using Babel to match the [Browserslist](https://browsersl.ist/) requirement defined in package.json as well as to make the ES6 import statements into CommonJS `require()` that browserify understands. This also enables us to use newer syntax available in ES6 and beyond without worrying about browser compatibility. +इसके बाद, `node_modules` से सभी निर्भरताओं सहित स्रोत कोड को पैकेज.जेसन में परिभाषित [ब्राउज़रलिस्ट](https://browsersl.ist/) आवश्यकता से मेल खाने के साथ-साथ कॉमनजेएस में ईएस 6 आयात विवरण बनाने के लिए बैबल का उपयोग करके ट्रांसप्लड किया जाता है: `require()` जो ब्राउज़राइज़ समझता है। यह हमें ब्राउज़र संगतता के बारे में चिंता किए बिना ES6 और उससे आगे उपलब्ध नए सिंटैक्स का उपयोग करने में भी सक्षम बनाता है। बंडलिंग के बाद, लेकिन फ़ाइल में लिखा जाने से पहले, कोड को `pretty-fast` के माध्यम से पार किया जाता है, यदि यह न्यूनतम नहीं है, तो इसे साफ कर दिया जाता है ताकि अंतिम स्वरूपण कुछ संरचनात्मक रूप से अधिक संबंधित हो (हम उम्मीद करते हैं कि p5.js स्रोत कोड पढ़ा और जांचा जा सकता है यदि इच्छित है)। @@ -227,7 +236,7 @@ mochaChrome mochaTest ``` -This step differs from `mochaChrome` in that it is run in node.js instead of in Chrome and only tests a small subset of features in the library. Most features in p5.js will require a browser environment, so this set of tests should only be expanded if the new tests really don't need a browser environment. +यह चरण `mochaChrome` से भिन्न है क्योंकि यह क्रोम के बजाय नोड.जेएस में चलाया जाता है और लाइब्रेरी में केवल सुविधाओं के एक छोटे उपसमूह का परीक्षण करता है। p5.js में अधिकांश सुविधाओं के लिए ब्राउज़र वातावरण की आवश्यकता होगी, इसलिए परीक्षणों के इस सेट का विस्तार केवल तभी किया जाना चाहिए जब नए परीक्षणों को वास्तव में ब्राउज़र वातावरण की आवश्यकता न हो। ``` nyc:report @@ -257,17 +266,17 @@ grunt watch:quick वॉच कार्य विभिन्न फ़ाइलों के लिए बदलावों की निगरानी करेंगे और कौन से फ़ाइलों में क्या परिवर्तन हुआ है, उस अनुसार संबंधित कार्यों को चलाएगे। ये सभी कार्य एक ही चीज़ करते हैं, जिसका केवल विस्तार है। -The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code. +`watch` कार्य स्रोत कोड में परिवर्तनों का पता लगाने पर पूर्ण डिफ़ॉल्ट कार्य चलाने के समान सभी बिल्ड और परीक्षण चलाएगा। -The `watch:main` task will run the library build and tests but not rebuild the reference on detecting changes in the source code. +`watch:main` कार्य लाइब्रेरी निर्माण और परीक्षण चलाएगा लेकिन स्रोत कोड में परिवर्तनों का पता लगाने पर संदर्भ का पुनर्निर्माण नहीं करेगा। -The `watch:quick` task will run the library build only on detecting changes in the source code. +`watch:quick` कार्य केवल स्रोत कोड में परिवर्तनों का पता लगाने पर लाइब्रेरी बिल्ड चलाएगा। -Depending on what you are working on, choosing the most minimal watch task here can save you from having to manually run a rebuild whenever you want to make some changes. +आप जिस पर काम कर रहे हैं उसके आधार पर, यहां सबसे न्यूनतम घड़ी कार्य चुनने से आप जब भी कुछ बदलाव करना चाहें तो मैन्युअल रूप से पुनर्निर्माण चलाने से बच सकते हैं। --- -## Release process +## रिहाई प्रक्रिया कृपया रिलीज [`release_process.md`](release_process.md) देखें। @@ -277,55 +286,55 @@ Depending on what you are working on, choosing the most minimal watch task here कभी-कभी, समीक्षा के लिए जितने भी जटिल पीआर हैं, उन्हें स्थानीय रूप से परीक्षण करने के लिए गिट के जटिल कमांड की आवश्यकता हो सकती है। भाग्य से, गिटहब सीएलआई टूल इस प्रक्रिया और अधिक के साथ बहुत मदद कर सकता है। -### Reply templates +### उत्तर टेम्पलेट -A handy GitHub feature that you can use is the [Saved Replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) feature, which is available to use when authoring a reply to issues or pull requests. Some of the workflow described above may require responding to issues or PRs with identical or very similar replies (redirecting questions to the forum, accepting an issue for fixing, etc.), and using Saved Replies can just ever so slightly make this more efficient. +एक आसान गिटहब सुविधा जिसका आप उपयोग कर सकते हैं वह है [सहेजे गए उत्तर](https://docs.github.com/en/get-started/writing-on-github/working-with-saveled-replies/about-saveled-replies) सुविधा, जो मुद्दों या पुल अनुरोधों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ मुद्दों या पीआर का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी मुद्दे को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। -Below are some of the Saved Replies that are being used by p5.js maintainers. You can use them yourself or create your own! +नीचे कुछ सहेजे गए उत्तर दिए गए हैं जिनका उपयोग p5.js अनुरक्षकों द्वारा किया जा रहा है। आप उन्हें स्वयं उपयोग कर सकते हैं या अपना खुद का बना सकते हैं! -##### Closing: Can’t Reproduce +##### समापन: पुनरुत्पादन नहीं किया जा सकता -> We're not able to reproduce this, but please feel free to reopen if you can provide a code sample that demonstrates the issue. Thanks! +> हम इसे पुन: पेश करने में सक्षम नहीं हैं, लेकिन यदि आप कोई कोड नमूना प्रदान कर सकते हैं जो समस्या को दर्शाता है तो कृपया बेझिझक इसे दोबारा खोलें। धन्यवाद! -##### Closing: Need Snippet +##### समापन: स्निपेट की आवश्यकता है -> I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks! +> मैं इसे संगठनात्मक उद्देश्यों के लिए बंद कर रहा हूं। यदि आप एक कोड स्निपेट प्रदान कर सकते हैं जो समस्या को दर्शाता है तो कृपया फिर से खोलें। धन्यवाद! -##### Closing: Use the Forum +##### समापन: फोरम का उपयोग करें -> The GitHub issues here are a good place for bugs and issues with the p5.js library itself. For questions about writing your own code, tests, or following tutorials, the [forum](https://discourse.processing.org/) is the best place to post. Thanks! +> यहां GitHub मुद्दे p5.js लाइब्रेरी के बग और मुद्दों के लिए एक अच्छी जगह हैं। अपना स्वयं का कोड लिखने, परीक्षण करने या ट्यूटोरियल का अनुसरण करने के बारे में प्रश्नों के लिए, [फोरम](https://discourse.processing.org/) पोस्ट करने के लिए सबसे अच्छी जगह है। धन्यवाद! -##### Closing: GSOC +##### समापन: जीएसओसी -> Thanks! The best place to discuss GSOC proposals is on our [forum](https://discourse.processing.org/c/summer-of-code). +> धन्यवाद! जीएसओसी प्रस्तावों पर चर्चा करने के लिए सबसे अच्छी जगह हमारा [फोरम](https://discourse.processing.org/c/summer-of-code) है। -##### Closing: Access +##### समापन: प्रवेश -> I'm not seeing a lot of interest in this feature, and we don't have a clear explanation of how it [expands access](access.md), so I will close this for now. If an access statement can be added to the issue request, please feel welcome to reopen. +> मुझे इस सुविधा में बहुत अधिक रुचि नहीं दिख रही है, और हमारे पास इसकी स्पष्ट व्याख्या नहीं है कि यह कैसे [पहुंच का विस्तार करता है] (access.md), इसलिए मैं इसे अभी बंद कर दूंगा। यदि समस्या अनुरोध में एक एक्सेस स्टेटमेंट जोड़ा जा सकता है, तो कृपया पुनः खोलने का स्वागत करें। -> We do not see a further explanation of how this issue [expands access](access.md), so I will close this issue for now. If a more detailed access statement can be added to the feature request, please feel welcome to reopen it. Thank you! +> हमें इस बारे में कोई और स्पष्टीकरण नहीं दिख रहा है कि यह मुद्दा कैसे [पहुंच का विस्तार करता है] (access.md), इसलिए मैं इस मुद्दे को अभी के लिए बंद कर दूंगा। यदि फीचर अनुरोध में अधिक विस्तृत एक्सेस स्टेटमेंट जोड़ा जा सकता है, तो कृपया इसे फिर से खोलने का स्वागत करें। धन्यवाद! -##### Closing: Addon +##### समापन: ऐडऑन -> I think this function is beyond the scope of the p5.js API (we try to keep it as minimal as possible), but it could be a great starting point for an addon library. See the docs here for how to create an addon: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) +> मुझे लगता है कि यह फ़ंक्शन p5.js API के दायरे से परे है (हम इसे यथासंभव न्यूनतम रखने की कोशिश करते हैं), लेकिन यह एक ऐडऑन लाइब्रेरी के लिए एक बेहतरीन शुरुआती बिंदु हो सकता है। ऐडऑन बनाने के तरीके के लिए यहां दस्तावेज़ देखें: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) -##### Closing PR: Need Issue First +##### समापन पीआर: पहले मुद्दे की आवश्यकता है -> Thank you. As a reminder, issues need to be opened before pull requests are opened and tagged with the issue. This is necessary for tracking development and keeping discussion clear. Thanks! +> धन्यवाद. एक अनुस्मारक के रूप में, पुल अनुरोधों को खोलने और समस्या के साथ टैग करने से पहले मुद्दों को खोला जाना चाहिए। विकास पर नज़र रखने और चर्चा को स्पष्ट रखने के लिए यह आवश्यक है। धन्यवाद! -##### Approve issue for fixing +##### समस्या को ठीक करने के लिए स्वीकृति दें -> You can go ahead with a fix. Thanks. +> आप सुधार के साथ आगे बढ़ सकते हैं। धन्यवाद। -##### Merged PR +##### मर्ज किया गया पीआर -> Looks good. Thanks! +> अच्छा लग रहा है. धन्यवाद! -### GitHub CLI +### गिटहब सीएलआई -Reviewing a complex PR can be difficult with complex git commands required to get the PR's version of code locally for you to test. Fortunately, the [GitHub CLI](https://cli.github.com/) tool can help greatly with this process and more. +आपके परीक्षण के लिए स्थानीय स्तर पर कोड का पीआर संस्करण प्राप्त करने के लिए आवश्यक जटिल गिट कमांड के साथ एक जटिल पीआर की समीक्षा करना मुश्किल हो सकता है। सौभाग्य से, [गिटहब CLI](https://cli.github.com/) टूल इस प्रक्रिया और बहुत कुछ में काफी मदद कर सकता है। -क्लाइंट को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पीआर की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout` मेन। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पीआर में से! +CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पीआर की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout` मेन। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पीआर में से! गिटहब एसईएलआई में बहुत सारे अन्य कमांड भी उपलब्ध हैं जो आपको उपयोगी हो सकते हैं या नहीं मिल सकते हैं, लेकिन यह एक अच्छा उपकरण है जिसका आपके आसपास होना है किसी भी मामले में। @@ -333,7 +342,7 @@ Reviewing a complex PR can be difficult with complex git commands required to ge नए मुद्दों या पीआर के लिए "मुद्दे" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। -![Cropped screenshot of the top right corner of a GitHub repository page showing a series of buttons in the center from left to right: Sponsor, Watch, Fork, Starred.](images/github-repo-metrics.png) +![गिटहब रिपॉजिटरी पेज के ऊपरी दाएं कोने का क्रॉप किया गया स्क्रीनशॉट, जो बाएं से दाएं केंद्र में बटनों की एक श्रृंखला दिखा रहा है: प्रायोजक (Sponsor), नजर रखना (Watch), शूल (Fork), तारांकित (Starred)](images/github-repo-metrics.png) रेपो को देखकर, नई समस्याएं, नई पुल रिक्वेस्ट्स, आपके उपयोगकर्ता हैंडल का उल्लेख, और अन्य गतिविधियां, जिनकी आपने रेपो में सब्सक्राइब की हैं, इन घटनाओं को आपके [सूचना पृष्ठ](https://github.com/notifications) पर सूचनाएं के रूप में भेजी जाती हैं, जिन्हें आप स्वीकार कर सकते हैं या उन्हें ईमेल इनबॉक्स की तरह पढ़कर या खारिज कर सकते हैं। From 793d682958a18fe99ae321293dc9e57c0a4629a3 Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Mon, 18 Mar 2024 22:51:22 +0530 Subject: [PATCH 3/8] fix relative links and hyperlinks --- contributor_docs/hi/steward_guidelines.md | 30 +++++++++++------------ 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index b857633c35..5afc18ff40 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -81,17 +81,17 @@ Bबग रिपोर्ट समस्याओं को "बग मिल - क्या यह p5.js के लिए पहले से लिखे गए विशिष्ट रेखाचित्रों के साथ टकराव करेगा? - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? - - उदाहरण के लिए, `join(["hello", "world!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। + - उदाहरण के लिए, `join(["हैलो", "वर्ल्ड!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। 3. यदि पहुँच आवश्यकता और अन्य विचारों को पूरा किया गया है, तो नई सुविधा अनुरोध को प्रारंभ किया जाना चाहिए जब तक कि कार्य पीआर की ओर न हो। नई सुविधाओं के पीआर की समीक्षा प्रक्रिया नीचे विवरणित है। ### सुविधा विस्तार सुविधा विस्तार समस्याओं का उपयोग करना चाहिए "मौजूदा सुविधा विस्तार" समस्या टेम्प्लेट का। प्रक्रिया नई सुविधा अनुरोधों के साथ बहुत समान है। नई सुविधा अनुरोध और सुविधा विस्तार के बीच का अंतर कभी-कभी कम हो सकता है। सुविधा विस्तार मुख्य रूप से p5.js के मौजूदा कार्यों के साथ संबंधित होता है जबकि नई सुविधा अनुरोध पूरी तरह से नए कार्यों को जोड़ने का अनुरोध कर सकता है। -1. नई सुविधा अनुरोधों की तरह, सुविधा विस्तार को केवल उन्हें स्वीकार किया जाना चाहिए अगर वे p5.js के पहुँच को बढ़ाते हैं। कृपया [ऊपर दिए गए खंड](./steward_guidelines.md/#सुविधा-अनुरोध) का बिंदु 1 देखें। +1. नई सुविधा अनुरोधों की तरह, सुविधा विस्तार को केवल उन्हें स्वीकार किया जाना चाहिए अगर वे p5.js के पहुँच को बढ़ाते हैं। कृपया [ऊपर दिए गए खंड](./steward_guidelines.md#सुविधा-अनुरोध) का बिंदु 1 देखें। 2. सुविधा विस्तारों के समावेश की मान्यता देने की मानदंड नए सुविधा अनुरोधों के लिए तुलनात्मक होती हैं, लेकिन भिन्नता तब की जाती है जब संभावित ब्रेकिंग बदलावों पर विशेष ध्यान दिया जाता है। -- मौजूदा कार्यों को संशोधित करते समय, सभी पिछले मान्य और दस्तावेजित कार्य साकार तरीके से बर्ताव करने चाहिए। + - मौजूदा कार्यों को संशोधित करते समय, सभी पिछले मान्य और दस्तावेजित कार्य साकार तरीके से बर्ताव करने चाहिए। 3. सुविधा विस्तारों को कम से कम एक स्टीवर्ड या मेंटेनर द्वारा मंजूर किया जान| चाहिए जब काम की ओर प्रीआर किया जाना चाहिए। सुविधा विस्तार के लिए पीआर समीक्षा प्रक्रिया नीचे विवरणित है। @@ -110,7 +110,7 @@ Bबग रिपोर्ट समस्याओं को "बग मिल प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। स्टीवर्ड और मेंटेनर्स रिपॉजिट्रीज के पुश एक्सेस रख सकते हैं लेकिन जब भी कोड योगदान किया जाता है, तो वे पुल रिक्वेस्ट की समीक्षा करने को प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: - पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)| -- लगभग सभी पुल रिक्वेस्ट के साथ संबंधित इस्स्यूज खोले और पहले चर्चा की जानी चाहिए, अर्थात पुश संबंधित इस्स्यूज के पहले पीआर की समीक्षा किया जाना चाहिए किसी भी स्टीवर्ड या मेंटेनर द्वारा। [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए +- लगभग सभी पुल रिक्वेस्ट के साथ संबंधित इस्स्यूज खोले और पहले चर्चा की जानी चाहिए, अर्थात पुश संबंधित इस्स्यूज के पहले पीआर की समीक्षा किया जाना चाहिए किसी भी स्टीवर्ड या मेंटेनर द्वारा। [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुले मुद्दे की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए मुद्दे खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक मुद्दा खोलें। - यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पीआर विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। @@ -119,9 +119,9 @@ Bबग रिपोर्ट समस्याओं को "बग मिल सरल सुधार, जैसे कि छोटी टाइपो फिक्स, को मर्ज एक्सेस वाले किसी भी व्यक्ति द्वारा सीधे मर्ज किया जा सकता है। यह सुनिश्चित करने के लिए कि स्वचालित सीआई परीक्षण पास हो गया है, पीआर "फ़ाइलें परिवर्तित (files changed)" टैब पर जांचें। -![गिटहब पर पुल अनुरोध देखते समय "फ़ाइलें परिवर्तित (Files changed)" टैब](images/files-changed.png) +![गिटहब पर पुल अनुरोध देखते समय "फ़ाइलें परिवर्तित (Files changed)" टैब](../images/files-changed.png) -![गिटहब पुल अनुरोध पर "सभी चेक पास हो गए हैं (All checks have passed)" संकेतक, मर्ज बटन के ऊपर हाइलाइट किया गया है](images/all-checks-passed.png) +![गिटहब पुल अनुरोध पर "सभी चेक पास हो गए हैं (All checks have passed)" संकेतक, मर्ज बटन के ऊपर हाइलाइट किया गया है](../images/all-checks-passed.png) ### बग फ़िक्स @@ -137,13 +137,13 @@ Bबग रिपोर्ट समस्याओं को "बग मिल 4. यदि कोई अतिरिक्त परिवर्तन आवश्यक हो, तो पंक्ति टिप्पणियाँ यहाँ जोड़ी [जानी चाहिए](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)। - एक सुझाव ब्लॉक का उपयोग किया जा सकता है विशिष्ट परिवर्तनों का सुझाव देने के लिए: - ![गिटहब पुल अनुरोध में कोड पर टिप्पणी लिखते समय परिवर्तन का सुझाव बटन](images/suggest-change.png)\ - ![एक सुझाया गया परिवर्तन "सुझाव (suggestion)" टैग के साथ कोड बाड़ के भीतर दिखाई देता है](images/suggested-value-change.png)\ - ![सुझाए गए परिवर्तन का पूर्वावलोकन अंतर के रूप में किया गया](images/suggestion-preview.png) + ![गिटहब पुल अनुरोध में कोड पर टिप्पणी लिखते समय परिवर्तन का सुझाव बटन](../images/suggest-change.png)\ + ![एक सुझाया गया परिवर्तन "सुझाव (suggestion)" टैग के साथ कोड बाड़ के भीतर दिखाई देता है](../images/suggested-value-change.png)\ + ![सुझाए गए परिवर्तन का पूर्वावलोकन अंतर के रूप में किया गया](../images/suggestion-preview.png) - यदि कई परिवर्तन की आवश्यकता है, तो एकाधिक बार एकल-लाइन टिप्पणियाँ न जोड़ें। बजाय इसके, कई-लाइन टिप्पणियाँ और एक ही परिवर्तन के लिए एक मांग करने के लिए यहाँ दस्तावेज़ की प्रक्रिया का [पालन करें](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)। - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ - ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) + ![The "comment" option circled within the GitHub Finish Review menu](../images/comment-review.png) 5. एक बार पीआर की समीक्षा की गई है और कोई अतिरिक्त परिवर्तन आवश्यक नहीं है, तो एक स्टीवर्ड पिछले चरण में "मंजूर" चयन करके पीआर को "मंजूर" चिह्नित कर सकता है, जिसमें अतिरिक्त टिप्पणियों के साथ या बिना चयन किया जा सकता है। स्टीवर्ड फिर अगर चाहें तो एक अन्य स्टीवर्ड या रक्षक से अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज पहुंच है, तो पीआर को मर्ज कर सकता है, या रक्षक से मर्ज का अनुरोध कर सकता है। @@ -172,7 +172,7 @@ Bबग रिपोर्ट समस्याओं को "बग मिल यह खंड सामान्य निर्माण सेटअप या आदेश का विवरण नहीं करेगा, बल्कि विवरणों के पीछे क्या हो रहा है उसके बारे में जानकारी देगा। कृपया अधिक विस्तृत निर्माण जानकारी के लिए [योगदानकर्ता दिशानिर्देश](Add link to contributor guidlines) देखें। -`Gruntfile.js` फ़ाइल p5.js के मुख्य निर्माण परिभाषणों को संबोधित करती है। पुस्तकालय और दस्तावेज़ीकरण निर्माण के लिए उपयोग किए जाने वाले विभिन्न उपकरणों में `Grunt`, `Browserify`, `YUIDoc`, `ESLint`, `Babel`, `Uglify`, और `Mocha` शामिल हैं। यह हमारे लिए `डिफ़ॉल्ट` टास्क के साथ शुरू करने और वहां से पिछले काम करने में मददगार हो सकता है। इस विवरण के दौरान `Gruntfile.js` दस्तावेज़ को खोलना भी उपयोगी हो सकता है। +`Gruntfile.js` फ़ाइल p5.js के मुख्य निर्माण परिभाषणों को संबोधित करती है। पुस्तकालय और दस्तावेज़ीकरण निर्माण के लिए उपयोग किए जाने वाले विभिन्न उपकरणों में `Grunt`, `Browserify`, `YUIDoc`, `ESLint`, `Babel`, `Uglify`, और `Mocha` शामिल हैं। यह हमारे लिए `default (डिफ़ॉल्ट)` टास्क के साथ शुरू करने और वहां से पिछले काम करने में मददगार हो सकता है। इस विवरण के दौरान `Gruntfile.js` दस्तावेज़ को खोलना भी उपयोगी हो सकता है। ### मुख्य निर्माण कार्य @@ -192,7 +192,7 @@ grunt.registerTask('lint', ['lint:source', 'lint:samples']); `lint:samples` कार्य पहले `yui` कार्य को चलाएगा जिसमें स्वयं `yuidoc: prod`, `clean:reference`, और `minjson` शामिल हैं, जो स्रोत कोड से दस्तावेज़ को JSON दस्तावेज़ में निकालते हैं, हटाते हैं पिछले चरण से अप्रयुक्त फ़ाइलें, और उत्पन्न JSON फ़ाइल को क्रमशः `data.min.json` में छोटा करें। -`lint:samples` में अगला है `eslint-samples:source`, जो एक कस्टम लिखित कार्य है जिसकी परिभाषा [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js) में है ; यह दस्तावेज़ीकरण उदाहरण कोड की जांच करने के लिए ESLint चलाएगा ताकि यह सुनिश्चित किया जा सके कि वे बाकी p5.js के समान कोडिंग कन्वेंशन का पालन करते हैं (`yui` यहां पहले चलाया गया है क्योंकि हमें उदाहरणों को लिंट करने से पहले JSON फ़ाइल बनाने की आवश्यकता है ). +`lint:samples` में अगला है `eslint-samples:source`, जो एक कस्टम लिखित कार्य है जिसकी परिभाषा [tasks/build/eslint-samples.js](../tasks/build/eslint-samples.js) में है ; यह दस्तावेज़ीकरण उदाहरण कोड की जांच करने के लिए ESLint चलाएगा ताकि यह सुनिश्चित किया जा सके कि वे बाकी p5.js के समान कोडिंग कन्वेंशन का पालन करते हैं (`yui` यहां पहले चलाया गया है क्योंकि हमें उदाहरणों को लिंट करने से पहले JSON फ़ाइल बनाने की आवश्यकता है ). #### `test` कार्य @@ -206,7 +206,7 @@ grunt.registerTask("test", ["build", "connect:server", "mochaChrome", "mochaTest grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browserify:test"]); ``` -`browserify` से शुरू होने वाले कार्य [./tasks/build/browserify.js](tasks/build/browserify.js) में परिभाषित होते हैं। इनमें सभी मुख्य कदम होते हैं जो बहुत से उपयोगकर्ता कोड फ़ाइलों को संग्रहीत और एक में बनाने के लिए हैं: +`browserify` से शुरू होने वाले कार्य [tasks/build/browserify.js](../tasks/build/browserify.js) में परिभाषित होते हैं। इनमें सभी मुख्य कदम होते हैं जो बहुत से उपयोगकर्ता कोड फ़ाइलों को संग्रहीत और एक में बनाने के लिए हैं: - `browserify` p5.js बनाता है जबकि `browserify:min` अगले कदम में संक्षिप्त किए जाने वाले एक बीच की फ़ाइल को बनाता है। `browserify` और `browserify:min` के बीच अंतर यह है कि `browserify:min` FES के लिए कार्यात्मक नहीं होने वाले डेटा को नहीं समाहित करता। - `uglify` `browserify:min` की उत्पादित फ़ाइल को छोटा करता है और अंतिम `p5.min.js` में इसे छोटा करता है (इस कदम की विन्यासिकता मुख्य `Gruntfile.js` में है)। @@ -230,7 +230,7 @@ connect:server mochaChrome ``` -यह कदम [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js) में परिभाषित है। यह प्यूपिटीयर का उपयोग करता है जो क्रोम का एक हेडलेस संस्करण स्पिन करता है जिसे रिमोट नियंत्रित किया जा सकता है और `./test` फ़ोल्डर में `HTML` फ़ाइलों के साथ जुड़े परीक्षणों को चलाता है, जिसमें लाइब्रेरी के अनमिनिफ़ाइड और मिनिफ़ाइड संस्करणों को यूनिट परीक्षण सुइटों के साथ परीक्षण किया जाता है साथ ही सभी संदर्भ उदाहरणों का परीक्षण किया जाता है। +यह कदम [tasks/test/mocha-chrome.js](../tasks/test/mocha-chrome.js) में परिभाषित है। यह प्यूपिटीयर का उपयोग करता है जो क्रोम का एक हेडलेस संस्करण स्पिन करता है जिसे रिमोट नियंत्रित किया जा सकता है और `./test` फ़ोल्डर में `HTML` फ़ाइलों के साथ जुड़े परीक्षणों को चलाता है, जिसमें लाइब्रेरी के अनमिनिफ़ाइड और मिनिफ़ाइड संस्करणों को यूनिट परीक्षण सुइटों के साथ परीक्षण किया जाता है साथ ही सभी संदर्भ उदाहरणों का परीक्षण किया जाता है। ``` mochaTest @@ -342,7 +342,7 @@ CLI को स्थानीय रूप से लिंक करने क नए मुद्दों या पीआर के लिए "मुद्दे" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। -![गिटहब रिपॉजिटरी पेज के ऊपरी दाएं कोने का क्रॉप किया गया स्क्रीनशॉट, जो बाएं से दाएं केंद्र में बटनों की एक श्रृंखला दिखा रहा है: प्रायोजक (Sponsor), नजर रखना (Watch), शूल (Fork), तारांकित (Starred)](images/github-repo-metrics.png) +![गिटहब रिपॉजिटरी पेज के ऊपरी दाएं कोने का क्रॉप किया गया स्क्रीनशॉट, जो बाएं से दाएं केंद्र में बटनों की एक श्रृंखला दिखा रहा है: प्रायोजक (Sponsor), नजर रखना (Watch), शूल (Fork), तारांकित (Starred)](../images/github-repo-metrics.png) रेपो को देखकर, नई समस्याएं, नई पुल रिक्वेस्ट्स, आपके उपयोगकर्ता हैंडल का उल्लेख, और अन्य गतिविधियां, जिनकी आपने रेपो में सब्सक्राइब की हैं, इन घटनाओं को आपके [सूचना पृष्ठ](https://github.com/notifications) पर सूचनाएं के रूप में भेजी जाती हैं, जिन्हें आप स्वीकार कर सकते हैं या उन्हें ईमेल इनबॉक्स की तरह पढ़कर या खारिज कर सकते हैं। From 858c8cc8d799739e2787ccb85da5c708d68d392d Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Wed, 20 Mar 2024 00:35:31 +0530 Subject: [PATCH 4/8] feat: refac the wrting style for lines 0-100 --- contributor_docs/hi/steward_guidelines.md | 72 +++++++++++------------ 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index 5afc18ff40..6514f91470 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -33,75 +33,75 @@ ## समस्याएँ -हम अधिकांश स्रोत कोड योगदानों को एक समस्या के साथ शुरू करने की प्रोत्साहना करते हैं, और इस तरह, समस्याओं में अधिकांश चर्चाएँ होंगी। समस्या को समीक्षा करने के लिए लेने के चरण वास्तव में यह निर्भर करेगा कि यह कैसी समस्या है। रेपो विभिन्न प्रकार की समस्याओं को बेहतर ढंग से व्यवस्थित करने और समस्या लेखकों को अपनी समस्याओं के बारे में सभी प्रासंगिक जानकारी प्रदान करने के लिए [गिटहब समस्या टेम्पलेट](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) का उपयोग करता है। समस्या की समीक्षा की पहली कदम अक्सर भरे गए टेम्पलेट को देखना होगा और यह तय करना होगा कि क्या आपको अतिरिक्त जानकारी की आवश्यकता है (जैसे कि कुछ क्षेत्र भरे नहीं गए हों या गलत टेम्पलेट का प्रयोग किया गया हो)। +हम अधिकांश स्रोत कोड योगदानों को एक समस्या के साथ शुरू करने की प्रोत्साहना करते हैं, क्योंकि समस्या वह स्थान हैं जहां अधिकांश चर्चाएं होंगी। किसी मुद्दे की समीक्षा करते समय उठाए जाने वाले कदम इस बात पर निर्भर करेंगे कि यह किस प्रकार का मुद्दा है। रेपो विभिन्न प्रकार की समस्याओं को बेहतर ढंग से व्यवस्थित करने और समस्या लेखकों को अपनी समस्याओं के बारे में सभी प्रासंगिक जानकारी प्रदान करने के लिए [गिटहब समस्या टेम्पलेट](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) का उपयोग करती है। समस्या की समीक्षा का पहला कदम अक्सर भरे गए टेम्पलेट को देखना होगा और यह तय करना होगा कि क्या आपको अतिरिक्त जानकारी की आवश्यकता है (जैसे कि कुछ क्षेत्र भरे नहीं गए हों या गलत टेम्पलेट का प्रयोग किया गया हो)। ### बग रिपोर्ट -Bबग रिपोर्ट समस्याओं को "बग मिला" (Found a bug) समस्या टेम्पलेट का प्रयोग करना चाहिए। बग रिपोर्ट को समाधान करने के लिए निम्नलिखित कार्यक्रम सामान्य होता है: +बग रिपोर्ट समस्याओं को "बग मिला" (`Found a bug`) समस्या टेम्पलेट का प्रयोग करना चाहिए। बग रिपोर्ट का समाधान करने के लिए निम्नलिखित कार्यक्रम सामान्य होता है: 1. बग को अनुकृत करें - - टेम्पलेट का उद्देश्य एक समीक्षक को समस्या को श्रद्धापूर्वक प्रयास करने के लिए पर्याप्त जानकारी प्रदान करना है। - - यदि रिपोर्ट की गई समस्या प्राथमिकता सूची में नहीं है (p5.js, p5.js-वेबसाइट, या अन्यत्र): - - यदि आपके पास इसका उपयोगकर्ता है, तो बग रिपोर्ट को संबंधित रेपो में स्थानांतरित करें। + - टेम्प्लेट का लक्ष्य समीक्षक को संबंधित बग को दोहराने का प्रयास करने के लिए पर्याप्त जानकारी प्रदान करना है। + - यदि रिपोर्ट किया गया बग वर्तमान रेपो के लिए प्रासंगिक नहीं है (p5.js, p5.js-वेबसाइट, या अन्यत्र): + - यदि आपके पास संबंधित रेपो तक पहुंच है, तो इसे स्थानांतरित करें। - अन्यथा, एक टिप्पणी छोड़ें जिसमें बग रिपोर्ट को कहां फाइल किया जाना चाहिए (सीधा लिंक सहित) और समस्या को बंद करें। - - बग रिपोर्ट का समीक्षा करने का पहला कदम यह है कि क्या एक बग प्रतिरूपण के लिए पर्याप्त जानकारी प्रदान की गई है, और यदि हां, तो समान रूप से बग को जैसा वर्णित किया गया है उसी रूप में प्रतिरूपित करने का प्रयास करें। + - बग रिपोर्ट की समीक्षा करने में पहला कदम यह देखना है कि बग प्रतिकृति के लिए पर्याप्त जानकारी प्रदान की गई है या नहीं, और यदि हां, तो वर्णित अनुसार बग को दोहराने का प्रयास करें। 2. अगर बग प्रतिरूपित किया जा सकता है: - किसी विशेष बग को सही करने का सबसे अच्छा तरीका निर्धारित करने के लिए कुछ चर्चा की जा सकती है। कभी-कभी, यह सीधा हो सकता है; कभी-कभी, यह कठिन हो सकता है। कृपया इस निर्णय को एक मामला-दर-मामला आधार पर लेते समय [p5.js' डिज़ाइन सिद्धांतों](design_principles.md) का उल्लेख करें। - यदि समस्या लेखक ने समस्या में इस संकेत किया है कि वे एक सुधार योगदान देने के लिए तत्पर हैं: - - कॉमेंट छोड़कर समस्या को सुधारने के लिए समस्या लेखक को स्वीकृत करें और उन्हें समस्या के लिए असाइन करें। "असाइनी" के बगल में "टोलिया" का उपयोग करें। + - कॉमेंट छोड़कर समस्या को सुधारने के लिए समस्या लेखक को स्वीकृत करें और उन्हें समस्या के लिए असाइन करें। "असाइनी (`Assignee`)" के बगल में "टोलिया (`cog button`)" का उपयोग करें। - यदि समस्या लेखक कोई सुधार नहीं करना चाहते हैं: - बग प्रतिरूपित होने का स्वीकृति छोड़ें। - - खुद को सुधारने का प्रयास करें या बग को ठीक करने की आवश्यकता होने पर मदद की जरूरत के लिए `मदद चाहिए (help wanted)` लेबल जोड़ें। + - बग को स्वयं ठीक करने का प्रयास करें या बग को ठीक करने की आवश्यकता होने पर मदद की जरूरत के लिए `मदद चाहिए (help wanted)` लेबल जोड़ें। 3. यदि बग प्रतिरूपित नहीं हो सकता है: - - अतिरिक्त जानकारी के लिए पूछें यदि पहले से ही टेम्पलेट में नहीं शामिल किया गया है (p5.js संस्करण, ब्राउज़र संस्करण, ओएस संस्करण आदि)। + - अअतिरिक्त जानकारी के लिए पूछें जो पहले से ही टेम्पलेट में प्रदान नहीं की गई है (p5.js संस्करण, ब्राउज़र संस्करण, ओएस संस्करण आदि)। - यदि आपका परीक्षण पर्याप्त नहीं है जो समस्या में रिपोर्ट किया गया है (उदाहरण के लिए, एक अलग ब्राउज़र या ओएस): - एक टिप्पणी छोड़ें कि आप अपने विशिष्ट पर्यावरण में प्रतिरूपित नहीं कर सकते हैं। - बग को प्रतिरूपित करने के लिए `मदद चाहिए (help wanted)` लेबल जोड़ें और समस्या को जिन निर्दिष्ट सेटअप के साथ प्रतिरूपित किया गया है, उनसे बग को प्रतिरूपित करने के लिए कहें। - - कभी-कभी, बग केवल वेब संपादक का उपयोग करते समय ही होते हैं और स्थानीय टेस्ट करते समय नहीं। इस मामले में, समस्या को [वेब संपादक रेपो](https://github.com/processing/p5.js-web-editor) की ओर पुनर्निर्देशित किया जाना चाहिए। + - कभी-कभी, बग केवल वेब संपादक के उपयोग करते समय ही होते हैं और स्थानीय टेस्ट करते समय नहीं। इस मामले में, समस्या को [वेब संपादक रेपो](https://github.com/processing/p5.js-web-editor) की ओर पुनर्निर्देशित किया जाना चाहिए। - यदि प्रतिरूपण बाद में संभव है, तो कदम 2 पर वापस जाएं। -4. यदि बग उपयोगकर्ता द्वारा प्रदान किए गए कोड से आता है और p5.js' व्यवहार नहीं: - - यह निर्धारित करें कि क्या p5.js' दस्तावेज़ीकरण, कोड कार्यान्वयन, या मित्रसंपर्क त्रुटि प्रणाली को सुधारा जा सकता है ताकि वही गलती फिर से न हो। +4. यदि बग उपयोगकर्ता द्वारा प्रदान किए गए कोड से आता है और p5.js के व्यवहार से नहीं: + - यह निर्धारित करें कि क्या p5.js दस्तावेज़ीकरण, कोड कार्यान्वयन, या मित्रसंपर्क त्रुटि प्रणाली को सुधारा जा सकता है ताकि वही गलती फिर से न हो। - कृपया आगे किसी भी परिवर्तन के लिए [मंच](https://discourse.processing.org/) या [डिस्कॉर्ड](https://discord.com/invite/SHQ8dH25r9) पर और अधिक प्रश्न अद्यतन करें और यदि p5.js में कोई अधिक परिवर्तन नहीं करना है, तो समस्या को बंद करें। ### सुविधा अनुरोध -सुविधा अनुरोध समस्याएँ "नई सुविधा अनुरोध" समस्या टेम्पलेट का उपयोग करना चाहिए। सुविधा अनुरोध को सम्बोधित करने के लिए निम्नलिखित वर्कफ़्लो सामान्य है: - -1. p5.js की पहुंच बढ़ाने के रूप में, सुविधा अनुरोध को यह साबित करना होगा कि यह प्रोजेक्ट कैसे p5.js के इतिहास में तब भी समुदायों के लिए पहुंच को बढ़ाता है जब वे इस क्षेत्र में नाज़िम किए गए हैं। अधिक विवरण [यहां](access.md) उपलब्ध हैं। - - यदि कोई सुविधा अनुरोध "पहुंच बढ़ाने" क्षेत्र को पर्याप्त रूप से भरा नहीं है, तो आप समस्या लेखक से सुविधा कैसे पहुंच बढ़ाती है, इसके बारे में पूछ सकते हैं। - - सुविधा का पहुंच का बयान किसी अलग समुदाय सदस्य, समस्या समीक्षकों सहित, द्वारा प्रदान किया जा सकता है। -2. नई सुविधा अनुरोध को निम्नलिखित मानकों के आधार पर समाविष्टि के लिए मूल्यांकन किया जा सकता है। - - क्या सुविधा परियोजना के धारा और [डिज़ाइन सिद्धांतों](design_principles.md) में फिट है? - - उदाहरण के लिए, एक नई आकृति जोड़ने का अनुरोध किया जा सकता है, लेकिन ब्राउज़र-आधारित आईओटी प्रोटोकॉल को ग्रहण करने का अनुरोध असंगत होगा। - - सम्पूर्ण रूप से, p5.js का धारा संक्षिप्त होना चाहिए ताकि अनियमित उपयोग की सुविधाओं से बचा जा सके। - - यदि कोई सुविधा p5.js के धारा में फिट नहीं होती है, तो सुझाव दें कि समस्या लेखक सुविधा को एक ऐड-ऑन पुस्तकालय के रूप में अमल करें। - - यदि स्पष्ट नहीं है कि यह फिट है या नहीं, तो एक प्रमाण-प्रतिसाद के रूप में एक ऐड-ऑन पुस्तकालय बनाने का सुझाव देना एक अच्छा विचार हो सकता है। यह प्रयोक्ताओं को सुविधा का उपयोग करने का एक तरीका देता है, इसका उपयोग और महत्ता का एक अधिक स्पष्ट उदाहरण प्रदान करता है, और पूरी तरह से एक स्थायी समाधान की तरह पूरा नहीं होना चाहिए। यह परियोजना की मूल धारा में बाद में शामिल किया जा सकता है। - - क्या इस सुविधा के कारण ब्रेकिंग परिवर्तन होने की संभावना है? - - क्या यह मौजूदा p5.js फ़ंक्शंस और वेरिएबल्स के साथ विरोध करेगा? - - क्या यह p5.js के लिए पहले से लिखे गए विशिष्ट रेखाचित्रों के साथ टकराव करेगा? - - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। - - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? - - उदाहरण के लिए, `join(["हैलो", "वर्ल्ड!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। -3. यदि पहुँच आवश्यकता और अन्य विचारों को पूरा किया गया है, तो नई सुविधा अनुरोध को प्रारंभ किया जाना चाहिए जब तक कि कार्य पीआर की ओर न हो। नई सुविधाओं के पीआर की समीक्षा प्रक्रिया नीचे विवरणित है। +सुविधा अनुरोध "नई सुविधा अनुरोध" समस्या टेम्पलेट का उपयोग करनी चाहिए। सुविधा अनुरोध को सम्बोधित करने के लिए निम्नलिखित वर्कफ़्लो सामान्य है: + +1. पहुंच बढ़ाने के लिए p5.js की प्रतिबद्धता के हिस्से के रूप में, एक सुविधा अनुरोध को यह मामला बनाना चाहिए कि यह उन समुदायों तक p5.js की पहुंच कैसे बढ़ाता है जो ऐतिहासिक रूप से क्षेत्र में हाशिए पर हैं। अधिक विवरण [यहां](access.md) उपलब्ध हैं। + - यदि कोई सुविधा अनुरोध "पहुंच बढ़ाने" क्षेत्र को पर्याप्त रूप से भरा नहीं है, तो आप समस्या लेखक से सुविधा कैसे पहुंच बढ़ाती है, इसके बारे में पूछ सकते हैं। + - सुविधा की पहुंच का बयान किसी अलग समुदाय सदस्य, समस्या समीक्षकों सहित, द्वारा प्रदान किया जा सकता है। +2. नई सुविधा अनुरोध को निम्नलिखित मानकों के आधार पर समाविष्टि के लिए मूल्यांकन किया जा सकता है। + - क्या सुविधा परियोजना के धारा और [डिज़ाइन सिद्धांतों](design_principles.md) में फिट है? + - उदाहरण के लिए, एक नई आकृति जोड़ने का अनुरोध किया जा सकता है, लेकिन ब्राउज़र-आधारित आईओटी प्रोटोकॉल को ग्रहण करने का अनुरोध असंगत होगा। + - सम्पूर्ण रूप से, p5.js का धारा संक्षिप्त होना चाहिए ताकि अनियमित उपयोग की सुविधाओं से बचा जा सके। + - यदि कोई सुविधा p5.js के धारा में फिट नहीं होती है, तो सुझाव दें कि समस्या लेखक सुविधा को एक ऐड-ऑन पुस्तकालय के रूप में अमल करें। + - यदि स्पष्ट नहीं है कि यह फिट है या नहीं, तो एक प्रमाण-प्रतिसाद के रूप में एक ऐड-ऑन पुस्तकालय बनाने का सुझाव देना एक अच्छा विचार हो सकता है। यह प्रयोक्ताओं को सुविधा का उपयोग करने का एक तरीका देता है, इसका उपयोग और महत्ता का एक अधिक स्पष्ट उदाहरण प्रदान करता है, और पूरी तरह से एक स्थायी समाधान की तरह पूरा नहीं होना चाहिए। यह परियोजना की मूल धारा में बाद में शामिल किया जा सकता है। + - क्या इस सुविधा के कारण ब्रेकिंग परिवर्तन होने की संभावना है? + - क्या यह मौजूदा p5.js फ़ंक्शंस और वेरिएबल्स के साथ विरोध करेगा? + - क्या यह p5.js के लिए पहले से लिखे गए विशिष्ट रेखाचित्रों के साथ टकराव करेगा? + - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। + - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? + - उदाहरण के लिए, `join(["हैलो", "वर्ल्ड!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। +3. यदि पहुंच की आवश्यकता और अन्य विचार पूरे हो गए हैं, तो पीआर की दिशा में काम शुरू करने से पहले कम से कम दो प्रबंधकों या अनुरक्षकों को नई सुविधा के अनुरोध को मंजूरी देनी होगी। नई सुविधाओं के पीआर की समीक्षा प्रक्रिया नीचे विवरणित है। ### सुविधा विस्तार -सुविधा विस्तार समस्याओं का उपयोग करना चाहिए "मौजूदा सुविधा विस्तार" समस्या टेम्प्लेट का। प्रक्रिया नई सुविधा अनुरोधों के साथ बहुत समान है। नई सुविधा अनुरोध और सुविधा विस्तार के बीच का अंतर कभी-कभी कम हो सकता है। सुविधा विस्तार मुख्य रूप से p5.js के मौजूदा कार्यों के साथ संबंधित होता है जबकि नई सुविधा अनुरोध पूरी तरह से नए कार्यों को जोड़ने का अनुरोध कर सकता है। +सुविधा विस्तार समस्याओं को "मौजूदा सुविधा विस्तार" समस्या टेम्प्लेट का उपयोग करना चाहिए। प्रक्रिया नई सुविधा अनुरोधों के साथ बहुत समान है। नई सुविधा अनुरोध और सुविधा विस्तार के बीच का अंतर कभी-कभी कम हो सकता है। सुविधा विस्तार मुख्य रूप से p5.js के मौजूदा कार्यों के साथ संबंधित होता है जबकि नई सुविधा अनुरोध पूरी तरह से नए कार्यों को जोड़ने का अनुरोध कर सकता है। 1. नई सुविधा अनुरोधों की तरह, सुविधा विस्तार को केवल उन्हें स्वीकार किया जाना चाहिए अगर वे p5.js के पहुँच को बढ़ाते हैं। कृपया [ऊपर दिए गए खंड](./steward_guidelines.md#सुविधा-अनुरोध) का बिंदु 1 देखें। -2. सुविधा विस्तारों के समावेश की मान्यता देने की मानदंड नए सुविधा अनुरोधों के लिए तुलनात्मक होती हैं, लेकिन भिन्नता तब की जाती है जब संभावित ब्रेकिंग बदलावों पर विशेष ध्यान दिया जाता है। +2. सुविधा विस्तार के लिए समावेशन मानदंड सुविधा अनुरोधों के समान हैं, लेकिन संभावित ब्रेकिंग परिवर्तनों पर विशेष ध्यान दिया जाना चाहिए। - मौजूदा कार्यों को संशोधित करते समय, सभी पिछले मान्य और दस्तावेजित कार्य साकार तरीके से बर्ताव करने चाहिए। -3. सुविधा विस्तारों को कम से कम एक स्टीवर्ड या मेंटेनर द्वारा मंजूर किया जान| चाहिए जब काम की ओर प्रीआर किया जाना चाहिए। सुविधा विस्तार के लिए पीआर समीक्षा प्रक्रिया नीचे विवरणित है। +3. पीआर की ओर काम शुरू करने से पहले फीचर संवर्द्धन को कम से कम एक प्रबंधक या अनुरक्षक द्वारा अनुमोदित किया जाना चाहिए। सुविधा विस्तार के लिए पीआर समीक्षा प्रक्रिया नीचे विवरणित है। ### चर्चा इस प्रकार की समस्या के पास एक न्यूनतम टेम्प्लेट ("चर्चा" (discussion)) होता है और इसका उपयोग विषय के चारों ओर संवाद जमा करने के लिए किया जाना चाहिए, जो बाद में किसी विशेष मुद्दे में एकत्रित किया जाता है, जैसे कि एक सुविधा अनुरोध। इन प्रकार की चर्चा समस्याओं को समाप्त होने पर बंद किया जा सकता है और परिणामी अधिक विशिष्ट समस्याएं बना दी गई हैं: -- यदि कोई मुद्दा चर्चा के रूप में खोला गया है, लेकिन उदाहरण के लिए, एक बग रिपोर्ट होना चाहिए, तो सही लेबल लागू किया जाना चाहिए और "चर्चा" लेबल हटा दिया जाना चाहिए। यदि पहले से शामिल नहीं है तो बग के बारे में अतिरिक्त जानकारी भी लेखक से मांगी जानी चाहिए। -- यदि कोई मुद्दा चर्चा के रूप में खोला गया है, लेकिन स्रोत कोड योगदान के लिए प्रासंगिक नहीं है या अन्यथा गिटहब रिपॉजिटरी/योगदान प्रक्रिया/योगदान समुदाय के लिए प्रासंगिक नहीं है, तो उन्हें फ़ोरम या डिस्कॉर्ड पर पुनर्निर्देशित किया जाना चाहिए और मुद्दा बंद कर दिया जाना चाहिए। -- यदि लागू हो, तो चर्चा इस्स्यूज के लिए अतिरिक्त लेबल जोड़े जा सकते हैं ताकि एक नजर में यह देखा जा सके कि यह किस प्रकार की चर्चा है। +- यदि कोई समस्या चर्चा के रूप में खोला गया है, उदाहरण के लिए, एक बग रिपोर्ट होना चाहिए, तो सही लेबल लागू किया जाना चाहिए और "चर्चा" लेबल हटा दिया जाना चाहिए। यदि पहले से शामिल नहीं है तो बग के बारे में अतिरिक्त जानकारी भी लेखक से मांगी जानी चाहिए। +- यदि कोई समस्या चर्चा के रूप में खोला गया है, लेकिन स्रोत कोड योगदान के लिए प्रासंगिक नहीं है या अन्यथा गिटहब रिपॉजिटरी/योगदान प्रक्रिया/योगदान समुदाय के लिए प्रासंगिक नहीं है, तो उन्हें फ़ोरम या डिस्कॉर्ड पर पुनर्निर्देशित किया जाना चाहिए और मुद्दा बंद कर दिया जाना चाहिए। +- यदि लागू हो, तो चर्चा के लिए अतिरिक्त लेबल जोड़े जा सकते हैं ताकि एक नजर में यह देखा जा सके कि यह किस प्रकार की चर्चा है। --- From c1d936d65a78f1df6cd4cd81a7e245b5e6384b1f Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Wed, 20 Mar 2024 01:11:07 +0530 Subject: [PATCH 5/8] feat: refac till 200 lines --- contributor_docs/hi/steward_guidelines.md | 44 +++++++++++------------ 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index 6514f91470..74d2aa1a30 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -107,12 +107,12 @@ ## पुल रिक्वेस्ट -प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। स्टीवर्ड और मेंटेनर्स रिपॉजिट्रीज के पुश एक्सेस रख सकते हैं लेकिन जब भी कोड योगदान किया जाता है, तो वे पुल रिक्वेस्ट की समीक्षा करने को प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: +प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। प्रबंधकों और अनुरक्षकों के पास रिपॉजिटरी तक पहुंच हो सकती है, लेकिन फिर भी उन्हें कोड का योगदान करते समय उसी मुद्दे> पीआर> समीक्षा प्रक्रिया का पालन करने के लिए प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: -- पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)| -- लगभग सभी पुल रिक्वेस्ट के साथ संबंधित इस्स्यूज खोले और पहले चर्चा की जानी चाहिए, अर्थात पुश संबंधित इस्स्यूज के पहले पीआर की समीक्षा किया जाना चाहिए किसी भी स्टीवर्ड या मेंटेनर द्वारा। [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। - - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुले मुद्दे की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। - - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए मुद्दे खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक मुद्दा खोलें। +- पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)। +- लगभग सभी पुल अनुरोधों में संबंधित मुद्दों को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पीआर की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। + - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुली समस्या की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। + - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए समस्याएं खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक समस्या खोलें। - यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पीआर विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। ### सरल सुधार @@ -126,10 +126,10 @@ ### बग फ़िक्स 1. बग फ़िक्स का समीक्षा उस संबंधित क्षेत्र के स्टीवर्ड द्वारा किया जाना चाहिए, आदर्शतः उसी जिसने संदर्भित मुद्दे को फ़िक्स के लिए स्वीकृति दी थी। -2. पीआर "फ़ाइल बदले" टैब का उपयोग प्रारंभिक रूप से इसकी समीक्षा करने के लिए किया जा सकता है कि क्या फ़िक्स मुद्दे के चर्चा में वर्णित रूप में लागू किया गया है। -3. पीआर को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI प्रक्रिया के कुछ हिस्सों को समीक्षा करने में मदद कर सकता है। (यहाँ और [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). - - [ ] फ़िक्स को मूल मुद्दे को पर्याप्त रूप से संबोधित करना चाहिए। - - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल मुद्दे में सहमति न हो। +2. पीआर "फ़ाइलें बदली गईं" टैब का उपयोग प्रारंभ में यह समीक्षा करने के लिए किया जा सकता है कि समस्या चर्चा में बताए अनुसार समाधान लागू किया गया है या नहीं। +3. पीआर को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI कुछ प्रक्रिया को सुव्यवस्थित करने में मदद कर सकता है। (यहाँ [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). + - [ ] फ़िक्स को मूल समस्या को पर्याप्त रूप से संबोधित करना चाहिए। + - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल समस्या में सहमति न हो। - [ ] फ़िक्स पर p5.js पर कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए। - [ ] फ़िक्स पर p5.js की पहुँच कोई प्रभाव नहीं होना चाहिए। - [ ] फ़िक्स को जावास्क्रिप्ट कोडिंग के आधुनिक मानक का उपयोग करना चाहिए। @@ -145,7 +145,7 @@ - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ ![The "comment" option circled within the GitHub Finish Review menu](../images/comment-review.png) -5. एक बार पीआर की समीक्षा की गई है और कोई अतिरिक्त परिवर्तन आवश्यक नहीं है, तो एक स्टीवर्ड पिछले चरण में "मंजूर" चयन करके पीआर को "मंजूर" चिह्नित कर सकता है, जिसमें अतिरिक्त टिप्पणियों के साथ या बिना चयन किया जा सकता है। स्टीवर्ड फिर अगर चाहें तो एक अन्य स्टीवर्ड या रक्षक से अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज पहुंच है, तो पीआर को मर्ज कर सकता है, या रक्षक से मर्ज का अनुरोध कर सकता है। +5. एक बार जब पीआर की समीक्षा हो जाती है और किसी अतिरिक्त बदलाव की आवश्यकता नहीं होती है, तो एक प्रबंधक पिछले चरण में "स्वीकृत" विकल्प चुनकर, अतिरिक्त टिप्पणियों के साथ या उसके बिना, पीआर को "स्वीकृत" के रूप में चिह्नित कर सकता है। यदि वांछित हो तो प्रबंधक या तो किसी अन्य प्रबंधक या अनुरक्षक द्वारा अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज की पहुंच है तो पीआर का विलय कर सकता है, या अनुरक्षक से विलय का अनुरोध कर सकता है। 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) बॉट को बुलाया जाना चाहिए ताकि `README.md` फ़ाइल में नए योगदानकर्ताओं को योगदानकर्ताओं की सूची में जोड़ा जा सके। `[योगदान के प्रकार]` के स्थान पर हर प्रकार का योगदान निर्दिष्ट किया जा सकता है, योगदान के उपलब्ध प्रकार की पूरी सूची ऊपर दी गई लिंक में मिलेगी। @@ -161,16 +161,16 @@ डिपेंडेबॉट पीआर आमतौर पर केवल रिपो व्यवस्थापकों को ही दिखाई जाती हैं, इसलिए यदि यह आपके लिए लागू नहीं होता है, तो कृपया इस खंड को छोड़ें। -- डिपेंडेबॉट पीआर [सीमवर पैच](https://semver.org/) संस्करण है और स्वचालित सीआई परीक्षण पास हो जाता है तो सीधे मर्ज किए जा सकते हैं। -- सेमवर माइनर संस्करण परिवर्तन के साथ डिपेंडेबॉट पीआर आमतौर पर स्वचालित सीआई परीक्षण पास होने के तुरंत बाद सीधे मर्ज किए जा सकते हैं। अपडेट की गई आवश्यकता के चेकलिस्ट पर एक त्वरित जांच की जाती है। -- सेमेस्टर प्रमुख संस्करण परिवर्तनों के साथ डिपेंडाबॉट पीआर संभवतः निर्माण प्रक्रिया या पी5.जेएस कार्यक्षमता को प्रभावित कर सकते हैं। इस मामले में, समीक्षक को यदि संभव हो तो वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने और यह सुनिश्चित करने के लिए स्थानीय स्तर पर पीआर का परीक्षण करने के लिए प्रोत्साहित किया जाता है कि सभी प्रक्रियाएं कार्य कर रही हैं और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। +- यदि संस्करण अद्यतन एक [सीमवर](https://semver.org/) पैच संस्करण है और स्वचालित सीआई परीक्षण पास हो गया है, तो डिपेंडेबॉट पीआर को सीधे मर्ज किया जा सकता है। +- स्वचालित सीआई परीक्षण पास होने पर मामूली सेमेस्टर संस्करण परिवर्तनों वाले डिपेंडाबोट पीआर को आमतौर पर सीधे मर्ज किया जा सकता है। अद्यतन निर्भरता के चेंजलॉग पर त्वरित जांच की अनुशंसा की जाती है। +- प्रमुख सेमेस्टर संस्करण परिवर्तनों के साथ डिपेंडाबॉट पीआर संभवतः निर्माण प्रक्रिया या p5.js कार्यक्षमता को प्रभावित करेंगे। इस मामले में, यदि संभव हो तो समीक्षक को वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने के लिए प्रोत्साहित किया जाता है। उनसे यह भी अपेक्षा की जाती है कि वे स्थानीय स्तर पर पीआर का परीक्षण करें ताकि यह सुनिश्चित किया जा सके कि सभी प्रक्रियाएं कार्य कर रही हैं, और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। - कई निर्भरताओं ने मुख्य संस्करण संख्याओं को केवल इसलिए बढ़ाया है क्योंकि वे बहुत पुराने संस्करणों के लिए आधिकारिक समर्थन को हटा देते हैं। बहुत से मामलों में, मुख्य संस्करण परिवर्तन निर्भरता एपीआई परिवर्तन से होने वाले तोड़फोड़ को नहीं अवश्य मतलब है। --- ## निर्माण प्रक्रिया -यह खंड सामान्य निर्माण सेटअप या आदेश का विवरण नहीं करेगा, बल्कि विवरणों के पीछे क्या हो रहा है उसके बारे में जानकारी देगा। कृपया अधिक विस्तृत निर्माण जानकारी के लिए [योगदानकर्ता दिशानिर्देश](Add link to contributor guidlines) देखें। +यह खंड सामान्य निर्माण सेटअप या आदेश का विवरण नहीं करेगा, बल्कि विवरणों के पीछे क्या हो रहा है उसके बारे में जानकारी देगा। कृपया अधिक विस्तृत निर्माण जानकारी के लिए [योगदानकर्ता दिशानिर्देश](./contributing_documentation.md#🗯-संदर्भ-के-लिए-योगदान-करें) देखें। `Gruntfile.js` फ़ाइल p5.js के मुख्य निर्माण परिभाषणों को संबोधित करती है। पुस्तकालय और दस्तावेज़ीकरण निर्माण के लिए उपयोग किए जाने वाले विभिन्न उपकरणों में `Grunt`, `Browserify`, `YUIDoc`, `ESLint`, `Babel`, `Uglify`, और `Mocha` शामिल हैं। यह हमारे लिए `default (डिफ़ॉल्ट)` टास्क के साथ शुरू करने और वहां से पिछले काम करने में मददगार हो सकता है। इस विवरण के दौरान `Gruntfile.js` दस्तावेज़ को खोलना भी उपयोगी हो सकता है। @@ -180,7 +180,7 @@ grunt.registerTask('default', ['lint', 'test']); ``` -जब हम `grunt` या `npm` स्क्रिप्ट npm `test` चलाते हैं, तो हम लिंट फिर परीक्षण के रूप में लिंट का डिफ़ॉल्ट टास्क चलाते हैं। +जब हम `grunt` या `npm` स्क्रिप्ट npm `test` चलाते हैं, तो हम लिंट फिर परीक्षण के रूप में डिफ़ॉल्ट टास्क चलाते हैं। #### `lint` कार्य @@ -190,9 +190,9 @@ grunt.registerTask('lint', ['lint:source', 'lint:samples']); लिंट कार्य में दो उप-कार्य होते हैं: `lint:source` और `lint:samples`। `lint:source` को तीन और उप-कार्यों में विभाजित किया गया है `eslint:build`, `eslint:source`, और `eslint:test`, जो ESLint का उपयोग निर्माण स्क्रिप्ट, सोर्स कोड, और परीक्षण स्क्रिप्ट की जाँच करने के लिए करता है। -`lint:samples` कार्य पहले `yui` कार्य को चलाएगा जिसमें स्वयं `yuidoc: prod`, `clean:reference`, और `minjson` शामिल हैं, जो स्रोत कोड से दस्तावेज़ को JSON दस्तावेज़ में निकालते हैं, हटाते हैं पिछले चरण से अप्रयुक्त फ़ाइलें, और उत्पन्न JSON फ़ाइल को क्रमशः `data.min.json` में छोटा करें। +`lint:samples` कार्य पहले `yui` कार्य को चलाएगा जिसमें स्वयं `yuidoc: prod`, `clean:reference`, और `minjson` शामिल हैं, जो स्रोत कोड से दस्तावेज़ को JSON दस्तावेज़ में परिवर्तित करते हैं, पिछले चरण से अप्रयुक्त फ़ाइलें हटाते हैं, और उत्पन्न JSON फ़ाइल को क्रमशः `data.min.json` में छोटा करते हैं। -`lint:samples` में अगला है `eslint-samples:source`, जो एक कस्टम लिखित कार्य है जिसकी परिभाषा [tasks/build/eslint-samples.js](../tasks/build/eslint-samples.js) में है ; यह दस्तावेज़ीकरण उदाहरण कोड की जांच करने के लिए ESLint चलाएगा ताकि यह सुनिश्चित किया जा सके कि वे बाकी p5.js के समान कोडिंग कन्वेंशन का पालन करते हैं (`yui` यहां पहले चलाया गया है क्योंकि हमें उदाहरणों को लिंट करने से पहले JSON फ़ाइल बनाने की आवश्यकता है ). +`lint:samples` में अगला है `eslint-samples:source`, जो एक कस्टम लिखित कार्य है जिसकी परिभाषा [tasks/build/eslint-samples.js](../tasks/build/eslint-samples.js) में है; यह दस्तावेज़ीकरण उदाहरण कोड की जांच करने के लिए ESLint चलाएगा ताकि यह सुनिश्चित किया जा सके कि वे बाकी p5.js के समान कोडिंग कन्वेंशन का पालन करते हैं (`yui` यहां पहले चलाया गया है क्योंकि हमें उदाहरणों को लिंट करने से पहले JSON फ़ाइल बनाने की आवश्यकता है)। #### `test` कार्य @@ -200,7 +200,7 @@ grunt.registerTask('lint', ['lint:source', 'lint:samples']); grunt.registerTask("test", ["build", "connect:server", "mochaChrome", "mochaTest", "nyc:report"]); ``` -सबसे पहले अपने तहत `test` के नीचे `build` कार्य को देखते हैं। +सबसे पहले `test` तहत `build` कार्य को देखते हैं। ```js grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browserify:test"]); @@ -208,11 +208,11 @@ grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browseri `browserify` से शुरू होने वाले कार्य [tasks/build/browserify.js](../tasks/build/browserify.js) में परिभाषित होते हैं। इनमें सभी मुख्य कदम होते हैं जो बहुत से उपयोगकर्ता कोड फ़ाइलों को संग्रहीत और एक में बनाने के लिए हैं: -- `browserify` p5.js बनाता है जबकि `browserify:min` अगले कदम में संक्षिप्त किए जाने वाले एक बीच की फ़ाइल को बनाता है। `browserify` और `browserify:min` के बीच अंतर यह है कि `browserify:min` FES के लिए कार्यात्मक नहीं होने वाले डेटा को नहीं समाहित करता। -- `uglify` `browserify:min` की उत्पादित फ़ाइल को छोटा करता है और अंतिम `p5.min.js` में इसे छोटा करता है (इस कदम की विन्यासिकता मुख्य `Gruntfile.js` में है)। -- `browserify:test` एक पूरे p5.js के संग्रह को बनाता है, लेकिन परीक्षण कोड कवरेज रिपोर्टिंग के लिए जोड़ा गया कोड जोड़ता है ([Istanbul](https://istanbul.js.org/) का उपयोग करके)। +- `browserify` p5.js का निर्माण कार्य है जबकि `browserify:min` अगले कदम में संक्षिप्त किए जाने वाले एक बीच की फ़ाइल को बनाता है। `browserify` और `browserify:min` के बीच अंतर यह है कि `browserify:min` FES के लिए कार्यात्मक नहीं होने वाले डेटा को नहीं समाहित करता। +- `uglify` `browserify:min` की उत्पादित फ़ाइल को छोटा करता है और अंतिम `p5.min.js` बनाता है (इस कदम की विन्यासिकता मुख्य `Gruntfile.js` में है)। +- `browserify:test` का उपयोग पूर्ण p5.js के समान संस्करण बनाने के लिए किया जाता है, सिवाय परीक्षण कोड कवरेज रिपोर्टिंग के लिए जोड़े गए कोड को छोड़कर ([Istanbul](https://istanbul.js.org/) का उपयोग करके) को बाहर रखा गया है। -पहले, नोड.जेएस के `fs.readFileSync()` का उपयोग फाइल की वास्तविक सामग्री के साथ प्रतिस्थापित किया जाता है जिसे `brfs-babel` का उपयोग किया जाता है। यह मुख्य रूप से वेबजीएल कोड के लिए उपयोग किया जाता है जो अलग फ़ाइलों के रूप में लिखा गया है। +सबसे पहले, `node.js` के `fs.readFileSync()` का उपयोग करके पढ़े गए कोड को `brfs-babel` का उपयोग करके फ़ाइल की वास्तविक सामग्री से बदल दिया जाता है। इसका उपयोग मुख्य रूप से WebGL कोड द्वारा अलग-अलग फ़ाइलों के रूप में लिखे गए स्रोत कोड से इनलाइन शेडर कोड के लिए किया जाता है। इसके बाद, `node_modules` से सभी निर्भरताओं सहित स्रोत कोड को पैकेज.जेसन में परिभाषित [ब्राउज़रलिस्ट](https://browsersl.ist/) आवश्यकता से मेल खाने के साथ-साथ कॉमनजेएस में ईएस 6 आयात विवरण बनाने के लिए बैबल का उपयोग करके ट्रांसप्लड किया जाता है: `require()` जो ब्राउज़राइज़ समझता है। यह हमें ब्राउज़र संगतता के बारे में चिंता किए बिना ES6 और उससे आगे उपलब्ध नए सिंटैक्स का उपयोग करने में भी सक्षम बनाता है। From 6d9149a393e27336e2cc843a780234483c5cdb06 Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Wed, 20 Mar 2024 02:00:01 +0530 Subject: [PATCH 6/8] refac: complete the same --- contributor_docs/hi/steward_guidelines.md | 45 ++++++++++++----------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index 74d2aa1a30..9a610f7138 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -110,7 +110,7 @@ प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। प्रबंधकों और अनुरक्षकों के पास रिपॉजिटरी तक पहुंच हो सकती है, लेकिन फिर भी उन्हें कोड का योगदान करते समय उसी मुद्दे> पीआर> समीक्षा प्रक्रिया का पालन करने के लिए प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: - पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)। -- लगभग सभी पुल अनुरोधों में संबंधित मुद्दों को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पीआर की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। +- लगभग सभी पुल अनुरोधों में संबंधित समस्याएं को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पीआर की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुली समस्या की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए समस्याएं खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक समस्या खोलें। - यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पीआर विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। @@ -214,9 +214,9 @@ grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browseri सबसे पहले, `node.js` के `fs.readFileSync()` का उपयोग करके पढ़े गए कोड को `brfs-babel` का उपयोग करके फ़ाइल की वास्तविक सामग्री से बदल दिया जाता है। इसका उपयोग मुख्य रूप से WebGL कोड द्वारा अलग-अलग फ़ाइलों के रूप में लिखे गए स्रोत कोड से इनलाइन शेडर कोड के लिए किया जाता है। -इसके बाद, `node_modules` से सभी निर्भरताओं सहित स्रोत कोड को पैकेज.जेसन में परिभाषित [ब्राउज़रलिस्ट](https://browsersl.ist/) आवश्यकता से मेल खाने के साथ-साथ कॉमनजेएस में ईएस 6 आयात विवरण बनाने के लिए बैबल का उपयोग करके ट्रांसप्लड किया जाता है: `require()` जो ब्राउज़राइज़ समझता है। यह हमें ब्राउज़र संगतता के बारे में चिंता किए बिना ES6 और उससे आगे उपलब्ध नए सिंटैक्स का उपयोग करने में भी सक्षम बनाता है। +इसके बाद, `package.json` में परिभाषित [ब्राउजर्सलिस्ट] (https://browsersl.ist/) आवश्यकता से मेल खाने के लिए `node_modules` से स्रोत कोड और सभी निर्भरताओं को `Babel` का उपयोग करके ट्रांसपाइल्ड किया जाता है। यह यह भी सुनिश्चित करता है कि सभी ES6 `import` विवरण CommonJS `require()` कथनों में परिवर्तित हो जाते हैं जिन्हें ब्राउज़र समझता है। यह हमें ब्राउज़र संगतता के बारे में चिंता किए बिना ES6 और उससे आगे उपलब्ध नए सिंटैक्स का उपयोग करने में भी सक्षम बनाता है। -बंडलिंग के बाद, लेकिन फ़ाइल में लिखा जाने से पहले, कोड को `pretty-fast` के माध्यम से पार किया जाता है, यदि यह न्यूनतम नहीं है, तो इसे साफ कर दिया जाता है ताकि अंतिम स्वरूपण कुछ संरचनात्मक रूप से अधिक संबंधित हो (हम उम्मीद करते हैं कि p5.js स्रोत कोड पढ़ा और जांचा जा सकता है यदि इच्छित है)। +बंडलिंग के बाद, लेकिन बंडल कोड को फ़ाइल में लिखे जाने से पहले, कोड को `pretty-fast` के माध्यम से पारित किया जाता है (यदि कोड को छोटा नहीं किया जाना है, तो इसे साफ किया जाना चाहिए ताकि अंतिम स्वरूपण थोड़ा अधिक सुसंगत हो)। ऐसा इसलिए किया जाता है क्योंकि हम आशा करते हैं कि यदि वांछित हो तो p5.js स्रोत कोड को पढ़ा और निरीक्षण किया जा सकता है। यहां कुछ छोटे विस्तृत कदम छोड़े गए हैं; आप नीचे दिए गए ब्राउज़रीफ़ाई निर्माण परिभाषण फ़ाइल की जांच करने के लिए सब कुछ को और करीब से देख सकते हैं। @@ -224,25 +224,25 @@ grunt.registerTask("build", ["browserify", "browserify:min", "uglify", "browseri connect:server ``` -यह कदम स्थानीय सर्वर को स्पिन करता है जो परीक्षण फ़ाइलों और निर्मित स्रोत कोड फ़ाइलों को होस्ट करता है ताकि क्रोम में स्वचालित परीक्षण चलाया जा सके। +यह कदम स्थानीय सर्वर को शुरू करता है जो परीक्षण फ़ाइलों और निर्मित स्रोत कोड फ़ाइलों को होस्ट करता है ताकि क्रोम में स्वचालित परीक्षण चलाया जा सके। ``` mochaChrome ``` -यह कदम [tasks/test/mocha-chrome.js](../tasks/test/mocha-chrome.js) में परिभाषित है। यह प्यूपिटीयर का उपयोग करता है जो क्रोम का एक हेडलेस संस्करण स्पिन करता है जिसे रिमोट नियंत्रित किया जा सकता है और `./test` फ़ोल्डर में `HTML` फ़ाइलों के साथ जुड़े परीक्षणों को चलाता है, जिसमें लाइब्रेरी के अनमिनिफ़ाइड और मिनिफ़ाइड संस्करणों को यूनिट परीक्षण सुइटों के साथ परीक्षण किया जाता है साथ ही सभी संदर्भ उदाहरणों का परीक्षण किया जाता है। +यह कदम [tasks/test/mocha-chrome.js](../tasks/test/mocha-chrome.js) में परिभाषित है। यह `Puppeteer` का उपयोग करता है जो `Chrome` का एक हेडलेस संस्करण शुरू करता है जिसे रिमोट नियंत्रित किया जा सकता है, और `./test` फ़ोल्डर में `HTML` फ़ाइलों के साथ जुड़े परीक्षणों को चलाता है, जिसमें लाइब्रेरी के अनमिनिफ़ाइड और मिनिफ़ाइड संस्करणों को यूनिट परीक्षण सुइटों और सभी संदर्भ उदाहरणों के साथ परीक्षण किया जाता है। ``` mochaTest ``` -यह चरण `mochaChrome` से भिन्न है क्योंकि यह क्रोम के बजाय नोड.जेएस में चलाया जाता है और लाइब्रेरी में केवल सुविधाओं के एक छोटे उपसमूह का परीक्षण करता है। p5.js में अधिकांश सुविधाओं के लिए ब्राउज़र वातावरण की आवश्यकता होगी, इसलिए परीक्षणों के इस सेट का विस्तार केवल तभी किया जाना चाहिए जब नए परीक्षणों को वास्तव में ब्राउज़र वातावरण की आवश्यकता न हो। +यह चरण `mochaChrome` से भिन्न है क्योंकि यह `Chrome` के बजाय `Node.js` में चलाया जाता है और लाइब्रेरी में केवल सुविधाओं के एक छोटे उपसमूह का परीक्षण करता है। p5.js में अधिकांश सुविधाओं के लिए ब्राउज़र वातावरण की आवश्यकता होगी, इसलिए परीक्षणों के इस सेट का विस्तार केवल तभी किया जाना चाहिए जब नए परीक्षणों को वास्तव में ब्राउज़र वातावरण की आवश्यकता न हो। ``` nyc:report ``` -आखिरकार, सभी निर्माण और परीक्षण पूर्ण होने के बाद, यह कदम परीक्षण कवरेज रिपोर्ट इकट्ठा करेगा जबकि `mochaChrome` ने पुस्तकालय का पूर्ण संस्करण परीक्षण किया था और परीक्षण कवरेज डेटा को कंसोल में प्रिंट करेगा। p5.js के परीक्षण कवरेज को मुख्यतः मॉनिटरिंग और कुछ अतिरिक्त डेटा बिंदुओं के लिए है; 100% परीक्षण कवरेज का उद्देश्य नहीं है। +अंत में, सभी निर्माण और परीक्षण पूरे होने के बाद, यह चरण परीक्षण कवरेज रिपोर्ट एकत्र करेगा। तुलना के लिए, `mochaChrome` लाइब्रेरी के पूर्ण संस्करण का परीक्षण कर रहा था और परीक्षण कवरेज डेटा को कंसोल पर प्रिंट कर रहा था। p5.js के लिए परीक्षण कवरेज मुख्य रूप से निगरानी और कुछ अतिरिक्त डेटा बिंदुओं के लिए है; 100% परीक्षण कवरेज प्राप्त करना कोई लक्ष्य नहीं है। और यही `Gruntfile.js` कॉन्फ़िगरेशन में डिफ़ॉल्ट कार्य को कवर करता है! @@ -254,9 +254,9 @@ nyc:report grunt yui:dev ``` -यह कार्य ऊपर विवरणित दस्तावेज़ और पुस्तकालय निर्माण को चलाएगा, उसके बाद उसी कोड के स्रोत में चिलम करने के लिए एक वेब सर्वर को स्पिन करेगा जिसका आप वेबसाइट पर [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/) पर संदर्भ पृष्ठ के संविदानी संस्करण के रूप में प्राप्त कर सकते हैं। फिर, यह स्रोत कोड के लिए बदलावों का मॉनिटर करेगा और संदर्भ और पुस्तकालय को फिर से निर्माण करेगा। +यह कार्य ऊपर बताए अनुसार दस्तावेज़ीकरण और लाइब्रेरी बिल्ड चलाएगा, और फिर एक वेब सर्वर शुरू करेगा जो वेबसाइट पर [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/) पर पाए गए संदर्भ पृष्ठ के समान संस्करण पेश करेगा। इसके बाद यह परिवर्तनों के लिए स्रोत कोड की निगरानी भी करेगा और दस्तावेज़ीकरण और लाइब्रेरी का पुनर्निर्माण भी करेगा। -`grunt` `yui:dev` उस समय उपयोगी है जब आप इनलाइन दस्तावेज़ में संदर्भ पर काम कर रहे हों क्योंकि आपको प्रति बार जब आप एक परिवर्तन करते हैं, तो आपको पिछले p5.js रिपॉजिटरी से निर्मित फ़ाइलों को स्थानीय p5.js-वेबसाइट रिपॉजिटरी में ले जाने और वेबसाइट को पुनः निर्मित करने की आवश्यकता नहीं होती है, और आप बस अपने परिवर्तनों को अपने ब्राउज़र में संदर्भ के इस संविदानी संस्करण की एकदम साधारित रूप में पूर्वावलोकन कर सकते हैं। इस तरह, आपको यह भी अधिक विश्वसनीय हो सकता है कि आपके द्वारा किए गए परिवर्तनों का सही रूप से वेबसाइट पर प्रकट होने की संभावना है। ध्यान दें कि यह केवल इनलाइन दस्तावेज़ के संशोधनों के लिए है; संदर्भ पृष्ठ इसका हिस्सा, संशोधन और लेआउट सहित, वेबसाइट रिपॉजिटरी पर बनाए और परीक्षण किए जाने चाहिए। +`grunt` `yui:dev` तब उपयोगी होता है जब आप इनलाइन दस्तावेज़ में संदर्भ पर काम कर रहे होते हैं। इस कमांड का उपयोग करने के बाद, आपको निर्मित फ़ाइलों को p5.js रिपॉजिटरी से स्थानीय p5.js-वेबसाइट रिपॉजिटरी में स्थानांतरित करने और हर बार बदलाव करने पर वेबसाइट को फिर से बनाने की ज़रूरत नहीं है; आप अपने ब्राउज़र में संदर्भ के इस थोड़े सरलीकृत संस्करण के साथ अपने परिवर्तनों का पूर्वावलोकन कर सकते हैं। इस तरह, आप अधिक आश्वस्त हो सकते हैं कि आपके परिवर्तन संभवतः वेबसाइट पर सही ढंग से दिखाई देंगे। ध्यान दें कि यह केवल इनलाइन दस्तावेज़ीकरण में संशोधन के लिए है; स्टाइलिंग और लेआउट सहित, संदर्भ पृष्ठ में परिवर्तन किए जाने चाहिए और वेबसाइट रिपॉजिटरी पर परीक्षण किया जाना चाहिए। ``` grunt watch @@ -264,7 +264,7 @@ grunt watch:main grunt watch:quick ``` -वॉच कार्य विभिन्न फ़ाइलों के लिए बदलावों की निगरानी करेंगे और कौन से फ़ाइलों में क्या परिवर्तन हुआ है, उस अनुसार संबंधित कार्यों को चलाएगे। ये सभी कार्य एक ही चीज़ करते हैं, जिसका केवल विस्तार है। +`watch` कार्य विभिन्न फ़ाइलों के लिए बदलावों की निगरानी करेंगे और कौन से फ़ाइलों में क्या परिवर्तन हुआ है, उस अनुसार संबंधित कार्यों को चलाएगे। ये सभी कार्य एक ही चीज़ करते हैं, जिसका दायरा अलग है। `watch` कार्य स्रोत कोड में परिवर्तनों का पता लगाने पर पूर्ण डिफ़ॉल्ट कार्य चलाने के समान सभी बिल्ड और परीक्षण चलाएगा। @@ -278,7 +278,7 @@ grunt watch:quick ## रिहाई प्रक्रिया -कृपया रिलीज [`release_process.md`](release_process.md) देखें। +कृपया रिलीज [`release_process.md`](./release_process.md) देखें। --- @@ -288,7 +288,8 @@ grunt watch:quick ### उत्तर टेम्पलेट -एक आसान गिटहब सुविधा जिसका आप उपयोग कर सकते हैं वह है [सहेजे गए उत्तर](https://docs.github.com/en/get-started/writing-on-github/working-with-saveled-replies/about-saveled-replies) सुविधा, जो मुद्दों या पुल अनुरोधों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ मुद्दों या पीआर का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी मुद्दे को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। +एक आसान गिटहब सुविधा जिसका आप उपयोग कर सकते हैं वह है [उत्तर टेम्पलेट](https://docs.github.com/en/get-started/writing-on-github/working-with-saveled-replies/about-saveled-replies), जो समस्या +या पुल अनुरोधों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ समस्याएं या पीआर का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी समस्या को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। नीचे कुछ सहेजे गए उत्तर दिए गए हैं जिनका उपयोग p5.js अनुरक्षकों द्वारा किया जा रहा है। आप उन्हें स्वयं उपयोग कर सकते हैं या अपना खुद का बना सकते हैं! @@ -302,25 +303,25 @@ grunt watch:quick ##### समापन: फोरम का उपयोग करें -> यहां GitHub मुद्दे p5.js लाइब्रेरी के बग और मुद्दों के लिए एक अच्छी जगह हैं। अपना स्वयं का कोड लिखने, परीक्षण करने या ट्यूटोरियल का अनुसरण करने के बारे में प्रश्नों के लिए, [फोरम](https://discourse.processing.org/) पोस्ट करने के लिए सबसे अच्छी जगह है। धन्यवाद! +> यहां गिटहब समस्या p5.js लाइब्रेरी के बग और समस्याएं के लिए एक अच्छी जगह हैं। अपना स्वयं का कोड लिखने, परीक्षण करने या ट्यूटोरियल का अनुसरण करने के बारे में प्रश्नों के लिए, [फोरम](https://discourse.processing.org/) पोस्ट करने के लिए सबसे अच्छी जगह है। धन्यवाद! ##### समापन: जीएसओसी > धन्यवाद! जीएसओसी प्रस्तावों पर चर्चा करने के लिए सबसे अच्छी जगह हमारा [फोरम](https://discourse.processing.org/c/summer-of-code) है। -##### समापन: प्रवेश +##### समापन: पहुंच -> मुझे इस सुविधा में बहुत अधिक रुचि नहीं दिख रही है, और हमारे पास इसकी स्पष्ट व्याख्या नहीं है कि यह कैसे [पहुंच का विस्तार करता है] (access.md), इसलिए मैं इसे अभी बंद कर दूंगा। यदि समस्या अनुरोध में एक एक्सेस स्टेटमेंट जोड़ा जा सकता है, तो कृपया पुनः खोलने का स्वागत करें। +> मुझे इस सुविधा में बहुत अधिक रुचि नहीं दिख रही है, और हमारे पास इसकी स्पष्ट व्याख्या नहीं है कि यह कैसे [पहुंच का विस्तार करता है](access.md), इसलिए मैं इसे अभी बंद कर दूंगा। यदि समस्या अनुरोध में एक एक्सेस स्टेटमेंट जोड़ा जा सकता है, तो कृपया पुनः खोलने का स्वागत करें। -> हमें इस बारे में कोई और स्पष्टीकरण नहीं दिख रहा है कि यह मुद्दा कैसे [पहुंच का विस्तार करता है] (access.md), इसलिए मैं इस मुद्दे को अभी के लिए बंद कर दूंगा। यदि फीचर अनुरोध में अधिक विस्तृत एक्सेस स्टेटमेंट जोड़ा जा सकता है, तो कृपया इसे फिर से खोलने का स्वागत करें। धन्यवाद! +> हमें इस बारे में कोई और स्पष्टीकरण नहीं दिख रहा है कि यह मुद्दा कैसे [पहुंच का विस्तार करता है](access.md), इसलिए मैं इस समस्या को अभी के लिए बंद कर दूंगा। यदि फीचर अनुरोध में अधिक विस्तृत एक्सेस स्टेटमेंट जोड़ा जा सकता है, तो कृपया इसे फिर से खोलने का स्वागत करें। धन्यवाद! ##### समापन: ऐडऑन -> मुझे लगता है कि यह फ़ंक्शन p5.js API के दायरे से परे है (हम इसे यथासंभव न्यूनतम रखने की कोशिश करते हैं), लेकिन यह एक ऐडऑन लाइब्रेरी के लिए एक बेहतरीन शुरुआती बिंदु हो सकता है। ऐडऑन बनाने के तरीके के लिए यहां दस्तावेज़ देखें: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) +> मुझे लगता है कि यह फ़ंक्शन p5.js एपीआई के दायरे से परे है (हम इसे यथासंभव न्यूनतम रखने की कोशिश करते हैं), लेकिन यह एक ऐडऑन लाइब्रेरी के लिए एक बेहतरीन शुरुआती बिंदु हो सकता है। ऐडऑन बनाने के तरीके के लिए यहां दस्तावेज़ देखें: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) -##### समापन पीआर: पहले मुद्दे की आवश्यकता है +##### समापन पीआर: पहले समस्या की आवश्यकता है -> धन्यवाद. एक अनुस्मारक के रूप में, पुल अनुरोधों को खोलने और समस्या के साथ टैग करने से पहले मुद्दों को खोला जाना चाहिए। विकास पर नज़र रखने और चर्चा को स्पष्ट रखने के लिए यह आवश्यक है। धन्यवाद! +> धन्यवाद. एक अनुस्मारक के रूप में, पुल अनुरोधों को खोलने और समस्या के साथ टैग करने से पहले समस्याएं को खोला जाना चाहिए। विकास पर नज़र रखने और चर्चा को स्पष्ट रखने के लिए यह आवश्यक है। धन्यवाद! ##### समस्या को ठीक करने के लिए स्वीकृति दें @@ -328,19 +329,19 @@ grunt watch:quick ##### मर्ज किया गया पीआर -> अच्छा लग रहा है. धन्यवाद! +> किये गये परिवर्तन मुझे अच्छे लग रहे हैं। धन्यवाद! ### गिटहब सीएलआई आपके परीक्षण के लिए स्थानीय स्तर पर कोड का पीआर संस्करण प्राप्त करने के लिए आवश्यक जटिल गिट कमांड के साथ एक जटिल पीआर की समीक्षा करना मुश्किल हो सकता है। सौभाग्य से, [गिटहब CLI](https://cli.github.com/) टूल इस प्रक्रिया और बहुत कुछ में काफी मदद कर सकता है। -CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पीआर की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout` मेन। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पीआर में से! +CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पीआर की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout main`। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पीआर में से! गिटहब एसईएलआई में बहुत सारे अन्य कमांड भी उपलब्ध हैं जो आपको उपयोगी हो सकते हैं या नहीं मिल सकते हैं, लेकिन यह एक अच्छा उपकरण है जिसका आपके आसपास होना है किसी भी मामले में। ### सूचनाओं का प्रबंधन -नए मुद्दों या पीआर के लिए "मुद्दे" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। +नए समस्याएं या पीआर के लिए "समस्याएं" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। ![गिटहब रिपॉजिटरी पेज के ऊपरी दाएं कोने का क्रॉप किया गया स्क्रीनशॉट, जो बाएं से दाएं केंद्र में बटनों की एक श्रृंखला दिखा रहा है: प्रायोजक (Sponsor), नजर रखना (Watch), शूल (Fork), तारांकित (Starred)](../images/github-repo-metrics.png) From f39a41395e3fea9c457d38a08189f8fa75f67ea9 Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Wed, 20 Mar 2024 20:28:36 +0530 Subject: [PATCH 7/8] fix: change pr to pull request --- contributor_docs/hi/steward_guidelines.md | 46 +++++++++++------------ 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index 9a610f7138..87ddd06a3f 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -82,7 +82,7 @@ - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? - उदाहरण के लिए, `join(["हैलो", "वर्ल्ड!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। -3. यदि पहुंच की आवश्यकता और अन्य विचार पूरे हो गए हैं, तो पीआर की दिशा में काम शुरू करने से पहले कम से कम दो प्रबंधकों या अनुरक्षकों को नई सुविधा के अनुरोध को मंजूरी देनी होगी। नई सुविधाओं के पीआर की समीक्षा प्रक्रिया नीचे विवरणित है। +3. यदि पहुंच की आवश्यकता और अन्य विचार पूरे हो गए हैं, तो पुल अनुरोध की दिशा में काम शुरू करने से पहले कम से कम दो प्रबंधकों या अनुरक्षकों को नई सुविधा के अनुरोध को मंजूरी देनी होगी। नई सुविधाओं के पुल अनुरोध की समीक्षा प्रक्रिया नीचे विवरणित है। ### सुविधा विस्तार @@ -93,7 +93,7 @@ - मौजूदा कार्यों को संशोधित करते समय, सभी पिछले मान्य और दस्तावेजित कार्य साकार तरीके से बर्ताव करने चाहिए। -3. पीआर की ओर काम शुरू करने से पहले फीचर संवर्द्धन को कम से कम एक प्रबंधक या अनुरक्षक द्वारा अनुमोदित किया जाना चाहिए। सुविधा विस्तार के लिए पीआर समीक्षा प्रक्रिया नीचे विवरणित है। +3. पुल अनुरोध की ओर काम शुरू करने से पहले फीचर संवर्द्धन को कम से कम एक प्रबंधक या अनुरक्षक द्वारा अनुमोदित किया जाना चाहिए। सुविधा विस्तार के लिए पुल अनुरोध समीक्षा प्रक्रिया नीचे विवरणित है। ### चर्चा @@ -107,17 +107,17 @@ ## पुल रिक्वेस्ट -प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। प्रबंधकों और अनुरक्षकों के पास रिपॉजिटरी तक पहुंच हो सकती है, लेकिन फिर भी उन्हें कोड का योगदान करते समय उसी मुद्दे> पीआर> समीक्षा प्रक्रिया का पालन करने के लिए प्रोत्साहित किया जाता है। यहां पीआर की समीक्षा के चरण दिए गए हैं: +प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। प्रबंधकों और अनुरक्षकों के पास रिपॉजिटरी तक पहुंच हो सकती है, लेकिन फिर भी उन्हें कोड का योगदान करते समय उसी मुद्दे> पुल अनुरोध> समीक्षा प्रक्रिया का पालन करने के लिए प्रोत्साहित किया जाता है। यहां पुल अनुरोध की समीक्षा के चरण दिए गए हैं: - पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)। -- लगभग सभी पुल अनुरोधों में संबंधित समस्याएं को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पीआर की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। +- लगभग सभी पुल अनुरोधों में संबंधित समस्याएं को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पुल अनुरोध की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुली समस्या की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए समस्याएं खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक समस्या खोलें। -- यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पीआर विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। +- यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पुल अनुरोध विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। ### सरल सुधार -सरल सुधार, जैसे कि छोटी टाइपो फिक्स, को मर्ज एक्सेस वाले किसी भी व्यक्ति द्वारा सीधे मर्ज किया जा सकता है। यह सुनिश्चित करने के लिए कि स्वचालित सीआई परीक्षण पास हो गया है, पीआर "फ़ाइलें परिवर्तित (files changed)" टैब पर जांचें। +सरल सुधार, जैसे कि छोटी टाइपो फिक्स, को मर्ज एक्सेस वाले किसी भी व्यक्ति द्वारा सीधे मर्ज किया जा सकता है। यह सुनिश्चित करने के लिए कि स्वचालित सीआई परीक्षण पास हो गया है, पुल अनुरोध "फ़ाइलें परिवर्तित (files changed)" टैब पर जांचें। ![गिटहब पर पुल अनुरोध देखते समय "फ़ाइलें परिवर्तित (Files changed)" टैब](../images/files-changed.png) @@ -126,8 +126,8 @@ ### बग फ़िक्स 1. बग फ़िक्स का समीक्षा उस संबंधित क्षेत्र के स्टीवर्ड द्वारा किया जाना चाहिए, आदर्शतः उसी जिसने संदर्भित मुद्दे को फ़िक्स के लिए स्वीकृति दी थी। -2. पीआर "फ़ाइलें बदली गईं" टैब का उपयोग प्रारंभ में यह समीक्षा करने के लिए किया जा सकता है कि समस्या चर्चा में बताए अनुसार समाधान लागू किया गया है या नहीं। -3. पीआर को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI कुछ प्रक्रिया को सुव्यवस्थित करने में मदद कर सकता है। (यहाँ [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). +2. पुल अनुरोध "फ़ाइलें बदली गईं" टैब का उपयोग प्रारंभ में यह समीक्षा करने के लिए किया जा सकता है कि समस्या चर्चा में बताए अनुसार समाधान लागू किया गया है या नहीं। +3. पुल अनुरोध को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI कुछ प्रक्रिया को सुव्यवस्थित करने में मदद कर सकता है। (यहाँ [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). - [ ] फ़िक्स को मूल समस्या को पर्याप्त रूप से संबोधित करना चाहिए। - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल समस्या में सहमति न हो। - [ ] फ़िक्स पर p5.js पर कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए। @@ -145,7 +145,7 @@ - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ ![The "comment" option circled within the GitHub Finish Review menu](../images/comment-review.png) -5. एक बार जब पीआर की समीक्षा हो जाती है और किसी अतिरिक्त बदलाव की आवश्यकता नहीं होती है, तो एक प्रबंधक पिछले चरण में "स्वीकृत" विकल्प चुनकर, अतिरिक्त टिप्पणियों के साथ या उसके बिना, पीआर को "स्वीकृत" के रूप में चिह्नित कर सकता है। यदि वांछित हो तो प्रबंधक या तो किसी अन्य प्रबंधक या अनुरक्षक द्वारा अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज की पहुंच है तो पीआर का विलय कर सकता है, या अनुरक्षक से विलय का अनुरोध कर सकता है। +5. एक बार जब पुल अनुरोध की समीक्षा हो जाती है और किसी अतिरिक्त बदलाव की आवश्यकता नहीं होती है, तो एक प्रबंधक पिछले चरण में "स्वीकृत" विकल्प चुनकर, अतिरिक्त टिप्पणियों के साथ या उसके बिना, पुल अनुरोध को "स्वीकृत" के रूप में चिह्नित कर सकता है। यदि वांछित हो तो प्रबंधक या तो किसी अन्य प्रबंधक या अनुरक्षक द्वारा अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज की पहुंच है तो पुल अनुरोध का विलय कर सकता है, या अनुरक्षक से विलय का अनुरोध कर सकता है। 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) बॉट को बुलाया जाना चाहिए ताकि `README.md` फ़ाइल में नए योगदानकर्ताओं को योगदानकर्ताओं की सूची में जोड़ा जा सके। `[योगदान के प्रकार]` के स्थान पर हर प्रकार का योगदान निर्दिष्ट किया जा सकता है, योगदान के उपलब्ध प्रकार की पूरी सूची ऊपर दी गई लिंक में मिलेगी। @@ -153,17 +153,17 @@ ### नई सुविधा/सुविधा वृद्धि -नई सुविधा या सुविधा वृद्धि पीआर के लिए परिक्रिया बग निवारण के साथ मिलती जुलती है, केवल एक विशेष अंतर है: +नई सुविधा या सुविधा वृद्धि पुल अनुरोध के लिए परिक्रिया बग निवारण के साथ मिलती जुलती है, केवल एक विशेष अंतर है: -- एक नई सुविधा/सुविधा वृद्धि पीआर को मर्ज करने से पहले कम से कम दो स्टीवर्ड या रक्षक द्वारा समीक्षित और मंजूर किया जाना चाहिए। +- एक नई सुविधा/सुविधा वृद्धि पुल अनुरोध को मर्ज करने से पहले कम से कम दो स्टीवर्ड या रक्षक द्वारा समीक्षित और मंजूर किया जाना चाहिए। ### डिपेंडेबॉट -डिपेंडेबॉट पीआर आमतौर पर केवल रिपो व्यवस्थापकों को ही दिखाई जाती हैं, इसलिए यदि यह आपके लिए लागू नहीं होता है, तो कृपया इस खंड को छोड़ें। +डिपेंडेबॉट पुल अनुरोध आमतौर पर केवल रिपो व्यवस्थापकों को ही दिखाई जाती हैं, इसलिए यदि यह आपके लिए लागू नहीं होता है, तो कृपया इस खंड को छोड़ें। -- यदि संस्करण अद्यतन एक [सीमवर](https://semver.org/) पैच संस्करण है और स्वचालित सीआई परीक्षण पास हो गया है, तो डिपेंडेबॉट पीआर को सीधे मर्ज किया जा सकता है। -- स्वचालित सीआई परीक्षण पास होने पर मामूली सेमेस्टर संस्करण परिवर्तनों वाले डिपेंडाबोट पीआर को आमतौर पर सीधे मर्ज किया जा सकता है। अद्यतन निर्भरता के चेंजलॉग पर त्वरित जांच की अनुशंसा की जाती है। -- प्रमुख सेमेस्टर संस्करण परिवर्तनों के साथ डिपेंडाबॉट पीआर संभवतः निर्माण प्रक्रिया या p5.js कार्यक्षमता को प्रभावित करेंगे। इस मामले में, यदि संभव हो तो समीक्षक को वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने के लिए प्रोत्साहित किया जाता है। उनसे यह भी अपेक्षा की जाती है कि वे स्थानीय स्तर पर पीआर का परीक्षण करें ताकि यह सुनिश्चित किया जा सके कि सभी प्रक्रियाएं कार्य कर रही हैं, और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। +- यदि संस्करण अद्यतन एक [सीमवर](https://semver.org/) पैच संस्करण है और स्वचालित सीआई परीक्षण पास हो गया है, तो डिपेंडेबॉट पुल अनुरोध को सीधे मर्ज किया जा सकता है। +- स्वचालित सीआई परीक्षण पास होने पर मामूली सेमेस्टर संस्करण परिवर्तनों वाले डिपेंडाबोट पुल अनुरोध को आमतौर पर सीधे मर्ज किया जा सकता है। अद्यतन निर्भरता के चेंजलॉग पर त्वरित जांच की अनुशंसा की जाती है। +- प्रमुख सेमेस्टर संस्करण परिवर्तनों के साथ डिपेंडाबॉट पुल अनुरोध संभवतः निर्माण प्रक्रिया या p5.js कार्यक्षमता को प्रभावित करेंगे। इस मामले में, यदि संभव हो तो समीक्षक को वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने के लिए प्रोत्साहित किया जाता है। उनसे यह भी अपेक्षा की जाती है कि वे स्थानीय स्तर पर पुल अनुरोध का परीक्षण करें ताकि यह सुनिश्चित किया जा सके कि सभी प्रक्रियाएं कार्य कर रही हैं, और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। - कई निर्भरताओं ने मुख्य संस्करण संख्याओं को केवल इसलिए बढ़ाया है क्योंकि वे बहुत पुराने संस्करणों के लिए आधिकारिक समर्थन को हटा देते हैं। बहुत से मामलों में, मुख्य संस्करण परिवर्तन निर्भरता एपीआई परिवर्तन से होने वाले तोड़फोड़ को नहीं अवश्य मतलब है। --- @@ -284,12 +284,12 @@ grunt watch:quick ## युक्तियाँ और ट्रिक्स -कभी-कभी, समीक्षा के लिए जितने भी जटिल पीआर हैं, उन्हें स्थानीय रूप से परीक्षण करने के लिए गिट के जटिल कमांड की आवश्यकता हो सकती है। भाग्य से, गिटहब सीएलआई टूल इस प्रक्रिया और अधिक के साथ बहुत मदद कर सकता है। +कभी-कभी, समीक्षा के लिए जितने भी जटिल पुल अनुरोध हैं, उन्हें स्थानीय रूप से परीक्षण करने के लिए गिट के जटिल कमांड की आवश्यकता हो सकती है। भाग्य से, गिटहब सीएलआई टूल इस प्रक्रिया और अधिक के साथ बहुत मदद कर सकता है। ### उत्तर टेम्पलेट एक आसान गिटहब सुविधा जिसका आप उपयोग कर सकते हैं वह है [उत्तर टेम्पलेट](https://docs.github.com/en/get-started/writing-on-github/working-with-saveled-replies/about-saveled-replies), जो समस्या -या पुल अनुरोधों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ समस्याएं या पीआर का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी समस्या को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। +या पुल अनुरोधों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ समस्याएं या पुल अनुरोध का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी समस्या को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। नीचे कुछ सहेजे गए उत्तर दिए गए हैं जिनका उपयोग p5.js अनुरक्षकों द्वारा किया जा रहा है। आप उन्हें स्वयं उपयोग कर सकते हैं या अपना खुद का बना सकते हैं! @@ -319,7 +319,7 @@ grunt watch:quick > मुझे लगता है कि यह फ़ंक्शन p5.js एपीआई के दायरे से परे है (हम इसे यथासंभव न्यूनतम रखने की कोशिश करते हैं), लेकिन यह एक ऐडऑन लाइब्रेरी के लिए एक बेहतरीन शुरुआती बिंदु हो सकता है। ऐडऑन बनाने के तरीके के लिए यहां दस्तावेज़ देखें: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) -##### समापन पीआर: पहले समस्या की आवश्यकता है +##### समापन पुल अनुरोध: पहले समस्या की आवश्यकता है > धन्यवाद. एक अनुस्मारक के रूप में, पुल अनुरोधों को खोलने और समस्या के साथ टैग करने से पहले समस्याएं को खोला जाना चाहिए। विकास पर नज़र रखने और चर्चा को स्पष्ट रखने के लिए यह आवश्यक है। धन्यवाद! @@ -327,21 +327,21 @@ grunt watch:quick > आप सुधार के साथ आगे बढ़ सकते हैं। धन्यवाद। -##### मर्ज किया गया पीआर +##### मर्ज किया गया पुल अनुरोध > किये गये परिवर्तन मुझे अच्छे लग रहे हैं। धन्यवाद! ### गिटहब सीएलआई -आपके परीक्षण के लिए स्थानीय स्तर पर कोड का पीआर संस्करण प्राप्त करने के लिए आवश्यक जटिल गिट कमांड के साथ एक जटिल पीआर की समीक्षा करना मुश्किल हो सकता है। सौभाग्य से, [गिटहब CLI](https://cli.github.com/) टूल इस प्रक्रिया और बहुत कुछ में काफी मदद कर सकता है। +आपके परीक्षण के लिए स्थानीय स्तर पर कोड का पुल अनुरोध संस्करण प्राप्त करने के लिए आवश्यक जटिल गिट कमांड के साथ एक जटिल पुल अनुरोध की समीक्षा करना मुश्किल हो सकता है। सौभाग्य से, [गिटहब CLI](https://cli.github.com/) टूल इस प्रक्रिया और बहुत कुछ में काफी मदद कर सकता है। -CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पीआर की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout main`। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पीआर में से! +CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पुल अनुरोध की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout main`। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पुल अनुरोध में से! गिटहब एसईएलआई में बहुत सारे अन्य कमांड भी उपलब्ध हैं जो आपको उपयोगी हो सकते हैं या नहीं मिल सकते हैं, लेकिन यह एक अच्छा उपकरण है जिसका आपके आसपास होना है किसी भी मामले में। ### सूचनाओं का प्रबंधन -नए समस्याएं या पीआर के लिए "समस्याएं" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। +नए समस्याएं या पुल अनुरोध के लिए "समस्याएं" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। ![गिटहब रिपॉजिटरी पेज के ऊपरी दाएं कोने का क्रॉप किया गया स्क्रीनशॉट, जो बाएं से दाएं केंद्र में बटनों की एक श्रृंखला दिखा रहा है: प्रायोजक (Sponsor), नजर रखना (Watch), शूल (Fork), तारांकित (Starred)](../images/github-repo-metrics.png) @@ -349,4 +349,4 @@ CLI को स्थानीय रूप से लिंक करने क कई मामलों में, आपको GitHub से रेपो में हो रही घटनाओं के बारे में ईमेल भी मिल सकते हैं, और आप इन्हें अपनी [सूचना सेटिंग्स पेज](https://github.com/settings/notifications) से कस्टमाइज़ कर सकते हैं (पूरी तरह से उनका अनसब्सक्राइब करके समेत)। -आपके काम करने के तरीके को ध्यान में रखते हुए इन्हें सेट करना, समस्याओं/पीआर समीक्षा को मैन्युअली से खोजने की आवश्यकता न हो और GitHub से अंतहीन सूचनाओं से अधिक भरी होने से बचाने में अंतर हो सकता है। यहां एक अच्छा संतुलन आवश्यक है। एक शुरुआती सुझाव के रूप में, स्टीवर्ड्स को इस रेपो के लिए "समस्याएँ" और "पुल रिक्वेस्ट्स" के लिए देखना चाहिए और इसे "भाग लेना, @मेंशन्स और कस्टम (Participating, @mentions and custom)" पर सेट करना चाहिए। +आपके काम करने के तरीके को ध्यान में रखते हुए इन्हें सेट करना, समस्याओं/पुल अनुरोध समीक्षा को मैन्युअली से खोजने की आवश्यकता न हो और GitHub से अंतहीन सूचनाओं से अधिक भरी होने से बचाने में अंतर हो सकता है। यहां एक अच्छा संतुलन आवश्यक है। एक शुरुआती सुझाव के रूप में, स्टीवर्ड्स को इस रेपो के लिए "समस्याएँ" और "पुल रिक्वेस्ट्स" के लिए देखना चाहिए और इसे "भाग लेना, @मेंशन्स और कस्टम (Participating, @mentions and custom)" पर सेट करना चाहिए। From fb19a20941df769baee3cbdd37a287cd4a784330 Mon Sep 17 00:00:00 2001 From: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com> Date: Wed, 20 Mar 2024 21:02:03 +0530 Subject: [PATCH 8/8] change pr --- contributor_docs/hi/steward_guidelines.md | 54 +++++++++++------------ 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/contributor_docs/hi/steward_guidelines.md b/contributor_docs/hi/steward_guidelines.md index 87ddd06a3f..da70ed21c3 100644 --- a/contributor_docs/hi/steward_guidelines.md +++ b/contributor_docs/hi/steward_guidelines.md @@ -82,7 +82,7 @@ - निम्नलिखित सुविधाएं जो संघर्ष पैदा कर सकती हैं जैसा कि उपरोक्त किए गए वे ब्रेकिंग बदलाव के रूप में गिना जाता है। [प्रमुख संस्करण रिलीज](https://docs.npmjs.com/about-semantic-versioning) के बिना, हमें p5.js में ब्रेकिंग बदलाव नहीं करने चाहिए। - क्या प्रस्तावित नई सुविधा को पहले से p5.js में मौजूद सुविधाओं का उपयोग करके, एक्सिस्टिंग साधारित जावास्क्रिप्ट कोड या मौजूदा सरल उपयोगिता वाली पुस्तकालयों का उपयोग करके प्राप्त किया जा सकता है? - उदाहरण के लिए, `join(["हैलो", "वर्ल्ड!"])` जैसी स्ट्रिंग्स की एक सरणी में शामिल होने के लिए एक p5.js फ़ंक्शन प्रदान करने के बजाय, मूल जावास्क्रिप्ट `["हैलो", "वर्ल्ड!"].join()` को प्राथमिकता दी जानी चाहिए। -3. यदि पहुंच की आवश्यकता और अन्य विचार पूरे हो गए हैं, तो पुल अनुरोध की दिशा में काम शुरू करने से पहले कम से कम दो प्रबंधकों या अनुरक्षकों को नई सुविधा के अनुरोध को मंजूरी देनी होगी। नई सुविधाओं के पुल अनुरोध की समीक्षा प्रक्रिया नीचे विवरणित है। +3. यदि पहुंच की आवश्यकता और अन्य विचार पूरे हो गए हैं, तो पुल रिक्वेस्ट की दिशा में काम शुरू करने से पहले कम से कम दो प्रबंधकों या अनुरक्षकों को नई सुविधा के अनुरोध को मंजूरी देनी होगी। नई सुविधाओं के पुल रिक्वेस्ट की समीक्षा प्रक्रिया नीचे विवरणित है। ### सुविधा विस्तार @@ -93,7 +93,7 @@ - मौजूदा कार्यों को संशोधित करते समय, सभी पिछले मान्य और दस्तावेजित कार्य साकार तरीके से बर्ताव करने चाहिए। -3. पुल अनुरोध की ओर काम शुरू करने से पहले फीचर संवर्द्धन को कम से कम एक प्रबंधक या अनुरक्षक द्वारा अनुमोदित किया जाना चाहिए। सुविधा विस्तार के लिए पुल अनुरोध समीक्षा प्रक्रिया नीचे विवरणित है। +3. पुल रिक्वेस्ट की ओर काम शुरू करने से पहले फीचर संवर्द्धन को कम से कम एक प्रबंधक या अनुरक्षक द्वारा अनुमोदित किया जाना चाहिए। सुविधा विस्तार के लिए पुल रिक्वेस्ट समीक्षा प्रक्रिया नीचे विवरणित है। ### चर्चा @@ -107,27 +107,27 @@ ## पुल रिक्वेस्ट -प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। प्रबंधकों और अनुरक्षकों के पास रिपॉजिटरी तक पहुंच हो सकती है, लेकिन फिर भी उन्हें कोड का योगदान करते समय उसी मुद्दे> पुल अनुरोध> समीक्षा प्रक्रिया का पालन करने के लिए प्रोत्साहित किया जाता है। यहां पुल अनुरोध की समीक्षा के चरण दिए गए हैं: +प्राय: p5.js रिपॉजिट्रीज में कोड योगदानों का अधिकांश पुल रिक्वेस्ट के माध्यम से होता है। प्रबंधकों और अनुरक्षकों के पास रिपॉजिटरी तक पहुंच हो सकती है, लेकिन फिर भी उन्हें कोड का योगदान करते समय उसी मुद्दे> पुल रिक्वेस्ट> समीक्षा प्रक्रिया का पालन करने के लिए प्रोत्साहित किया जाता है। यहां पुल रिक्वेस्ट की समीक्षा के चरण दिए गए हैं: - पुल रिक्वेस्ट टेम्पलेट [यहाँ मिलेगा](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)। -- लगभग सभी पुल अनुरोधों में संबंधित समस्याएं को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पुल अनुरोध की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। +- लगभग सभी पुल रिक्वेस्टों में संबंधित समस्याएं को पहले खोला और चर्चा की जानी चाहिए, जिसका अर्थ है कि किसी भी प्रबंधक या अनुरक्षक द्वारा पुल रिक्वेस्ट की समीक्षा करने से पहले प्रासंगिक [इश्यू वर्कफ़्लो](steward_guidelines.md#समस्याएँ) का पहले पालन किया जाना चाहिए। - एकमात्र उदाहरण जहां यह लागू नहीं होता है, वे बहुत मामूली टाइपो फिक्स होते हैं, जिनके लिए एक खुली समस्या की आवश्यकता नहीं होती है और रेपो तक मर्ज पहुंच वाले किसी भी व्यक्ति द्वारा विलय किया जा सकता है, भले ही वे किसी विशेष क्षेत्र के प्रबंधक न हों। - हालांकि यह अपवाद मौजूद है, हम इसे व्यवहार में तभी लागू करेंगे जब योगदानकर्ताओं को पहले नए समस्याएं खोलने के लिए प्रोत्साहित किया जाएगा। दूसरे शब्दों में, यदि इस बारे में संदेह है कि यह अपवाद लागू होता है या नहीं, तो फिर भी एक समस्या खोलें। -- यदि कोई पुल अनुरोध संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पुल अनुरोध विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। +- यदि कोई पुल रिक्वेस्ट संदर्भित समस्या को पूरी तरह से हल नहीं करता है, तो आप मूल पोस्ट को संपादित कर सकते हैं और `Resolves #OOOO` को `Addresses #OOOO` में बदल सकते हैं ताकि पुल रिक्वेस्ट विलय होने पर यह स्वचालित रूप से मूल समस्या को बंद न करे। ### सरल सुधार -सरल सुधार, जैसे कि छोटी टाइपो फिक्स, को मर्ज एक्सेस वाले किसी भी व्यक्ति द्वारा सीधे मर्ज किया जा सकता है। यह सुनिश्चित करने के लिए कि स्वचालित सीआई परीक्षण पास हो गया है, पुल अनुरोध "फ़ाइलें परिवर्तित (files changed)" टैब पर जांचें। +सरल सुधार, जैसे कि छोटी टाइपो फिक्स, को मर्ज एक्सेस वाले किसी भी व्यक्ति द्वारा सीधे मर्ज किया जा सकता है। यह सुनिश्चित करने के लिए कि स्वचालित सीआई परीक्षण पास हो गया है, पुल रिक्वेस्ट "फ़ाइलें परिवर्तित (files changed)" टैब पर जांचें। -![गिटहब पर पुल अनुरोध देखते समय "फ़ाइलें परिवर्तित (Files changed)" टैब](../images/files-changed.png) +![गिटहब पर पुल रिक्वेस्ट देखते समय "फ़ाइलें परिवर्तित (Files changed)" टैब](../images/files-changed.png) -![गिटहब पुल अनुरोध पर "सभी चेक पास हो गए हैं (All checks have passed)" संकेतक, मर्ज बटन के ऊपर हाइलाइट किया गया है](../images/all-checks-passed.png) +![गिटहब पुल रिक्वेस्ट पर "सभी चेक पास हो गए हैं (All checks have passed)" संकेतक, मर्ज बटन के ऊपर हाइलाइट किया गया है](../images/all-checks-passed.png) ### बग फ़िक्स 1. बग फ़िक्स का समीक्षा उस संबंधित क्षेत्र के स्टीवर्ड द्वारा किया जाना चाहिए, आदर्शतः उसी जिसने संदर्भित मुद्दे को फ़िक्स के लिए स्वीकृति दी थी। -2. पुल अनुरोध "फ़ाइलें बदली गईं" टैब का उपयोग प्रारंभ में यह समीक्षा करने के लिए किया जा सकता है कि समस्या चर्चा में बताए अनुसार समाधान लागू किया गया है या नहीं। -3. पुल अनुरोध को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI कुछ प्रक्रिया को सुव्यवस्थित करने में मदद कर सकता है। (यहाँ [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). +2. पुल रिक्वेस्ट "फ़ाइलें बदली गईं" टैब का उपयोग प्रारंभ में यह समीक्षा करने के लिए किया जा सकता है कि समस्या चर्चा में बताए अनुसार समाधान लागू किया गया है या नहीं। +3. पुल रिक्वेस्ट को संभावनापूर्वक और संबंधित होने पर स्थानीय रूप से परीक्षण किया जाना चाहिए। यदि संभव हो, तो गिटहब CLI कुछ प्रक्रिया को सुव्यवस्थित करने में मदद कर सकता है। (यहाँ [टिप्स और ट्रिक्स](./steward_guidelines.md#युक्तियाँ-और-ट्रिक्स) में अधिक देखें). - [ ] फ़िक्स को मूल समस्या को पर्याप्त रूप से संबोधित करना चाहिए। - [ ] फ़िक्स को किसी भी मौजूदा व्यवहार में परिवर्तन नहीं करना चाहिए जब तक मूल समस्या में सहमति न हो। - [ ] फ़िक्स पर p5.js पर कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए। @@ -137,7 +137,7 @@ 4. यदि कोई अतिरिक्त परिवर्तन आवश्यक हो, तो पंक्ति टिप्पणियाँ यहाँ जोड़ी [जानी चाहिए](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)। - एक सुझाव ब्लॉक का उपयोग किया जा सकता है विशिष्ट परिवर्तनों का सुझाव देने के लिए: - ![गिटहब पुल अनुरोध में कोड पर टिप्पणी लिखते समय परिवर्तन का सुझाव बटन](../images/suggest-change.png)\ + ![गिटहब पुल रिक्वेस्ट में कोड पर टिप्पणी लिखते समय परिवर्तन का सुझाव बटन](../images/suggest-change.png)\ ![एक सुझाया गया परिवर्तन "सुझाव (suggestion)" टैग के साथ कोड बाड़ के भीतर दिखाई देता है](../images/suggested-value-change.png)\ ![सुझाए गए परिवर्तन का पूर्वावलोकन अंतर के रूप में किया गया](../images/suggestion-preview.png) @@ -145,7 +145,7 @@ - यदि लाइन टिप्पणियाँ स्पष्टीकरण या चर्चा के लिए हैं, तो "अनुरोध परिवर्तन" की बजाय "टिप्पणी" का चयन करें:\ ![The "comment" option circled within the GitHub Finish Review menu](../images/comment-review.png) -5. एक बार जब पुल अनुरोध की समीक्षा हो जाती है और किसी अतिरिक्त बदलाव की आवश्यकता नहीं होती है, तो एक प्रबंधक पिछले चरण में "स्वीकृत" विकल्प चुनकर, अतिरिक्त टिप्पणियों के साथ या उसके बिना, पुल अनुरोध को "स्वीकृत" के रूप में चिह्नित कर सकता है। यदि वांछित हो तो प्रबंधक या तो किसी अन्य प्रबंधक या अनुरक्षक द्वारा अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज की पहुंच है तो पुल अनुरोध का विलय कर सकता है, या अनुरक्षक से विलय का अनुरोध कर सकता है। +5. एक बार जब पुल रिक्वेस्ट की समीक्षा हो जाती है और किसी अतिरिक्त बदलाव की आवश्यकता नहीं होती है, तो एक प्रबंधक पिछले चरण में "स्वीकृत" विकल्प चुनकर, अतिरिक्त टिप्पणियों के साथ या उसके बिना, पुल रिक्वेस्ट को "स्वीकृत" के रूप में चिह्नित कर सकता है। यदि वांछित हो तो प्रबंधक या तो किसी अन्य प्रबंधक या अनुरक्षक द्वारा अतिरिक्त समीक्षा का अनुरोध कर सकता है, यदि उनके पास मर्ज की पहुंच है तो पुल रिक्वेस्ट का विलय कर सकता है, या अनुरक्षक से विलय का अनुरोध कर सकता है। 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) बॉट को बुलाया जाना चाहिए ताकि `README.md` फ़ाइल में नए योगदानकर्ताओं को योगदानकर्ताओं की सूची में जोड़ा जा सके। `[योगदान के प्रकार]` के स्थान पर हर प्रकार का योगदान निर्दिष्ट किया जा सकता है, योगदान के उपलब्ध प्रकार की पूरी सूची ऊपर दी गई लिंक में मिलेगी। @@ -153,17 +153,17 @@ ### नई सुविधा/सुविधा वृद्धि -नई सुविधा या सुविधा वृद्धि पुल अनुरोध के लिए परिक्रिया बग निवारण के साथ मिलती जुलती है, केवल एक विशेष अंतर है: +नई सुविधा या सुविधा वृद्धि पुल रिक्वेस्ट के लिए परिक्रिया बग निवारण के साथ मिलती जुलती है, केवल एक विशेष अंतर है: -- एक नई सुविधा/सुविधा वृद्धि पुल अनुरोध को मर्ज करने से पहले कम से कम दो स्टीवर्ड या रक्षक द्वारा समीक्षित और मंजूर किया जाना चाहिए। +- एक नई सुविधा/सुविधा वृद्धि पुल रिक्वेस्ट को मर्ज करने से पहले कम से कम दो स्टीवर्ड या रक्षक द्वारा समीक्षित और मंजूर किया जाना चाहिए। ### डिपेंडेबॉट -डिपेंडेबॉट पुल अनुरोध आमतौर पर केवल रिपो व्यवस्थापकों को ही दिखाई जाती हैं, इसलिए यदि यह आपके लिए लागू नहीं होता है, तो कृपया इस खंड को छोड़ें। +डिपेंडेबॉट पुल रिक्वेस्ट आमतौर पर केवल रिपो व्यवस्थापकों को ही दिखाई जाती हैं, इसलिए यदि यह आपके लिए लागू नहीं होता है, तो कृपया इस खंड को छोड़ें। -- यदि संस्करण अद्यतन एक [सीमवर](https://semver.org/) पैच संस्करण है और स्वचालित सीआई परीक्षण पास हो गया है, तो डिपेंडेबॉट पुल अनुरोध को सीधे मर्ज किया जा सकता है। -- स्वचालित सीआई परीक्षण पास होने पर मामूली सेमेस्टर संस्करण परिवर्तनों वाले डिपेंडाबोट पुल अनुरोध को आमतौर पर सीधे मर्ज किया जा सकता है। अद्यतन निर्भरता के चेंजलॉग पर त्वरित जांच की अनुशंसा की जाती है। -- प्रमुख सेमेस्टर संस्करण परिवर्तनों के साथ डिपेंडाबॉट पुल अनुरोध संभवतः निर्माण प्रक्रिया या p5.js कार्यक्षमता को प्रभावित करेंगे। इस मामले में, यदि संभव हो तो समीक्षक को वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने के लिए प्रोत्साहित किया जाता है। उनसे यह भी अपेक्षा की जाती है कि वे स्थानीय स्तर पर पुल अनुरोध का परीक्षण करें ताकि यह सुनिश्चित किया जा सके कि सभी प्रक्रियाएं कार्य कर रही हैं, और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। +- यदि संस्करण अद्यतन एक [सीमवर](https://semver.org/) पैच संस्करण है और स्वचालित सीआई परीक्षण पास हो गया है, तो डिपेंडेबॉट पुल रिक्वेस्ट को सीधे मर्ज किया जा सकता है। +- स्वचालित सीआई परीक्षण पास होने पर मामूली सेमेस्टर संस्करण परिवर्तनों वाले डिपेंडाबोट पुल रिक्वेस्ट को आमतौर पर सीधे मर्ज किया जा सकता है। अद्यतन निर्भरता के चेंजलॉग पर त्वरित जांच की अनुशंसा की जाती है। +- प्रमुख सेमेस्टर संस्करण परिवर्तनों के साथ डिपेंडाबॉट पुल रिक्वेस्ट संभवतः निर्माण प्रक्रिया या p5.js कार्यक्षमता को प्रभावित करेंगे। इस मामले में, यदि संभव हो तो समीक्षक को वर्तमान संस्करण से लक्ष्य संस्करण तक चेंजलॉग की समीक्षा करने के लिए प्रोत्साहित किया जाता है। उनसे यह भी अपेक्षा की जाती है कि वे स्थानीय स्तर पर पुल रिक्वेस्ट का परीक्षण करें ताकि यह सुनिश्चित किया जा सके कि सभी प्रक्रियाएं कार्य कर रही हैं, और निर्भरता में संभावित ब्रेकिंग परिवर्तनों के कारण कोई भी आवश्यक परिवर्तन करें। - कई निर्भरताओं ने मुख्य संस्करण संख्याओं को केवल इसलिए बढ़ाया है क्योंकि वे बहुत पुराने संस्करणों के लिए आधिकारिक समर्थन को हटा देते हैं। बहुत से मामलों में, मुख्य संस्करण परिवर्तन निर्भरता एपीआई परिवर्तन से होने वाले तोड़फोड़ को नहीं अवश्य मतलब है। --- @@ -284,12 +284,12 @@ grunt watch:quick ## युक्तियाँ और ट्रिक्स -कभी-कभी, समीक्षा के लिए जितने भी जटिल पुल अनुरोध हैं, उन्हें स्थानीय रूप से परीक्षण करने के लिए गिट के जटिल कमांड की आवश्यकता हो सकती है। भाग्य से, गिटहब सीएलआई टूल इस प्रक्रिया और अधिक के साथ बहुत मदद कर सकता है। +कभी-कभी, समीक्षा के लिए जितने भी जटिल पुल रिक्वेस्ट हैं, उन्हें स्थानीय रूप से परीक्षण करने के लिए गिट के जटिल कमांड की आवश्यकता हो सकती है। भाग्य से, गिटहब सीएलआई टूल इस प्रक्रिया और अधिक के साथ बहुत मदद कर सकता है। ### उत्तर टेम्पलेट एक आसान गिटहब सुविधा जिसका आप उपयोग कर सकते हैं वह है [उत्तर टेम्पलेट](https://docs.github.com/en/get-started/writing-on-github/working-with-saveled-replies/about-saveled-replies), जो समस्या -या पुल अनुरोधों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ समस्याएं या पुल अनुरोध का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी समस्या को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। +या पुल रिक्वेस्टों का उत्तर लिखते समय उपयोग के लिए उपलब्ध है। ऊपर वर्णित कुछ वर्कफ़्लो में समान या बहुत समान उत्तरों के साथ समस्याएं या पुल रिक्वेस्ट का जवाब देने की आवश्यकता हो सकती है (प्रश्नों को फ़ोरम पर पुनर्निर्देशित करना, फिक्सिंग के लिए किसी समस्या को स्वीकार करना, आदि), और सहेजे गए उत्तरों का उपयोग करना इसे थोड़ा और अधिक कुशल बना सकता है। नीचे कुछ सहेजे गए उत्तर दिए गए हैं जिनका उपयोग p5.js अनुरक्षकों द्वारा किया जा रहा है। आप उन्हें स्वयं उपयोग कर सकते हैं या अपना खुद का बना सकते हैं! @@ -319,29 +319,29 @@ grunt watch:quick > मुझे लगता है कि यह फ़ंक्शन p5.js एपीआई के दायरे से परे है (हम इसे यथासंभव न्यूनतम रखने की कोशिश करते हैं), लेकिन यह एक ऐडऑन लाइब्रेरी के लिए एक बेहतरीन शुरुआती बिंदु हो सकता है। ऐडऑन बनाने के तरीके के लिए यहां दस्तावेज़ देखें: [https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md](creating_libraries.md) -##### समापन पुल अनुरोध: पहले समस्या की आवश्यकता है +##### समापन पुल रिक्वेस्ट: पहले समस्या की आवश्यकता है -> धन्यवाद. एक अनुस्मारक के रूप में, पुल अनुरोधों को खोलने और समस्या के साथ टैग करने से पहले समस्याएं को खोला जाना चाहिए। विकास पर नज़र रखने और चर्चा को स्पष्ट रखने के लिए यह आवश्यक है। धन्यवाद! +> धन्यवाद. एक अनुस्मारक के रूप में, पुल रिक्वेस्टों को खोलने और समस्या के साथ टैग करने से पहले समस्याएं को खोला जाना चाहिए। विकास पर नज़र रखने और चर्चा को स्पष्ट रखने के लिए यह आवश्यक है। धन्यवाद! ##### समस्या को ठीक करने के लिए स्वीकृति दें > आप सुधार के साथ आगे बढ़ सकते हैं। धन्यवाद। -##### मर्ज किया गया पुल अनुरोध +##### मर्ज किया गया पुल रिक्वेस्ट > किये गये परिवर्तन मुझे अच्छे लग रहे हैं। धन्यवाद! ### गिटहब सीएलआई -आपके परीक्षण के लिए स्थानीय स्तर पर कोड का पुल अनुरोध संस्करण प्राप्त करने के लिए आवश्यक जटिल गिट कमांड के साथ एक जटिल पुल अनुरोध की समीक्षा करना मुश्किल हो सकता है। सौभाग्य से, [गिटहब CLI](https://cli.github.com/) टूल इस प्रक्रिया और बहुत कुछ में काफी मदद कर सकता है। +आपके परीक्षण के लिए स्थानीय स्तर पर कोड का पुल रिक्वेस्ट संस्करण प्राप्त करने के लिए आवश्यक जटिल गिट कमांड के साथ एक जटिल पुल रिक्वेस्ट की समीक्षा करना मुश्किल हो सकता है। सौभाग्य से, [गिटहब CLI](https://cli.github.com/) टूल इस प्रक्रिया और बहुत कुछ में काफी मदद कर सकता है। -CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पुल अनुरोध की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout main`। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पुल अनुरोध में से! +CLI को स्थानीय रूप से लिंक करने के लिए इस आईडी का कमांड `gh pr checkout [पुल रिक्वेस्ट आईडी]` चलाने से पुल रिक्वेस्ट की संस्करण कोड को आपके लिए स्थानीय रूप से प्राप्त करना संभव है, और रिमोट फोर्क को प्राप्त करने, एक ब्रांच बनाने और ब्रांच को चेकआउट करने की प्रक्रिया सभी आपके लिए स्वचालित रूप से की जाती है। मुख्य शाखा पर वापस जाना एक ब्रांच को स्विच करने के लिए उसी तरह होगा जैसे `git checkout main`। आप एक टिप्पणी भी छोड़ सकते हैं बिना वेबपेज पर जाने की आवश्यकता के साथ पुल रिक्वेस्ट में से! गिटहब एसईएलआई में बहुत सारे अन्य कमांड भी उपलब्ध हैं जो आपको उपयोगी हो सकते हैं या नहीं मिल सकते हैं, लेकिन यह एक अच्छा उपकरण है जिसका आपके आसपास होना है किसी भी मामले में। ### सूचनाओं का प्रबंधन -नए समस्याएं या पुल अनुरोध के लिए "समस्याएं" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। +नए समस्याएं या पुल रिक्वेस्ट के लिए "समस्याएं" या "पुल रिक्वेस्ट" टैबों का मैन्युअल निगरानी करने की बजाय, आप रिपो को देखकर "नजर रखना (watch)" कर सकते हैं जिसमें रेपो के नाम के साथ एक आई आइकन है जो रेपो के नाम के विपरीत है। ![गिटहब रिपॉजिटरी पेज के ऊपरी दाएं कोने का क्रॉप किया गया स्क्रीनशॉट, जो बाएं से दाएं केंद्र में बटनों की एक श्रृंखला दिखा रहा है: प्रायोजक (Sponsor), नजर रखना (Watch), शूल (Fork), तारांकित (Starred)](../images/github-repo-metrics.png) @@ -349,4 +349,4 @@ CLI को स्थानीय रूप से लिंक करने क कई मामलों में, आपको GitHub से रेपो में हो रही घटनाओं के बारे में ईमेल भी मिल सकते हैं, और आप इन्हें अपनी [सूचना सेटिंग्स पेज](https://github.com/settings/notifications) से कस्टमाइज़ कर सकते हैं (पूरी तरह से उनका अनसब्सक्राइब करके समेत)। -आपके काम करने के तरीके को ध्यान में रखते हुए इन्हें सेट करना, समस्याओं/पुल अनुरोध समीक्षा को मैन्युअली से खोजने की आवश्यकता न हो और GitHub से अंतहीन सूचनाओं से अधिक भरी होने से बचाने में अंतर हो सकता है। यहां एक अच्छा संतुलन आवश्यक है। एक शुरुआती सुझाव के रूप में, स्टीवर्ड्स को इस रेपो के लिए "समस्याएँ" और "पुल रिक्वेस्ट्स" के लिए देखना चाहिए और इसे "भाग लेना, @मेंशन्स और कस्टम (Participating, @mentions and custom)" पर सेट करना चाहिए। +आपके काम करने के तरीके को ध्यान में रखते हुए इन्हें सेट करना, समस्याओं/पुल रिक्वेस्ट समीक्षा को मैन्युअली से खोजने की आवश्यकता न हो और GitHub से अंतहीन सूचनाओं से अधिक भरी होने से बचाने में अंतर हो सकता है। यहां एक अच्छा संतुलन आवश्यक है। एक शुरुआती सुझाव के रूप में, स्टीवर्ड्स को इस रेपो के लिए "समस्याएँ" और "पुल रिक्वेस्ट्स" के लिए देखना चाहिए और इसे "भाग लेना, @मेंशन्स और कस्टम (Participating, @mentions and custom)" पर सेट करना चाहिए।