開發與維運

走進ASF系列 – 如何成為一個合格的ASF 提交者(Committer)

2020-05-18

阿里土話

身為一個老阿里，開篇之前總想甩點和阿里相關的內容，當然，這些內容或多或少的也和如何成為ASF提交者（Committer）有關係：

  • 做正確的事，正確地做事。
  • 與其抱怨老闆關注細節，不如比老闆更細節, Don't Complain. Go to fix it.
  • 絕不放棄，就會發光；若有光芒，必有遠方。

如果說做正確的事是一種選擇，那麼正確的做事就是一種能力，就以阿里巴巴在疫情期間對武漢捐贈10億醫療物資來說，進行捐贈就是在做正確的事，那麼如何將海內外的10億醫療物資快速的送達武漢就是能力，其中大量醫療物資都來自海外，那麼這些物資空運要跨越10多個國家的領空，如何處理？怎麼做到？我不知道怎麼處理的，但可以說 得道者多助，阿里巴巴做到了！

此外，阿里巴巴還有能讓全球振奮和刮目相看的大數據和AI技術能力，一項傳統技術30分鐘才能完成的核酸對比，阿里巴巴技術團隊讓這個檢測在60秒內完成，這不僅僅是和時間賽跑的問題，這是對生命延續的問題！還有 支付寶的 健康碼，釘釘的 在家上課，復工平臺等等。阿里巴巴不僅僅在做正確的事，而且也一直被證明著阿里巴巴擁有正確做事的能力！

image.png

提交者(Committer)是怎樣的角色？

我們在《走進ASF系列》多次提及 ASF金字塔組織，今天我們重點聊聊其中的Committer的權利與職責。
image.png

在ASF官網上面對貢獻者(Contributor)和提交者(Committer)有明確的角色定義，如下：

image.png

簡單理解如下：

  • 貢獻者(Contributors) - 就是開發人員，以寫代碼或寫文檔的形式為項目做貢獻。開發人員可以多種方式共享社區，比如參加者郵件列表討論、提交代碼補丁、提交文檔等等。
  • 提交者(Committers) - 提交者是一批特殊的貢獻者，他們是擁有代碼倉庫寫操作權限的開發者。

也就是說，Committer 也是社區的Contributor，表面上看某個項目的Committer相對於該項目的普通Contributor來說，擁有了對該項目代碼倉庫的寫入權限。那麼這個寫入權限又意味著什麼呢？- 個人榮耀和反哺社區的責任！

image.png

我們暫且記住這個 “個人榮耀和反哺社區的責任！”，我們聊聊怎樣才能擁有這個“個人榮耀”和肩負“反哺社區的責任”？

Contributor 到 Committer

在《走進ASF系列 - 如何成為一個合格的ASF貢獻者(Contributor)》中我們介紹瞭如何向社區貢獻第一個PR，但一個PR距離成為一名優秀的Contributor，距離成為一名Committer還有一段修煉之路。

Never update your description of an issue

通常我們有很多種貢獻社區的途徑，但往往完整性和邏輯嚴謹性把握的好壞決定了迎來的是掌聲還是抱怨。

一次性的將問題描述清楚是一種能力。雖然看似簡單，但事實證明大部人都做不到，很多人描述一個問題需要被追問多次才能將問題表述清楚。也就是說，很多人在彙報一個Issue的時候，還沒有到討論問題解決方案的地步，就已經把想幫你解決問題的人弄崩潰了。要解決這個現象首先要從內因出發，我相信參與社區貢獻的人都是有能力將問題描述清楚的，只是缺少了 一定要 一次性 將問題描述清楚的意識！所以 “Never update your description of a issue” 目的就是要努力做到描述完一個問題之後就不需要有任何更新了，如果你真的能做到這一點，併成為一種習慣，那你想不被認可都很難～～

當然，要做到這一點，還是需要一些做事的邏輯思維的，我們以向社區彙報一個問題（創建一個JIRA）為例，當我們發現一個問題（不論是代碼問題，還是文檔問題）的時候，第一件要做的事情就是創建一個Issue。創建Issue的時候，我們可以按照如下邏輯進行（當然每個步驟要有一次性將問題描述清楚的意識）：

image.png

其實“Never update your description of an issue”的本質也是我們在《走進ASF系列 - 如何成為一個合格的ASF貢獻者(Contributor)》中所說的 “前進一小步，文明一大步”的原則，你多思考一下表述邏輯，多描述一下問題始末，多蒐集一下問題資料，就避免了他人的麻煩、顧慮和對問題的確定，進而可以直接進入對問題解決方案的思考，既節省了他人的時間，也加速了你問題的解決速度！所謂，己所不欲，勿施於人，予人玫瑰, 必將手有餘香！

Small is Powerful，Small is Beautiful

"不因善小而不為", 這是我們為人之道，也同樣適用於我們做開源建設。一個語法錯誤，一個typo，一個標點符號的改進都會受到社區的歡迎！優秀的社區貢獻者不僅僅可以為社區提供重大的功能貢獻，更需要具備為社區小的改變而努力的意識！很多關注社區貢獻的人會發現，一些貢獻者會只做test的優化，也能獲得Committer的殊榮，為什麼？有些人抱怨“不公平”，憑什麼我做了很重要的功能還沒有拿到Committer，而那些只做test優化的人卻成為了Committer。 我來告訴你可能的原因：

  • 貢獻的重要性 - 對於整體項目，固然代碼非常重要，但文檔和測試對開源建設同樣至關重要，寫文檔和做測試也是一門學問；
  • 貢獻的初衷和持續性 - 處處為社區考慮，不挑活的默默付出精神更值得尊重，PMC會細緻的觀察每個人對社區貢獻的初衷，貢獻的內容和貢獻的持續性。
  • 貢獻的多面性 - 代碼貢獻，文檔貢獻，回答社區問題，宣傳社區文化，組織社區活動，維護社區安全等等，任何對項目有利的貢獻不分輕重，不要有某種類型的貢獻一定是比另一種類型的貢獻更重要的偏見，要看到社區貢獻的多元化。

Don't Complain. Go to fix it.

上面聊到阿里土話 “與其抱怨老闆關注細節，不如比老闆更細節”，這裡我想說，不要抱怨代碼reviewer太關注細節，如果你做的足夠足夠完美，別人除了說“LGTM”之外，就是大讚你的高質量貢獻了。社區規則是一種“精英統治”，所謂“精英統治”就是 誰是對的，誰就是精英，就服從誰。所以在具體的代碼面前，0就是0，1就是1，沒有Committer和PMC的特權，誰是對的，誰是最優的就以誰的為準。所以如果在社區貢獻過程中，Reviewer對你提出的建議，哪怕是微小的改進，請不要抱怨，按正確的建議優化貢獻就好了！所以請做到：

  • 不要抱怨代碼reviewer太關注細節，請你自己更注重細節！
  • 如果有人提出任何微小但有意義的建議， Don't Complain. Go to fix it！

更多的交互才會讓PR更完美，哪怕有幾百個Comments，在某種意義上來說，更多Reviewer和更多的Comments也證明了PR的重要性和社區的精益求精，不要被Comment數量所嚇到，比如下面的PR，儘管有300個評論，但這些討論可以留痕，最終讓PR是最好的狀態，那麼同樣是優秀的PR。這個和 “前進一小步，文明一大步”並不矛盾，對吧? 🙂

image.png

要驅動別人，先點燃自己

燃燒自己是一種狀態，是通過自我不斷的對外輸出，通過行為讓周圍的人感知的，進而讓別人感受到你的能量和驅動力！社區貢獻是自怨的，沒有任何人能夠指揮或者命令其他貢獻者。人性本善，你給予我微笑，我必給你一個擁抱。如果你想讓你的PR被人及時的Review，那麼你也要先主動的力所能及的Review其他人的PR。請注意，不僅是Committer可以Review Contributor 的PR，Contributor之間同樣可以積極Review彼此的PR，也可以Review Committer和PMC所提交的PR，讓你的激情引燃他人，進而讓你所專注的項目模塊快速發展！如果你一直以燃燒自己的方式持續積極的推動社區的發展，那麼你的貢獻必將被社區關注，必將被PMC所關注，你距離Committer也就不遠了。更幸運的是社區有多種方式，很方便的查看到你對開源的貢獻，比如你的github的profile頁面，我去年的貢獻有600+，如下：
image.png
如圖，小方塊顏色越深代表你當時的貢獻越多，如果你以前沒有看過，你也可以現在查看一下你自己一年來的貢獻 🙂

成為Committer的信號

任何人的成功都不是偶然的，成為Committer也不是一夜成名的事情，都是要經過不斷的持續努力。到一定程度某些信號會釋放給你：

  • 如果你的PR沒有過多的改進建議，不斷收到： “Great Job！ LGTM. +1 to merged"。
  • 如果你Review其他人PR所給出的建議，持續收到：“Thanks for the commons, makes sense to me."
  • 如果你發起的郵件提議，多數情況最終收到：“Good idea，+1 for the proposal.”
  • 如果社區的用戶列表時時會收到你幫助解答的問題，持續收到用戶：“Thanks for your help，the suggestion solved my problem."
  • 其他...

上面這些信號不僅僅會激發你的激情，其實PMC也會關注某個貢獻者的社區貢獻狀態。這些信號都是提名你成為Committer的有力佐證！特別提醒： 上面的信號是需要有“持續性”和“一致性”特點的 。

好的貢獻心態和持續不斷的貢獻社區是成為Committer的大前提，堅持不懈，永不放棄的精神必將促使你成為一併優秀的Contributor, 進而成為一名令人羨慕的Committer ：） 所謂： “絕不放棄，就會發光；若有光芒，必有遠方。” 你也必將在某個不經意的時刻迎來那個激動人心的邀請，比如Flink社區的邀請內容大概如下：

image.png

那麼問題來了，成為Committer之後應該如何進行社區貢獻？如何成為優秀的Committer呢？

Review and Merge PR

在你成為Committer之後，提名你的PMC成員會給你發送一封如何Merge PR的操作步驟郵件（不是所有的項目PMC成員都會給自己發展的Committer發送這類郵件，因人而異），以我發展的Flink Committer為例，我會發一封如下郵件：
image.png

那麼我現在就Merge一個PyFlink的PR12061為例，演示一下郵件中核心的操作內容：

  • 查看你本地的repo情況
    執行命令git remote -v:

image.png

我自己的repo命名為“jincheng", asf 的 repo 為“origin”，鏡像repo就叫做“mirror”，這個名字不重要，你自己能區分清楚就行：

  • 將你要Merge的PR拉取到本地
    執行命令git fetch mirror pull/12061/head:FLINK-17454-PR:

image.png

  • 將所有的Commits壓縮為一個（保留必要的多個也是可以的）
    切換到剛才建立的分支git checkout FLINK-17454-PR 並查看git log -2(可以查看你想看的commit數量）要壓縮的Commits, 如下：

image.png
由於這個PR已經被貢獻者壓縮過Commits，所以我們這裡可以不執行git rebase -i HEAD~N(N是要壓縮的數量）了.

  • 規範Commit信息
    有些剛剛加入社區貢獻的貢獻者提交Commit時候，描述信息可能不是十分完美，那麼Committer可以藉此機會進行一定的調整。比如這個PR中的Commit信息如下：

[FLINK-17454][python]python gateway callback server port should not be determined by JVM process. 這個信息沒有大毛病，但就我個人而已，更希望把這個信息做一點點優化：
1) 在 [python]python之間添加空格 [python] python。
2) 將描述信息的句首用大寫 [python] Python。
3) 描述信息儘量用肯定句，不要用否定句。
因為否定句只是否定了一種錯誤的做法，沒有描述正確的做法是什麼，這樣會造成後面想了解這個Commit具體變化的人，只有通過查看源代碼才知道。所以我做一點點的改進，變成 [FLINK-17454][python] Specify a port number for gateway callback server from python gateway, 如下：
image.png

  • Rebase 代碼到Master
    執行命令git rebase master:

image.png

  • Push 待Merge的分支到自己的repo
    執行命令git push jincheng FLINK-17454-PR:FLINK-17454-PR，在我的repo會自動跑CI測試(Flink目前採用的是Azure)。當所有的測試都過了之後，就可以Merge代碼了。
  • Merge PR to ASF master
    執行命令 gck master, git merge FLINK-17454-PR,git push origin master:

image.png
可以通過查看repo的最新提交代碼查看double check你Merge的情況：
image.png

  • 關閉JIRA
    最後一步是關閉JIRA，在Flink社區要求關閉JIRA時候要將Merge的分支和對應的Commit留痕在JIRA上面，如： Merged in to Master: 5f744d3f81bcfb8f77164a5ec9caa4594851d4bf。

Committer 的職責和反哺

作為項目的Contributor，有權設定自己工作內容，以及工作內容的優先級，可以選擇在社區做一些自己喜歡的貢獻。但作為一名Committer，擁有了項目代碼的寫權限，就響應的擔負了一些對項目的責任，比如：

  • Review PRs - 作為一名Committer，一個明顯的職責就是儘可能多的Review來自Contributor的PRs，進行PR的Review即是對Contributor的幫助（反哺），更是在行使Committer的職責之一。
  • 參與社區討論 - 作為一名Committer，對社區發出的各種新功能的討論，需要在自己熟悉的模塊做出支持或者不支持的選擇，並根據項目的實際情況和發展規劃明確的解釋清楚 支持或者不支持的原因。
  • 參與項目發佈 - 作為一名Committer，項目每個版本的發佈都需要你進行發佈的檢查，確保每次發佈的質量（當然PMC成員有跟多責任確保每次發佈的質量）。
  • 監督項目的發展 - 作為一名Committer，同樣要時刻關注你所熟悉部分的Issues的進展，比如：JIRA上的討論，PR Review的進度，並且Committer之間進行交叉Review，相互查閱待Merge的PR質量。面對任何不利於項目發展的事情，做敢於說No的人。
  • 幫助用戶解決問題 - 作為一名Committer，要有較強的用戶服務意識，不僅僅要關心@dev郵件列表，更要關注@user郵件列表的用戶問題。
  • 項目活動 - 作為一名Committer，不僅僅要關注代碼層面問題，也要適當的參加各種演講，通過各種渠道擴大項目的知名度，吸引更多的貢獻者，為項目的社區的成長做出最大的努力。

己所欲施於人，成為一名Committer之後應該更多的與現在的Contributor換位思考，儘可能多的響應Contributor的問題和Review Contributor的PRs. 同時思考PMC的日常事務，儘可能多的幫助PMC完成力所能及的事情，比如主動承擔RM的職責，幫助進行項目版本的發佈，這也是在為後期成為PMC成員作準備哦:-)

堅持堅持，相信相信

在Contributor成為Committer的過程中會存在很多的困難，會發生很多你無法想象的困難。同時也會存在你認為很不公平的事情，比如你認為不如你的人成為了Committer，成為了PMC成員。這個時候請牢記：“如果你喜歡這個項目，你相信你所參與的這個項目是可以為他人造福的，那麼請暫時收起你認為不公平的想法，相信PMC的能力與公平公正性！”，由社區貢獻延伸到公司職場，在考慮到社會生涯，你認為不公平的事情太多了，但 若干時間過去後你會發現，當時你認為的不公平 其實 很公平，任何人，任何組織，不會莫名其妙的對你戴有色眼鏡，如果戴了，那也是你自己的行為影響了環境所造成的。想改變任何結果，請先改變自己對外界的看法！你變了，你眼裡的世界才會變化，你變了，那面牆的回聲才會發生改變。所謂，山不過來，那麼你就走向山！總之，要 堅持你所堅持的，相信你所相信的，在漫長的社區貢獻中，請始終牢記：

  • 做正確的事，正確地做事。
  • 與其抱怨他人關注細節，不如你更關注細節，如果做不到，Please Don't Complain. Go to fix it.
  • 絕不放棄，就會發光；若有光芒，必有遠方。

小結

本篇為大家介紹了參與開源的利好，原則，以及介紹為自己的第一個社區貢獻需要做怎樣的準備。最後誠摯邀請想參與開源建設的朋友首站加入Apache Flink 的PyFlink建設！

參考

[1] http://www.apache.org/foundation/how-it-works.html#committers

查閱更多內容

Leave a Reply

Your email address will not be published. Required fields are marked *