如何參與 Apache 項目社區

| 作者：tison

| 轉載自：知乎

| 編輯：黃欣宜

| 設計：朱億欽

| 責編：陳梅梅

如何參與到 Apache 項目的開發討論中去，或者更廣泛地說，如何參與到開源項目的開發討論中去，在開源日漸風靡的今天越來越成為一個新手常問的問題。其實參與開源項目並不困難，參與 Apache 項目更有一些具體的套路。我有幸在今年九月份成為 Apache Flink 的 Committer，本文以 Apache Flink 社區為例，介紹作為開發者，如何參與到 Apache 項目社區中去，如何做出自己的貢獻和發表自己的意見。

交流技巧

這裡要擺在第一位的是交流技巧，放在這個具體的環境下即與來自全球各地的開發者協作的語言技巧。毫無疑問，清晰地表達自己的觀點和謙虛地聽取別人的觀點是參與開源社區的一個重要能力。

所謂的社區是由人組成的，社區的活動也是為了解決社區成員的問題而發生的。拋開社區中的人光談技術或者代碼是沒有意義的。在參與社區活動的時候，切忌一個人埋頭苦幹而不與社區交流，要與社區有良好的互動，這樣社區的成員對你的信任感和認可才會提升，你也才能更好的為社區服務。

具體到 Apache Flink 這樣擁有眾多模塊的項目，其中的 Committer 和 PMC 也未必甚至很大可能上不能詳細了解每一個模塊的具體細節。為此，社區的新人想要提升自己的影響力，最好是專注在某一個模塊上，和模塊的 maintainer 保持良好的關係。這樣不管是對新人了解代碼的來龍去脈和未來被推舉成為 Committer 等過程都有幫助。

最早進入 Flink 的時候我基本上每周都會有一個問題問現在 Flink 的 Tech Leader Till，後來跟我家 mentor 另一位 Commiter 施曉罡博士一起工作的時候我也常常纏著他問各種各樣的問題。從 FLIP-6 的框架設計到作業提交的設計，到各個小組件最早的設計構想到如何成為今天的融合怪（bushi）。了解代碼的演化歷史對新人修改代碼的時候不會偶然破壞一些前提假設有莫大的幫助，明白某個模塊想要解決的問題能夠幫助修改代碼時向著目標收斂，和 maintainer 形成的共識和公共知識更能夠使得 Review 的流程更加流暢和順利。

分享兩個道聽途說的說法，一個是據說在評價一個人能否成為 Committer 的時候，有一個通用的指標是「easy to work with」，也就是說合作起來很順暢；另一個是據說情緒化的言語可能會阻礙當選 Committer，即使這個人技術過得去，也貢獻了不少的 patch。

這一部分從實際操作上除了主觀的交流技巧之外，對於國內開發者，有一個重要的事情是要練好英語呀！不管是讀寫還是聽說，都非常的重要。在重大特性的合作討論中，有時會出現郵件列表不能很好的進行溝通的情況，通過一次視頻會議同步觀點就可能能夠使得共識的達成事半功倍進行，這和微信聊不明白的時候打電話或者當面聊是一樣的。熟練的掌握英語特別是流暢的表達技巧能夠使得項目的成員更好的了解你的思路，甚至很快地推舉你成為 PMC，原因就包括了你能夠讓自己對項目發展的看法明確的傳達出去的緣故。畢竟人類不是三體人，也沒有卡拉，只能通過書面或者口頭的方式同步觀點，交流的技巧包括交流工具的熟練都至關重要。

代碼提交技巧

代碼提交技巧放在第二點講是因為從道理上將它不比交流重要，但是對於國內開發者來說在如何向開源項目提交代碼上卻存在一個巨大的常識偏差，即沒有認識到，只要是對代碼倉庫的修改，都算是代碼提交，也都算是你個人的貢獻。

國內的開發者總想搞個大的特性，對其他的小修改都看不上，也就是常說的眼高手低。其實社區的貢獻涉及方方面面，不只是大特性是貢獻，提交問題也是貢獻，回答問題也是貢獻，修復文檔也是貢獻，維護自動化流程也是貢獻。一步一步積累對自己的認可才能得到社區的信賴。你就想想，社區裡突然來了一個從來也沒見過的人，上來就說我們把一個模塊重寫一遍吧，這你敢信他麼。而且閉門造車有的時候自以為搞得特性多麼了不起，其實跟這個模塊的初衷乃至社區的發展方向都是違背的，自然不會得到重視。

混跡開源社區的人常常開的一個玩笑是「fix typo」，通常是看到調侃某個人又在蹭改錯別詞的 commit 了。不過這樣的 commit 對於新手來說是相性非常相合的，我個人也通過「fix typo」的方式接觸過若干個社區。當然，這樣的貢獻是微不足道的，對於有志於做出更大貢獻的開發者來說也不應該完全把時間都用來做編輯的工作。但是這樣的一個貢獻也會走一個正規的（可能有所簡化的）commit 流程，在此期間你可以了解社區的接受代碼提交運作方式。不同社區往往會有不小的差別，例如問題提在 GitHub Issue 上還是 JIRA 上，使用 JIRA 提交 Patch 還是使用 Pull Request 提交 Patch，需要運行怎樣的測試，如何理解測試產出物，commit 的格式等等。保證代碼提交符合規範，能夠節省他人的時間，也能讓社區的成員感覺到你是一個遵守規則的參與者。此外，對於某些第一次接觸開源項目協作的同學來說，還需要通過這樣的過程了解如何使用 Git 和 GitHub 或者其他各種工具的基本使用技巧。通過一個 trivial 的貢獻，能夠避免討論修改細節的負擔，先儘快的掌握這個流程。這也涉及社區對你的觀感，試想一個社區規範都沒搞清楚的人一來就要改代碼，如果不是 trivial 的重構的話，也會審慎三分。當然，防槓起見，如果你已經是一個成熟的開發者，那你看這篇文章幹啥，你還不懂嗎

對於大的特性修改，國內開發者特別是一些寫多了內部代碼想也不想就提交的人，會犯的一個常見的錯誤是沒有修改的背景和抽象設計，直接就 pia 上去一坨代碼，英語又差，別人看不懂他也解釋不通。其實代碼的提交是一個協作的過程，需要達成共識，並不是說甩一臉代碼別人就會去看，特別是 Java 之類的很多樣板化的修改的代碼，diff 賊多信息量賊少。對於任何 non-trivial 的改動，都需要有一定的描述來表明動機；對於大的改動，更需要設計文檔來留存記憶。人的記憶不是永久的，總會忘記最初的時候自己為什麼做某一件事情，設計文檔的沉澱對於社區擺脫人的不確定性演化有至關重要的作用。只有記下來最初是為了做什麼事而做出的這個改動，以後移交代碼或者教授新人的時候才好援引和解釋。

興趣使然

上面兩個是作為開發者的我從實踐的角度具體討論的幾個小的切入點，最後一點想簡單聊聊的是動機的問題。我曾經看到知乎上有這樣的問題《如何在開源社區中提高自己的地位？》，也被人問過《在校生如何利用好開源社區？》。其實，總是想著成為 Committer，想著如何利用社區反而是緣木求魚的方法，因為這些事情你想了也不會有任何幫助。真正需要的一是溝通技巧，二是技術水平。只要這兩點到位了，如果社區健康的話，自然會歡迎你的加入。

我在成為 Committer 之前，並沒有想著我的 commit 多麼的重要，非要爭取一到兩個 commit 的實際數量，只是作為第一份工作感覺分布式系統的開發也非常的有趣，興趣使然地想看看自己能做什麼。出乎意外地成為 Committer 之後更願意將一些 trivial 的或者稍微了解就可以上手任務告訴中文社區的同學，希望能夠吸引他們參與進來，也會協助 Review 和合併。我相信，只要有一顆熱愛開發的心，在自己的崗位上做好自己的工作，我們一定能夠開發出立派的軟體，讓開發者的社會印象在國內有所提升，讓中國開發者的名片在世界上都有口皆碑。

最後跳脫得有點兒厲害，嘿嘿。歡迎大家來找我交流 Flink 或者各種有趣的分布式系統的問題呀，說不定我們討論的某一段內容，就是下一個有趣的開源軟體的雛形。