community/contributors/guide/contributor-cheatsheet/README-hi.md

कुबेरनेट्स योगदानकर्ता चीट शीट

कुबेरनेट्स परियोजना में उपयोग किए जाने वाले कुबेरनेट्स,टिप्स, ट्रिक्स और सामान्य सर्वोत्तम प्रथाओं में योगदान करते समय सामान्य संसाधनों की एक सूची। यह एक "TL;DR" या आपके GitHub योगदान अनुभव को बेहतर बनाने के लिए उपयोगी जानकारी का त्वरित संदर्भ है।

विषय - सूची

• सहायक संसाधन
  • आरंभ करना
  • SIGS और अन्य समूह
  • समुदाय
  • महत्वपूर्ण ईमेल उपनाम
  • वर्कफ़्लो
  • परीक्षण
• GitHub पर प्रभावी रूप से संवाद
  • अन्य उपयोगी लिंक्स
  • एक-दूसरे के लिए उत्कृष्ट कैसे बनें
    • अच्छे / बुरे संचार के उदाहरण
• कंट्रीब्यूशन सबमिट करना
  • CLA पर हस्ताक्षर करना
  • मुद्दों को खोलना और जवाब देना
    • एक मुद्दा बनाना
    • एक मुद्दे पर प्रतिक्रिया
  • एक Pull Request खोलना
    • एक Pull Request बनाना
    • उदाहरण PR विवरण
    • Pull Request की समस्या निवारण करना
  • लेबल
• स्थानीय स्तर पर काम करना
  • शाखा रणनीति
    • Upstream जोड़ना
    • अपने Fork को समक्रमण में रखना
  • स्क्वाशिंग कमिट्स

---

सहायक संसाधन

आरंभ करना

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

SIGS और अन्य समूह

• मास्टर समूह सूची

समुदाय

• कैलेंडर - सभी कुबेरनेट समुदाय की कार्यक्रम (SIG/WG मीटिंग, ईवेंट आदि) देखें
• kubernetes-dev - कुबेरनेट्स विकास मेलिंग सूची|
• कुबरनेट्स फ़ोरम - आधिकारिक कुबेरनेट्स मंच।
• Slack चैनल - आधिकारिक कुबेरनेट्स Slack|
• StackOverflow - अपने कुबेरनेट्स के अंत-उपयोगकर्ता प्रश्न पूछने के लिए एक जगह
• YouTube चैनल - कुबेरनेट्स समुदाय के लिए आधिकारिक चैनल।

वर्कफ़्लो

• Prow - कुबेरनेट्स CI/CD सिस्टम।
• Tide - मर्ज और परीक्षण का प्रबंधन करने वाले प्लगइन को साबित करें। [टाइड डैशबोर्ड]
• बॉट कमांड - कमांड को कुबेरनेट्स बॉट्स के साथ बातचीत करने के लिए इस्तेमाल किया जाता है (उदाहरण: /cc, /lgtm, और /retest)
• Github लेबल - कुबेरनेट्स प्रोजेक्ट में प्रयुक्त लेबल की सूची।
• कुबरनेट्स Code Search, @dims द्ववारा बनाए रखा गया है।

टेस्ट

• Prow - कुबेरनेट्स CI / CD सिस्टम।
• परीक्षण ग्रिड - ऐतिहासिक परीक्षण और उनसे जुड़ी जानकारी देखें।
• triage डैशबोर्ड - बेहतरलिए समान विफलताओं को एक साथ समस्या निवारण केरखता है।

महत्वपूर्ण ईमेल उपनाम

• community@kubernetes.io - किसी सामुदायिक समस्या के बारे में समुदाय टीम (SIG योगदानकर्ता अनुभव) पर किसी को मेल करें।
• conduct@kubernetes.io - आचार संहिता समिति से संपर्क करें, निजी मेलिंग सूची।
• steering@kubernetes.io - स्टीयरिंग कमेटी को मेल करें। सार्वजनिक संग्रह के साथ सार्वजनिक पता।
• steering-private@kubernetes.io - संवेदनशील आइटम के लिए निजी तौर पर स्टीयरिंग कमेटी को मेल करें।
• social@cncf.io - CCNF सामाजिक टीम से संपर्क करें; ब्लॉग, ट्विटर अकाउंट और अन्य सामाजिक गुण।

अन्य उपयोगी लिंक्स

• डेवलपर आँकड़े - सभी CNCF प्रबंधित परियोजनाओं के लिए डेवलपर आँकड़े देखें।

---

GitHub पर प्रभावी रूप से संवाद

एक-दूसरे के लिए उत्कृष्ट कैसे बनें

पहले चरण के रूप में, अपने आप को आचार संहिता से परिचित कराएं।

अच्छे / बुरे संचार के उदाहरण

समस्या उठाते समय, या सहायता मांगते हुए, कृपया अपने अनुरोध के साथ विनम्र बनें:

🙂 “जब मैं Y करता हूं, तो X कोई संकलन नहीं करता है, क्या आपके पास कोई सुझाव है?"

😞 "X काम नहीं करता है! कृपया इसे ठीक करे!"

PR को बंद करते समय, एक व्याख्यात्मक और सौहार्दपूर्ण संदेश देते हुए समझाएं कि यह विलय की जाने वाली आवश्यकताओं को पूरा क्यों नहीं करता है।

🙂 "मैं इस पीआर को बंद कर रहा हूं क्योंकि यह सुविधा उपयोग के मामले में X का समर्थन नहीं कर सकती है। यह प्रस्तावित रूप में है, यह वाई टूल के साथ लागू किया जाना बेहतर होगा। इस पर काम करने के लिए धन्यवाद।”

😞 "यह API सम्मेलनों का पालन क्यों नहीं कर रहा है? यह कहीं और किया जाना चाहिए!”

---

कंट्रीब्यूशन सबमिट करना

CLA पर हस्ताक्षर करना

योगदान देने से पहले, आपको Contributor License Agreement(CLA) पर हस्ताक्षर करना चाहिए। कुबेरनेट्स परियोजना only एक योगदान स्वीकार कर सकती है यदि आपने या आपकी कंपनी ने सीएलए पर हस्ताक्षर किए हैं।

यदि आप सीएलए पर हस्ताक्षर करने में किसी भी समस्या का सामना करते हैं, तो सCLA समस्या निवारण दिशा निर्देशों का पालन करें।

मुद्दों को खोलना और जवाब देना

GitHub मुद्दे, बग रिपोर्ट, एन्हांसमेंट निवेदन जैसी चीजों को ट्रैक करने या फेल होने वाले टेस्ट जैसे अन्य मुद्दों की रिपोर्टिंग के प्राथमिक साधन हैं। वे उपयोगकर्ता समर्थन अनुरोध के लिए अभिप्रेत नहीं हैं। उन लोगों के लिए, समस्या निवारण गाइड के साथ जाँच करें, समस्या को StackOverflow पर रिपोर्ट करें यापर फॉलो करें कुबरनेट्स फ़ोरम।

संदर्भ:

• लेबल
• Prow आदेश

एक मुद्दा बनाना

• यदि कोई उपलब्ध है तो एक समस्या टेम्पलेट का उपयोग करें। सही का उपयोग करने से आपकी समस्या के जवाब में अन्य योगदानकर्ताओं को सहायता मिलेगी।
  • अंक टेम्पलेट में वर्णित किसी भी दिशा-निर्देश का पालन करें।
• जिस मुद्दे को आप उठा रहे हैं, उसके साथ वर्णनात्मक बनें।
• उचित लेबल असाइन करें। यदि आप अनिश्चित हैं, तो k8s-ci-robot bot (Kubernetes CI bot) आपकी समस्या के लिए आवश्यक लेबल के साथ आपके मुद्दे का जवाब देगा।
• /assign @<username> याका उपयोग करके मुद्दों को असाइन करते समय चयन करें /cc @<username>। आपकी समस्या को और अधिक प्रभावी ढंग सेकरने परलगाने में मदद मिलेगी सही लोगों को समस्या के लिए असाइन सही लेबल।

एक मुद्दे पर प्रतिक्रिया

• जब किसी मुद्दे से निपटते हैं, तो उस पर टिप्पणी करें जिससे दूसरों को पता चले कि आप उस पर काम कर रहे हैं ताकि डुप्लिकेट काम से बच सकें।
• जब आप किसी भी भविष्य के समय में अपने दम पर कुछ हल कर लेते हैं, तोपर टिप्पणी करें इस मुद्दे जिससे लोगों को इसे बंद करने से पहले पता चल सके।
• अन्य PR या मुद्दों(या किसी भी सुलभ सामग्री) के संदर्भ शामिल करें, उदाहरण: "ref: #1234"। यह पहचानना उपयोगी है कि संबंधित कार्य कोकिया गया कहीं और संबोधित है।

एक Pull Request खोलना

खींचो अनुरोध (PR) कोड, प्रलेखन या योगदान के मुख्य साधन हैं अन्य प्रकार के कार्य जो एक गिट रिपॉजिटरी के भीतर संग्रहीत किए जाएंगे।

संदर्भ:

• लेबल
• Prow आदेश
• पुल अनुरोध प्रक्रिया
• Github वर्कफ़्लो

एक Pull Request बनाना

• एक उपलब्ध होने पर पुल अनुरोध टेम्पलेट के निर्देशों का पालन करें । यह उन लोगों की मदद करेगा जो आपके PR पर प्रतिक्रिया करते हैं।
• अगर एक [तुच्छ निर्धारण] जैसे टूटी हुई कड़ी, टाइपो या व्याकरण की गलती,समीक्षा करें अन्य संभावित गलतियों के लिए पूरे दस्तावेज़ की।लिए कई PR न खोलें एक ही दस्तावेज़ में छोटे फ़िक्सेस के।
• अपने PR से संबंधित किसी भी मुद्दे, या PR को हल करने वाले मुद्दों को संदर्भित कर सकते हैं।
• सिंगल कमिट में अत्यधिक बड़े बदलाव करने से बचें। इसके बजाय, अपने PR तोड़ें को कई छोटे, तार्किक रूप से। इससे आपके PR करना आसान हो जात है की समीक्षा।
• अपने स्वयं के PR पर टिप्पणी करें जहां आप मानते हैं कि कुछ और आवश्यकता हो सकती है स्पष्टीकरण की।
• जब आप अपने PR को /assign @<username> के साथ सेलेक्ट करें। अत्यधिक समीक्षकों को असाइन करने से एक त्वरित पीआर समीक्षा नहीं होगी।
• यदि आपका PR एक "work in progress" माना जाता है, तो '[WIP]' के साथ नाम उपसर्ग करें या [/hold][होल्ड] कमांड का उपयोग करें। यह PR कोविलयसे रोकेगा तब तकहोनेजब तक [WIP] या पकड़ को हटा नहीं दिया जाता।
• यदि आपने अपने PR की समीक्षा नहीं की है, तोसाथ एक नया PR बंद न करें और खोलें उसी परिवर्तनों के। अपने समीक्षकों को एक टिप्पणी में @<github username> के साथ पिंग करें।

उदाहरण PR विवरण

Ref. #3064 #3097
SIG परीक्षण के स्वामित्व वाली सभी फाइलें `/devel` से नए फ़ोल्डर `/devel/sig-testing` में ले जाया गया।

/ sig योगदानकर्ता-अनुभव
/ cc @स्टेकहोल्डर1 @स्टेकहोल्डर2
/ तरह क्लीनअप
/ एरिया डेवलपर-गाइड
/ असाइन करें @अनुमोदक1 @अनुमोदक2 @अनुमोदक3

उस PR में क्या है:

• लाइन 1 - अन्य मुद्दों या संदर्भ (#3064 #3097)।
• लाइन 2 - PR में क्या किया जा रहा है, इसका संक्षिप्त विवरण।
• लाइन 4 - SIG [कमांड][कमांड] के साथ असाइनमेंट /sig contributor-experience..
• लाइन 5 - समीक्षकों कि इस विशिष्ट मुद्दे पर रुचि हो सकती है या PR को /cc कमांड के साथ निर्दिष्ट किया गया है।
• लाइन 6 - /kind cleanup कमांड एक लेबल जोड़ते हैं जो कोड या प्रक्रिया सफाई या तकनीकीसे संबंधि समस्या या PR को वर्गीकृत करता है ऋण।
• लाइन 7 - /area developer-guide कमांडसमस्या यावर्गीकृत डेवलपर गाइड से संबंधित PR कोकरता है।
• लाइन 8 - कमांड /assign PR को एक अनुमोदन प्रदान करता है। एक अनुमोदन k8s-ci-robot द्वारा सुझाया जाएगा और इसेसे चुना गया है [OWNERS] फ़ाइल में मालिकों की सूची। वेमेंजोड़ देंगे समीक्षा के बाद PR[/approve][approve] लेबल।

Pull Request की समस्या निवारण करना

आपके PR के प्रस्तावित होने के बाद, एक, कुबेरनेट्स CI प्रूद्वारा परीक्षणों की एक श्रृंखला निष्पादित की जाती है प्लेटफॉर्म,Prow। यदि कोई भी परीक्षण विफल रहा, तो k8s-ci-robot विफल परीक्षणों और उपलब्ध लॉग्स के लिंक के साथ PR को उत्तर देगा।

अपने PR के लिए नए काम करता है स्वचालित रूप से फिर से चलाने के लिए परीक्षण ट्रिगर होगा।

कभी-कभी कुबेरनेट्स CI प्लेटफॉर्म के साथ समस्याएं हो सकती हैं। येहो सकते हैं कई कारणों से, भले ही आपका योगदान सभी स्थानीयगुजरता हो परीक्षणों से। आप /retest कमांड के साथ परीक्षणों को फिर से चला सकते हैं।

विशिष्ट परीक्षणों के समस्या निवारण के बारे में अधिक जानकारी के लिए, परीक्षण गाइड देखें।

लेबल

कुबेरनेट्स मुद्दों और हल अनुरोधों को वर्गीकृत और ट्राइ करने के लिए लेबल का उपयोग करता है। सही लेबल लगाने से आपकी समस्या या PR को अधिकनियंत्रित करने में मदद मिलेगी प्रभावी रूप से।

संदर्भ:

• लेबल
• Prow आदेश

अक्सर इस्तेमाल किए जाने वाले लेबल:

• /sig <sig name> मुद्दे या PR के स्वामित्व के लिए एक SIG असाइन करें।
• /area <area name> किसी विशिष्ट क्षेत्र के लिए या PR संबद्ध करें।
• /kind <category> समस्या या PR को वर्गीकृत करता है।।

स्थानीय स्तर पर काम करना

पहले, आपकोस ्तर पर काम करने का अनुरोध करना होगा स्थानीय। यदि आप git के लिए नए हैं, तो Atlassian git tutorial एक अच्छा प्रारंभिक बिंदु है। एक विकल्प के रूप में, स्टैनफोर्ड का Git magic ट्यूटोरियल एक अच्छा बहु-भाषा विकल्प है।

संदर्भ:

• Atlassian git tutorial
• Git magic
• Github वर्कफ़्लो
• स्थानीय स्तर पर परीक्षण
• डेवलपर गाइड

शाखा रणनीति

कुबेरनेट्स परियोजना एक "fork और pull" वर्कफ़्लो का उपयोग करती है जो कि GitHub के लिए मानक है। Git शब्दों में, आपके व्यक्तिगत फोर्क को "origin" के रूप में संदर्भित किया जाता है और वास्तविक परियोजना के Git रिपॉजिटरी को "upstream" कहा जाता है। अपनी व्यक्तिगत शाखा (origin) को प्रोजेक्ट (upstream) तक अद्यतित रखने के लिए, इसे आपकी स्थानीय कामकाजी प्रति के भीतर कॉन्फ़िगर किया जाना चाहिए।

Upstream जोड़ना

एक रिमोट के रूप में upstream जोड़ें, और इसे कॉन्फ़िगर करें ताकि आप इसे पुश न कर सकें।

# Upstream रेपो यूआरएल के साथ <upstream git repo> को बदलें
# उदाहरण:
#  https://github.com/kubernetes/kubernetes.git
#  git@github.com/kubernetes/kubernetes.it

git remote add upstream <upstream git repo>
git remote set-url --push upstream no_push

यह git remote -v चलाकर सत्यापित किया जा सकता है जो आपके कॉन्फ़िगर किए गए रीमोट को सूचीबद्ध करेगा।

अपने Fork को समक्रमण में रखना

सभी परिवर्तनों को upstream और rebase से प्राप्त करें, उन पर अपने स्थानीय master की शाखा यह upstream प्रोजेक्ट के साथ आपके स्थानीय रेपो को सिंक करेगा।

git fetch upstream
git checkout master
git rebase upstream/master

अपनी सुविधा पर काम करने या ठीक करने के लिए नई शाखा बनाने से पहले आपको यह न्यूनतम करना चाहिए।

git checkout -b myfeature

स्क्वाशिंग कमिट

स्क्वाशिंग कमिट का मुख्य उद्देश्य एक साफ पठनीय गिट इतिहास या उन बदलावों का लॉग बनाना है जो किए गए थे। आमतौर पर यह आखिरी में किया जाता है PR संशोधन का चरण। यदि आप अनिश्चित हैं यदि आपको अपने कमिट्स को स्क्वैश करना चाहिए, तो अधिक होने के पक्ष में गलती करना बेहतर है और इसे अपने PR की समीक्षा और अनुमोदन करने के लिए सौंपे गए अन्य योगदानकर्ताओं के निर्णय तक छोड़ दें।