阿裡土話
身為一個老阿裡，開篇之前總想甩點和阿裡相關的内容，當然，這些内容或多或少的也和如何成為ASF送出者（Committer）有關系：
- 做正确的事，正确地做事。
- 與其抱怨老闆關注細節，不如比老闆更細節, Don't Complain. Go to fix it.
- 絕不放棄，就會發光；若有光芒，必有遠方。
如果說做正确的事是一種選擇，那麼正确的做事就是一種能力，就以阿裡巴巴在疫情期間對武漢捐贈10億醫療物資來說，進行捐贈就是在做正确的事，那麼如何将海内外的10億醫療物資快速的送達武漢就是能力，其中大量醫療物資都來自海外，那麼這些物資空運要跨越10多個國家的領空，如何處理？怎麼做到？我不知道怎麼處理的，但可以說 得道者多助，阿裡巴巴做到了！
此外，阿裡巴巴還有能讓全球振奮和刮目相看的大資料和AI技術能力，一項傳統技術30分鐘才能完成的核酸對比，阿裡巴巴技術團隊讓這個檢測在60秒内完成，這不僅僅是和時間賽跑的問題，這是對生命延續的問題！還有 支付寶的 健康碼，釘釘的 在家上課，複工平台等等。阿裡巴巴不僅僅在做正确的事，而且也一直被證明着阿裡巴巴擁有正确做事的能力！
送出者(Committer)是怎樣的角色？
我們在
《走進ASF系列》多次提及 ASF金字塔組織，今天我們重點聊聊其中的Committer的權利與職責。
在ASF官網上面對貢獻者(Contributor)和送出者(Committer)有明确的角色定義，如下：
簡單了解如下：
- 貢獻者(Contributors) - 就是開發人員，以寫代碼或寫文檔的形式為項目做貢獻。開發人員可以多種方式共享社群，比如參加者郵件清單讨論、送出代碼更新檔、送出文檔等等。
- 送出者(Committers) - 送出者是一批特殊的貢獻者，他們是擁有代碼倉庫寫操作權限的開發者。
也就是說，Committer 也是社群的Contributor，表面上看某個項目的Committer相對于該項目的普通Contributor來說，擁有了對該項目代碼倉庫的寫入權限。那麼這個寫入權限又意味着什麼呢？- 個人榮耀和反哺社群的責任！
我們暫且記住這個 “個人榮耀和反哺社群的責任！”，我們聊聊怎樣才能擁有這個“個人榮耀”和肩負“反哺社群的責任”？
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的時候，我們可以按照如下邏輯進行（當然每個步驟要有一次性将問題描述清楚的意識）：
其實“Never update your description of an issue”的本質也是我們在《
》中所說的 “前進一小步，文明一大步”的原則，你多思考一下表述邏輯，多描述一下問題始末，多搜集一下問題資料，就避免了他人的麻煩、顧慮和對問題的确定，進而可以直接進入對問題解決方案的思考，既節省了他人的時間，也加速了你問題的解決速度！所謂，己所不欲，勿施于人，予人玫瑰, 必将手有餘香！
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。這個和 “前進一小步，文明一大步”并不沖突，對吧? :-)
要驅動别人，先點燃自己
燃燒自己是一種狀态，是通過自我不斷的對外輸出，通過行為讓周圍的人感覺的，進而讓别人感受到你的能量和驅動力！社群貢獻是自怨的，沒有任何人能夠指揮或者指令其他貢獻者。人性本善，你給予我微笑，我必給你一個擁抱。如果你想讓你的PR被人及時的Review，那麼你也要先主動的力所能及的Review其他人的PR。請注意，不僅是Committer可以Review Contributor 的PR，Contributor之間同樣可以積極Review彼此的PR，也可以Review Committer和PMC所送出的PR，讓你的激情引燃他人，進而讓你所專注的項目子產品快速發展！如果你一直以燃燒自己的方式持續積極的推動社群的發展，那麼你的貢獻必将被社群關注，必将被PMC所關注，你距離Committer也就不遠了。更幸運的是社群有多種方式，很友善的檢視到你對開源的貢獻，比如你的github的profile頁面，我去年的貢獻有
600+，如下：
如圖，小方塊顔色越深代表你當時的貢獻越多，如果你以前沒有看過，你也可以現在檢視一下你自己一年來的貢獻 :-)
成為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社群的邀請内容大概如下：
那麼問題來了，成為Committer之後應該如何進行社群貢獻？如何成為優秀的Committer呢？
Review and Merge PR
在你成為Committer之後，提名你的PMC成員會給你發送一封如何Merge PR的操作步驟郵件（不是所有的項目PMC成員都會給自己發展的Committer發送這類郵件，因人而異），以我發展的Flink Committer為例，我會發一封如下郵件：
那麼我現在就Merge一個PyFlink的
PR12061為例，示範一下郵件中核心的操作内容：
-
檢視你本地的repo情況
執行指令
git remote -v
我自己的repo命名為“jincheng", asf 的 repo 為“origin”，鏡像repo就叫做“mirror”，這個名字不重要，你自己能區厘清楚就行：
- 将你要Merge的PR拉取到本地
git fetch mirror pull/12061/head:FLINK-17454-PR
-
将所有的Commits壓縮為一個（保留必要的多個也是可以的）
切換到剛才建立的分支
git checkout FLINK-17454-PR
git log -2
由于這個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
, 如下：
- Rebase 代碼到Master
git rebase master
- Push 待Merge的分支到自己的repo
git push jincheng FLINK-17454-PR:FLINK-17454-PR
- Merge PR to ASF master
gck master
git merge FLINK-17454-PR
git push origin master
可以通過檢視repo的最新送出代碼檢視double check你Merge的情況：
-
關閉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