本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
為開發指南做貢獻
當大多數人想到為開源專案做貢獻時，我猜他們可能會想到貢獻程式碼更改、新功能和錯誤修復。作為一名軟體工程師和資深的開源使用者和貢獻者，這確實是我的想法。儘管我在不同的工作流程中編寫了大量的文件，但Kubernetes社群的龐大規模是一種全新的“客戶”。當Google要求我和我的同事在Lion's Way對Kubernetes開發指南進行急需的更新時，我不知道會發生什麼。
本文最初發表於Kubernetes貢獻者社群部落格。
與社群合作的樂趣
作為專業作家，我們習慣於受僱撰寫非常具體的作品。我們專注於技術服務和產品的營銷、培訓和文件，這可以涵蓋從相對輕鬆的營銷電子郵件到面向IT和開發人員的深度技術白皮書。對於這種專業的服務，每個可交付成果都傾向於有可衡量的投資回報。我知道在處理開源文件時不會出現這個指標，但我無法預測它會如何改變我與專案的關係。
我們寫作與傳統客戶關係的主要特點之一是，我們公司內部始終有一到兩個主要聯絡人。這些聯絡人負責審查我們的作品，並確保它符合公司的口吻，並針對他們所尋找的受眾。這可能會很有壓力——這就是為什麼我很高興我的寫作夥伴、眼光敏銳的審閱者和鐵腕編輯Joel處理了大部分客戶聯絡。
與Kubernetes社群合作時，所有客戶聯絡的壓力都煙消雲散了，這讓我感到驚訝和高興。
“我必須多麼小心？如果我搞砸了怎麼辦？如果我惹惱了開發者怎麼辦？如果我樹敵了怎麼辦？”當我第一次加入Kubernetes Slack上的#sig-contribex頻道並宣佈我將致力於開發指南時，這些問題都在我腦海中飛快閃過，讓我感覺像是在走鋼絲。
“Kubernetes行為準則生效中，請大家互相尊重。”——Jorge Castro，SIG ContribEx 聯席主席
我的擔心是沒有根據的。我立刻感受到了歡迎。我想這不僅僅是因為我正在做一項急需的任務，更是因為Kubernetes社群充滿了友好、熱情的人。在每週的SIG ContribEx會議上，我們關於開發指南進展的報告立即被納入。此外，會議主席總是強調Kubernetes行為準則是有效的，我們應該像比爾和特德一樣，互相尊重。
這並不意味著一切都很容易
《開發指南》需要進行一次相當徹底的修訂。當我們拿到它時，它已經包含了大量資訊和新開發者需要經歷的許多步驟，但它已經因年久失修而積滿了灰塵。文件真的需要全域性性的審視，而不僅僅是零星的修復。結果，我最終向社群倉庫提交了一個龐大的拉取請求：增加了267行，刪除了88行。
拉取請求的生命週期要求一定數量的Kubernetes組織成員在合併更改之前對其進行審查和批准。這是一個很好的做法，因為它使文件和程式碼都保持良好狀態，但說服合適的人花時間進行如此重要的審查可能會很困難。結果，那個龐大的PR從我第一次提交到最終合併花了26天。但最終，它成功了。
由於 Kubernetes 是一個快速發展的專案，並且開發人員通常對編寫文件不那麼熱衷，我還遇到了一個問題：有時，描述 Kubernetes 子系統工作原理的秘密寶藏深埋在一位傑出工程師迷宮般的思維中，而不是以通俗易懂的英語寫在 Markdown 檔案裡。當需要更新端到端 (e2e) 測試的入門文件時，我直接遇到了這個問題。
我旅程的這一部分將我帶出了文件編寫領域，進入了全新使用者使用未完成軟體的角色。我最終與新的kubetest2 框架的開發人員之一合作，記錄了 e2e 測試的最新啟動和執行過程，但這需要我撓頭苦思。您可以檢視我已完成的拉取請求，自行判斷結果。
沒有人是老闆，每個人都提供反饋
儘管我暗地裡預料到會一片混亂，但為Kubernetes開發指南做貢獻以及與令人驚歎的Kubernetes社群互動過程卻異常順利。沒有爭議。我沒有樹敵。每個人都非常友好和熱情。這非常愉快。
在一個開源專案中，沒有一個老闆。龐大的Kubernetes專案被分為許多不同的特別興趣小組（SIGs）、工作組和社群。每個都有自己定期安排的會議、分配的職責和選舉出的主席。我的工作與SIG ContribEx（負責監督和改善貢獻者體驗）和SIG Testing（負責測試）的努力相交叉。這兩個SIG都證明了易於合作，渴望貢獻，並且充滿了非常友好和熱情的人。
在一個像Kubernetes這樣活躍的、有生命力的專案中，文件與程式碼庫一樣，持續需要維護、修訂和測試。《開發指南》將繼續對新貢獻者加入Kubernetes程式碼庫至關重要，正如我們的努力所表明的那樣，這份指南與Kubernetes專案的發展保持同步非常重要。
喬爾和我非常喜歡與Kubernetes社群互動，併為《開發指南》做出貢獻。我真的很期待繼續貢獻更多，並繼續在這龐大的開源社群中，與我在過去幾個月裡結識的新朋友們建立友誼。