कुबेरनेटस रिलीज चक्र मे प्रलेखन की देख रेख और प्रकाशन करते हैं
शुरू करना
कोई भी प्रलेखन के बारे मे इशू खोल सकता है या कुबेरनेटस वेबसाइट
kubernetes/website GitHub रिपॉजिटरी
मे बदलाव पुल अनुरोध (PR) द्वारा कर सकता है।
आपको Git और
Github
की जानकारी होनी चाहिए ताकि आप कुबेरनेटेस समुदाय मे प्रभावी रूप से काम कर सकें।
flowchart TB
subgraph third[PR ओपन करे]
direction TB
U[ ] -.-
Q[विषय सुधारे] --- N[विषय निर्माण करे]
N --- O[डॉक्स का अनुवाद करे]
O --- P[K8s रिलीज़ चक्र के प्रलेखन को संचालित /प्रकाशित करें]
end
subgraph second[समीक्षा]
direction TB
T[ ] -.-
D[kubernetes/website रिपॉजिटरी को देखें] --- E[Hugo स्टैटिक साइट जनरेटर को देखें]
E --- F[मूलभूत GitHub कमांड समझें]
F --- G[ओपन PR की समीक्षा करे और समीक्षा प्रक्रिया को बदलें]
end
subgraph first[साइनअप]
direction TB
S[ ] -.-
B[CNCF योगदानकर्ता लइसेंस समझौता पर हस्ताक्षर करें] --- C[sig-docs स्लैक चैनल में जुड़ें]
C --- V[kubernetes-sig-docs मेलिंग लिस्ट में जुड़ें]
V --- M[साप्ताहिक sig-docs कॉल या स्लैक बैठक में शामिल हों]
end
A([fa:fa-user नए योगदानकर्ता]) --> first
A --> second
A --> third
A --> H[सवाल पूछे!!!]
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
class S,T,U spacewhite
class first,second,third white
आकृति - नए योगदानकर्ताओं के लिए योगदान शुरू करने का रास्ता
ऊपर दी गई आकृति नए योगदानकर्ता के लिए दिशानिर्देश हैं। Sign up या review के लिए आप इनमे से कुछ या सभी निर्देशों का पालन कर सकते हैं। अब आप PR ओपन करने के लिए तैयार हैं जो आपके योगदान के उद्देश को पूरा करे जो Open PR खंड मे सूचीबद्ध हैं। आपके सभी प्रश्नों का सदैव स्वागत है।
कुबेरनेटस समुदाय मे कुछ कार्यों के लिए अधिक विश्वास और अभिगम की आवश्यकता होती है।
भूमिका और अनुमति के बारे मे ज्यादा जानकारी के लिए SIG Docs मे भाग लेना को देखें।
आपका पहला योगदान
आप अपने पहले योगदान की तैयारी के लिए दिए गए दिशानिर्देश को देख सकते हैं। नीचे दिया हुआ चित्र दिशानिर्देश और उसकी विस्तार मे जानकारी देता है।
flowchart LR
subgraph second[पहला योगदान]
direction TB
S[ ] -.-
G[दूसरे K8s मेम्बर्स के PRs की समीक्षा करें] -->
A[अपने पहले इशू (गुफ फर्स्ट इशू) के लिए kubernetes/website की इशू सूची पर जाएं] --> B[PR ओपन करें!!]
end
subgraph first[सूचित तैयारी]
direction TB
T[ ] -.-
D[योगदान अवलोकन को पढे] -->E[K8s विषय और विषय गाइड को पढ़ें]
E --> F[Hugo पेज विषय के प्रकार और shortcodes के बारे मे जाने]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,D,E,F,G grey
class S,T spacewhite
class first,second white
आकृति - आपके पहले योगदान की तैयारी
योगदान करने के विभिन्न तरीकों को जानने के लिए योगदानकर्ता अवलोकन को पढ़ें।
SIG Docs योगदानकर्ताओ का एक समूह है
जो कुबेरनेटेस प्रलेखन और वेबसाईट की देख रेख और उसे प्रकाशित करता है।
SIG Docs मे शामिल होना कुबेरनेटस योगदानकर्ताओ (फीचर विकास या उससे अन्यथा) के लिए
कुबेरनेटस परियोजना पर प्रभाव डालने का बेहतरीन तरीका है।
SIG Docs विडिओ बैठक मे शामिल हो जो हर दो सप्ताह मे होती है। बैठक की घोषणा हमेशा #sig-docs पर की जाती है और कुबेरनेटेस समुदाय बैठक कैलंडर में जोड़ दिया जाता है। आपको Zoom client डाउनलोड करने की जरूरत पड़ेगी या फोन की मदद से भी डायल कर सकते हैं।
जिन सप्ताह मे Zoom बैठक नहीं हुई हो तब SIG Docs अतुल्यकालिक बैठक को जॉइन करे जो Slack पर होती है। बैठक की घोषणा हमेशा #sig-docs पर होती है। बैठक की घोषणा के बाद आप किसी भी सूत्र मे 24 घंटे तक योगदान कर सकते है।
योगदान करने के अन्य तरीके
कुबेरनेटस समुदाय साइट पर जाए। Twitter या Slack Overflow मैं भाग ले, कुबेरनेटस स्थानीय आयोजन और मिलन के बारे मे जाने ।
SIG Docs के समीक्षक और
अनुमोदक किसी भी बदलाव को review करते वक्त
कुछ अलग काम भी करते हैं।
हर हफ्ते एक docs approver pull requests को triage और review करने की जिम्मेदारी लेता है —
उसे उस हफ्ते का "PR Wrangler" कहते हैं। ज्यादा जानकारी के लिए
PR Wrangler scheduler देखें।
PR Wrangler बनने के लिए SIG Docs की हफ्तेवारी मीटिंग में आएं और अपना नाम दें।
अगर आप उस हफ्ते schedule पर नहीं हैं, तब भी आप ऐसे PRs देख सकते हैं जिन पर अभी किसी की नजर नहीं है।
इसके अलावा एक bot भी है जो affected files के owners के हिसाब से reviewers और approvers
को PR assign करता है।
pull request review करना में जो कुछ भी लिखा है
वो सब तो लागू होता ही है, लेकिन reviewers और approvers को ये भी करना चाहिए:
जरूरत पड़ने पर किसी खास reviewer को PR assign करने के लिए /assign Prow command का इस्तेमाल करें।
खासकर तब जब code contributors से technical review माँगनी हो।
टिप्पणी:
Markdown file के ऊपर front-matter में reviewers field देखें — वहाँ लिखा होता है कि
technical review कौन दे सकता है।
देखें कि PR, Content और
Style guide को follow कर रहा है या नहीं।
अगर नहीं कर रहा तो author को उस guide का link दें।
जहाँ जरूरी लगे, वहाँ GitHub के Request Changes option से PR author को changes suggest करें।
अगर आपके suggestions लागू हो जाएं तो /approve या /lgtm Prow command से
GitHub में अपना review status update करें।
किसी और के PR में commit करना
PR पर comments छोड़ना तो ठीक है, लेकिन कभी-कभी आपको सीधे किसी और के PR में
commit करना पड़ सकता है।
किसी का PR "take over" मत करें जब तक वो खुद न कहे, या फिर PR काफी समय से
पड़ा हो और उसे जगाना जरूरी हो। हाँ, इससे काम जल्दी हो जाता है — लेकिन उस
contributor को सीखने का मौका चला जाता है।
आप क्या करेंगे यह इस बात पर निर्भर करता है — क्या उस file को edit करना है जो
PR में पहले से है, या कोई नई file जोड़नी है।
इन दोनों में से कोई भी स्थिति हो तो आप किसी और के PR में commit नहीं कर सकते:
PR author ने अपनी branch सीधे
https://github.com/kubernetes/website/
repository में push की हो। ऐसे में सिर्फ वही reviewer commit कर सकता है जिसके पास
push access हो।
टिप्पणी:
Author को समझाएं कि अगली बार PR खोलने से पहले branch को अपने fork में push करें।
PR author ने approvers को edit करने से मना किया हो।
Review के लिए Prow commands
Prow
Kubernetes का CI/CD system है जो PRs पर jobs चलाता है। इससे आप GitHub comments में
chatbot जैसे commands दे सकते हैं — जैसे labels लगाना और हटाना,
issues बंद करना, या approver assign करना। Commands का format होता है /<command-name>।
Reviewers और approvers जो commands सबसे ज्यादा use करते हैं:
Review के लिए Prow commands
Prow Command
किसके लिए
क्या करता है
/lgtm
Organization members
बताता है कि आपने PR review कर लिया और changes ठीक हैं।
/approve
Approvers
PR को merge के लिए approve करता है।
/assign
कोई भी
किसी को PR review या approve करने के लिए assign करता है।
/close
Organization members
कोई issue या PR बंद करता है।
/hold
कोई भी
do-not-merge/hold label लगाता है — यानी PR अभी auto-merge नहीं होगा।
SIG Docs आमतौर पर
Kubernetes issue triage
process को follow करता है और वही labels use करता है।
यह GitHub Issue filter
उन issues को दिखाता है जिन्हें triage की जरूरत हो सकती है।
किसी issue को triage करना
Issue को जाँचें
पहले देखें कि issue सच में website documentation से जुड़ा है या नहीं। कुछ issues
तो बस एक जवाब देने से या सही resource की तरफ भेजने से बंद हो सकते हैं। इसके लिए
सहायता अनुरोध या code bug reports section देखें।
Issue में कोई दम है या नहीं, यह भी तय करें।
अगर issue में काम करने लायक जानकारी नहीं है या template ठीक से नहीं भरा गया,
तो triage/needs-information label लगाएं।
अगर issue पर lifecycle/stale और triage/needs-information दोनों labels हों
तो उसे बंद कर दें।
ध्यान रखें — label पहले से exist करना चाहिए। कोई ऐसा label add करने की कोशिश करेंगे
जो है ही नहीं, तो command बिना कोई error दिए चुपचाप ignore हो जाएगा।
Issues आमतौर पर जल्दी खुलते और बंद होते हैं।
लेकिन कभी-कभी issue खुलने के बाद उस पर कोई activity नहीं होती।
और कभी-कभी issue को 90 दिनों से ज्यादा खुला रखना जरूरी होता है।
Issue lifecycle labels
Label
मतलब
lifecycle/stale
90 दिन तक कोई activity नहीं हुई तो issue अपने आप stale mark हो जाता है। अगर /remove-lifecycle stale command से इसे वापस नहीं किया गया तो issue अपने आप बंद हो जाएगा।
lifecycle/frozen
यह label लगा हो तो issue 90 दिन बाद भी stale नहीं होगा। यह label उन issues पर manually लगाते हैं जिन्हें लंबे समय तक खुला रखना हो — जैसे priority/important-longterm वाले।
खास तरह के issues को handle करना
SIG Docs कुछ खास तरह के issues से अक्सर मिलता है, इसलिए उन्हें handle करने का तरीका
यहाँ लिखा गया है।
Duplicate issues
एक ही समस्या पर कई issues खुले हों तो उन्हें एक में मिला दें। तय करें कि कौन सा issue
खुला रखना है (या चाहें तो नया खोल लें), उसमें सारी जरूरी जानकारी डालें और related issues
को link करें। बाकी सभी issues पर triage/duplicate label लगाकर बंद कर दें। एक issue
रहेगा तो confusion नहीं होगी और एक ही काम दो बार नहीं होगा।
Dead link issues
अगर dead link, API या kubectl documentation में है तो समस्या पूरी तरह समझ आने तक
/priority critical-urgent assign करें। बाकी dead link issues को
/priority important-longterm दें क्योंकि उन्हें manually ठीक करना पड़ता है।
Blog issues
Kubernetes Blog की posts समय के साथ पुरानी हो जाती हैं, यह स्वाभाविक है।
इसलिए हम सिर्फ एक साल से कम पुरानी blog posts को maintain करते हैं। अगर issue किसी
एक साल से पुरानी post से जुड़ा हो तो उसे बिना fix किए बंद करना ठीक रहता है।
कुछ docs issues दरअसल code की समस्याएं होती हैं, या फिर कोई tutorial काम न करने पर
मदद का अनुरोध होता है। ऐसे issues को kind/support label लगाकर बंद करें और एक comment
में उस व्यक्ति को Slack, Stack Overflow जैसी जगहों पर जाने को कहें। अगर bug किसी
feature में है तो kubernetes/kubernetes repository में issue खोलने को कहें।
सहायता अनुरोध के लिए नमूना जवाब:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.
If this is a documentation issue, please re-open this issue.
Code bug report के लिए नमूना जवाब:
This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.
If this is a documentation issue, please re-open this issue.
Squashing
Approver के तौर पर PRs review करते वक्त आपके सामने कई situations आ सकती हैं:
Contributor को commits squash करने की सलाह देना
खुद उनके commits squash करना
अभी squash न करने को कहना
Squashing रोकना
Squash करने की सलाह देना: नए contributors को अक्सर नहीं पता होता कि PRs में
commits squash करने चाहिए। ऐसे में उन्हें बताएं, useful links दें और जरूरत पड़े तो
मदद करने की पेशकश करें। कुछ helpful links:
अगर contributor ने maintainers को PR manage करने दिया हो, तो उनके commits squash
करके उनके fork में result push करें। Squash करने से पहले उन्हें latest changes save
और push करने को कहें। Squash के बाद उन्हें squashed commit pull करने को कहें।
Label लगाकर Tide / GitHub से squash करवा सकते हैं, या merge करते वक्त
Squash commits button click करें।
Squash न करने की सलाह देना
अगर किसी commit ने कुछ गड़बड़ किया हो और आखिरी commit ने उसे ठीक किया हो, तो
squash मत करें। GitHub पर "Files changed" tab और Netlify preview दोनों ठीक दिखेंगे,
लेकिन merge करने से दूसरों के लिए rebase या merge conflicts आ सकते हैं। जैसा उचित
लगे, बीच में आएं।
कभी squash मत करें
अगर आप कोई localization launch कर रहे हों या नए version के लिए docs release कर रहे हों
और किसी user के fork से नहीं बल्कि किसी branch में merge हो रहा हो — commits कभी
squash मत करें। Commit history बनाए रखना जरूरी है।
2 - प्रलेखन शैली अवलोकन
इस खंड के विषय लेखन शैली, सामग्री स्वरूपण, और संगठन, और कुबेरनेट्स प्रलेखन के लिए विशिष्ट Hugo अनुकूलन का उपयोग करने पर मार्गदर्शन प्रदान करते हैं।
3 - साइट विश्लेषिकी देखना
इस पृष्ठ में Kubernetes.io विश्लेषिकी डैशबोर्ड के बारे में जानकारी है।
यह डैशबोर्ड Google Data Studio का उपयोग करके बनाया गया है और Google Analytics का उपयोग करके Kubernetes.io पर एकत्रित जानकारी दिखाता है।
डैशबोर्ड का उपयोग करना
डिफ़ॉल्ट रूप से, डैशबोर्ड पिछले 30 दिनों के सभी एकत्रित विश्लेषण दिखाता है। विभिन्न दिनांक सीमा मे आने वाला डेटा देखने के लिए date selector का उपयोग करें। अन्य फ़िल्टरिंग विकल्प आपको उपयोगकर्ता का स्थान, साइट तक पहुंचने के लिए उपयोग किए जाने वाले उपकरण, उपयोग किए गए दस्तावेज़ों के अनुवाद, और बहुत से चीज़ों का डेटा देखने की अनुमति देते हैं।
यदि आप इस डैशबोर्ड में कोई समस्या देखते हैं, या किसी सुधार का अनुरोध करना चाहते हैं, तो कृपया एक इशू बनाएं।