如何高效參與開源項(xiàng)目?
本文重新發(fā)布了如何高效利用有限的時(shí)間參與開源社區(qū)的兩篇文章，修復(fù)了大量影響閱讀的措辭。
大部分人參與開源社區(qū)會面臨的一個(gè)巨大挑戰(zhàn)，那就是缺乏時(shí)間。本文試圖提供一種方式，幫助想要參與開源社區(qū)的同學(xué)高效利用有限的時(shí)間。
在一個(gè)開源社區(qū)里，maintainers 需要關(guān)注的范圍比 contributors 要大得多。本文分別討論這兩類人群適用的參與開源社區(qū)的技巧，以減少過程中的摩擦，提高時(shí)間的利用率。
Contributors
Join the community and lurk first
參與開源社區(qū)的第一步就是加入社區(qū)。加入社區(qū)的方式有很多，可以訂閱郵件列表，關(guān)注開發(fā)活動(dòng)，參與技術(shù)或非技術(shù)討論，等等。很多希望參與開源社區(qū)的人遲遲邁不出第一步就是忽略了自己首先要加入社區(qū)，跟社區(qū)建立起聯(lián)系。
一個(gè)典型的錯(cuò)誤做法是完全不顧開源社區(qū)是開發(fā)開源項(xiàng)目的主體，一頭鉆進(jìn)技術(shù)細(xì)節(jié)里，暗搓搓地做一個(gè)“大功能”，然后希望社區(qū)盡快合并這個(gè)補(bǔ)丁，讓自己得到榮譽(yù)。
Linux Foundation 有一篇博文?Participating in Open Source Communities[1]?明確反對了這種做法。
Some organizations make the mistake of developing big chunks of code in house and then dumping them into the open source project, which is almost never seen as a positive way to engage with the community. The reality is that open source projects can be complex, and what seems like an obvious change might have far reaching side effects in other parts of the project. Any significant change is likely to require some community discussion before it moves to implementation to make sure that there are no side effects and that the solution is aligned with the broader goals for the project. While you discuss it with the community, it can help to focus on the problem, rather than a specific solution, before you invest too much time in the creation of a body of code.
一個(gè)現(xiàn)實(shí)的例子，前幾天有人問我，自己做了一個(gè) Flink StateBackend 的實(shí)現(xiàn)，提交給社區(qū)是不是就能當(dāng) PMC 了。這個(gè)問題屬實(shí)把我整不會了。從來沒有在社區(qū)當(dāng)中亮相的人，突然出現(xiàn)并提出自己實(shí)現(xiàn)了一個(gè)“大功能”，在其他成員眼里跟民科沒什么不同。絕大部分情況下，這種實(shí)現(xiàn)跟上游社區(qū)的開發(fā)節(jié)奏是脫節(jié)的，很難合回去。也就是說，閉門造車的形式自我感動(dòng)地開發(fā)項(xiàng)目，即使花費(fèi)了時(shí)間，大概率還是白忙一場。
剛開始接觸 Flink 社區(qū)的時(shí)候，我就按照項(xiàng)目文檔的提示訂閱了 users 和 dev 兩個(gè)郵件列表。實(shí)話說，最初的三個(gè)月，我基本看不懂他們在說什么。當(dāng)時(shí)的我盡可能地讀每一封郵件，從郵件里面引用的鏈接一個(gè)個(gè)點(diǎn)進(jìn)去了解背景，混沌當(dāng)中建立起對項(xiàng)目的初步印象。直到四個(gè)月后第一次提交代碼，這個(gè)祛魅的過程才算完成。從此以后，我逐漸能夠輕松地參與到技術(shù)討論，也掌握了 review 的溝通習(xí)慣。
最近，我在跟人介紹 Engula 項(xiàng)目的時(shí)候，也是先發(fā)討論區(qū)[2]和聊天室[3]的鏈接。新成員可以閱讀過往的討論，掛在聊天室里，觀察社區(qū)討論問題和推進(jìn)工作的方式，了解已有的設(shè)計(jì)實(shí)現(xiàn)和結(jié)論。參與閑聊或者回復(fù)感興趣的話題，找到自己愿意投入的工作。只有這樣，才能進(jìn)一步深入?yún)⑴c開源社區(qū)，而不是接觸了好幾年，卻始終邁不出第一步。
Figure out what you care about
要想利用有限的時(shí)間創(chuàng)造更多價(jià)值，最好的方法是找到一個(gè)感興趣的問題，然后持續(xù)投入進(jìn)去直到解決。
一個(gè)典型的錯(cuò)誤做法是強(qiáng)迫自己做著不感興趣的工作。這種情況下，由于內(nèi)心是抗拒的，即使投入再多的時(shí)間，也幾乎不會有產(chǎn)出。
可能有人會不理解，開源社區(qū)的 contributor 都是自愿參與，如果不想做某個(gè)工作，不是不做就可以了嗎。其實(shí)不然，社區(qū)成員身處其中很容易感受到無形的社交壓力。
一種情況是不懂得拒絕。知乎上有個(gè)問題，如何優(yōu)雅地拒絕開源項(xiàng)目的 PR 邀請[4]，講的就是這種情況。我在回答里分享了一個(gè)自己拒絕 Flink 社區(qū)成員里的 PR 邀請的案例。另一種情況是錯(cuò)誤估計(jì)難度，即自以為能搞定這個(gè)工作，做的過程里發(fā)現(xiàn)不對，又不好意思改口說自己搞不定。應(yīng)對這些情況的方法非常簡單，直截了當(dāng)?shù)卣f明情況即可，解放自己避免浪費(fèi)時(shí)間。
另外一個(gè)難題是自己往往對比較有挑戰(zhàn)性的工作感興趣，但是從一個(gè)剛接觸項(xiàng)目的 contributor 到能夠完成一個(gè)復(fù)雜任務(wù)之間有一道坎。
要跨過這道坎，同樣需要積極采取行動(dòng)，而不要獨(dú)自糾結(jié)。首先可以考慮從簡單的工作入手，比如閱讀項(xiàng)目文檔時(shí)發(fā)現(xiàn)的拼寫錯(cuò)誤。一個(gè)簡單的貢獻(xiàn)能帶你走完整個(gè) contribution 流程。一回生二回熟，做其他有挑戰(zhàn)性的工作也就不會在流程上踩坑。其次可以保持和 maintainers 的交流，以了解現(xiàn)有邏輯的設(shè)計(jì)背景和演進(jìn)過程。只有對工作涉及的邏輯有充分的了解，才能寫出高質(zhì)量的代碼。高質(zhì)量的代碼也意味著更少的返工和不必要的爭論，也就避免了時(shí)間的浪費(fèi)。
Build relationships
隨著參與的深入，總有你一個(gè)人無法完成的工作。開源協(xié)同的價(jià)值就在于跨越所屬組織的邊界合作開發(fā)項(xiàng)目。合作的基礎(chǔ)是成員之間的信任，也就是良好的關(guān)系。
開源社區(qū)是圍繞開源軟件建立起來的。但是并不只有軟件本身帶來技術(shù)價(jià)值，人與人的連結(jié)帶來認(rèn)同感和歸屬感，這些也能滿足社區(qū)成員的需要。此外，相互信任的基礎(chǔ)能很大程度提升價(jià)值創(chuàng)造的效率，例如減少浪費(fèi)在同步和對齊上的時(shí)間。因此，建立并保持與其他項(xiàng)目成員的關(guān)系至關(guān)重要。
做到這一點(diǎn)的方式就是充分的溝通。同樣，這需要以開放的心態(tài)對待平時(shí)的交流。不要把所有事情都憋在心里。不要糾結(jié)于想清楚所有細(xì)節(jié)再開始溝通，其他成員一時(shí)間內(nèi)往往沒辦法追上你所想的所有細(xì)節(jié)。我的建議是，當(dāng)你有一個(gè)初步的想法，也做了力所能及的調(diào)研，就可以整理一下，發(fā)布到社區(qū)當(dāng)中征求意見。
我給 Engula 項(xiàng)目做了一個(gè)社區(qū)計(jì)劃[5]。老實(shí)說，內(nèi)容并不成熟，但是我一個(gè)人干想也得不出結(jié)論，所以在經(jīng)過幾輪自我 Review 以后，就先拋出來征求意見。另一個(gè)例子是 Engula 的 maintainer @huachaohuang 想為 contributor 提供開發(fā)文檔，于是就發(fā)起了一個(gè)關(guān)于 Dev Guide 的討論[6]。正好我對這個(gè)話題也早有想法，當(dāng)我看到發(fā)出來的討論以后，發(fā)現(xiàn)他也在關(guān)注這個(gè)話題。于是我花了一個(gè)小時(shí)把自己的想法寫下來，經(jīng)過討論以后提 PR 推進(jìn)主分支。
溝通協(xié)作的過程里沖突在所難免。我在好幾個(gè)項(xiàng)目里都別人討論甚至爭論過很多次技術(shù)問題，給別人的行為提過意見，也夸贊過好的做法。開源社區(qū)解決沖突的方式比較樸素，一般是有話直說，盡量客觀地達(dá)成共識，按照流程約定做出決策。不用整那么多彎彎繞浪費(fèi)時(shí)間。
舉一個(gè)現(xiàn)實(shí)的例子，曾經(jīng)有人跟我抱怨提上去的 PR 被 maintainer 挑戰(zhàn)了，問我應(yīng)該怎么回復(fù)。懷疑 maintainer 是不是有偏見，抱怨很難跟 maintainer 溝通，大量的時(shí)間精力浪費(fèi)在糾結(jié)這些臆想出來的問題，自然是筋疲力竭，感覺在開源社區(qū)里寸步難行。
Talk to your boss, and choose your job
最后，關(guān)注到相當(dāng)一部分 contributors 的公司員工的身份。這顯然會影響到他們參與社區(qū)的動(dòng)力和能力。
主要的挑戰(zhàn)是，如果工作期間不允許參與開源社區(qū)，同時(shí)工作本身已經(jīng)消耗了太多的時(shí)間精力，那么 contributors 對參與開源社區(qū)也只能是有心無力。這其實(shí)是很長一段時(shí)間里開源社區(qū)的參與在國內(nèi)發(fā)展緩慢的原因。大量的開發(fā)者都在過度工作，下班只想躺平休息，沒有動(dòng)力再談什么開源貢獻(xiàn)。
不過，隨著時(shí)間的發(fā)展，情況也在發(fā)生著變化。越來越多的公司采用更加靈活合理的工作時(shí)間，尤其是以研發(fā)為核心競爭力的公司。如果你所在的公司仍然要求超負(fù)荷工作，燃燒生命賺血汗錢，那么是時(shí)候找份新工作了。時(shí)代已經(jīng)變了，就讓這些公司被無情的淘汰吧。
另一個(gè)方向是考慮在工作期間參與開源社區(qū)。如果你確實(shí)喜歡某個(gè)開源項(xiàng)目，那么最佳策略就是找一份允許你全職投入這個(gè)項(xiàng)目的工作。這樣的工作崗位如今并不少見。尤其是隨著企業(yè)級解決方案越來越傾向于采用開源組件，企業(yè)對熟悉開源軟件的人才的需求只會日益增加。如果找不到全職投入開源項(xiàng)目的工作，與之相關(guān)的工作也是備選方案。
不過，即使這份工作允許你全職投入開源項(xiàng)目，也并不意味著你能夠參與開源社區(qū)。特別是當(dāng)你的老板認(rèn)為參與開源社區(qū)不能為公司創(chuàng)造價(jià)值的時(shí)候。面對這個(gè)問題，首先你可以問問你的老板，說不定他不這么覺得，那就省事兒了。如果你的老板確實(shí)難以理解，那你就得像兜售一個(gè)技術(shù)方案一樣向他宣傳參與開源社區(qū)的價(jià)值了。我在其他的文章里對這一點(diǎn)已經(jīng)有不少討論，你可以看看。
普適的時(shí)間管理手段這里就不展開介紹了，各種相關(guān)書籍和 GTD 方法論都很值得一看。
Maintainers
Nominate new maintainers selectively
Maintainers 比起 contributors 需要關(guān)注的更多的事情。隨著開源項(xiàng)目日漸復(fù)雜，開源社區(qū)逐漸成長，單靠一個(gè)人的力量很難處理好所有的事務(wù)。這個(gè)時(shí)候，就需要 maintainer 適時(shí)地發(fā)展項(xiàng)目維護(hù)的隊(duì)伍。
首先需要理清 maintainer 頭銜的定位。實(shí)際上，大部分項(xiàng)目的維護(hù)是個(gè)苦力活，而 maintainers 就是一群承擔(dān)這些工作的社區(qū)成員。Maintainers 可能會擁有合并 PR 的權(quán)限，在社區(qū)治理中能投票做決策，確定項(xiàng)目發(fā)展的方向。但是，這種權(quán)限并非特權(quán)。在一個(gè)健康的社區(qū)里，任何社區(qū)成員都可以做技術(shù)討論，也可以就社區(qū)發(fā)展話題提出自己的觀點(diǎn)。對于技術(shù)觀點(diǎn)，客觀上更加合理的方案理應(yīng)被采納。對于社區(qū)發(fā)展話題，maintainers 也一定會考慮建設(shè)性的提議。
可能有不少人把成為 maintainer 當(dāng)成參與開源社區(qū)的目標(biāo)，這是很好的。如果你理解了 maintainer 的職責(zé)，通過 contribution 積累了足夠的信譽(yù)，成為 maintainer 為開源社區(qū)服務(wù)，這個(gè)頭銜是一個(gè)顯式的認(rèn)可。不過，大可不必過分糾結(jié)于 maintainer 頭銜。這只是對 contribution 認(rèn)可形式的其中一種，而不是唯一一種。
Maintainers 的職責(zé)并不輕松，所以 Python 社區(qū)和 Apache 軟件基金會下的項(xiàng)目社區(qū)都會有一個(gè)詢問 contributor 是否愿意成為 maintainer 的流程。也存在 contributor 拒絕邀請的情況，因?yàn)榫拖袂懊嫣岬降模】档拈_源社區(qū)里，只要提議是合理的，就能憑借其客觀的優(yōu)勢勝出。成為 maintainer 并不意味著在方案選擇上有特權(quán)。
對于 contributor 的感謝，也可以通過宣傳渠道發(fā)布。比起一個(gè)模糊的 maintainer 頭銜，作為技術(shù)人員，我會更在意這個(gè)人實(shí)際在開源社區(qū)里實(shí)際完成的事情。
基于上面的認(rèn)識，我們引出下一個(gè)觀點(diǎn)。Maintainers 發(fā)展新成員，必須是有選擇性的。
這種選擇性的主要依據(jù)是維護(hù)項(xiàng)目的需要，而不是追求數(shù)量或者過分在意 diversity 等等。這可以類比到開發(fā)軟件的目的是提供技術(shù)價(jià)值，而不是代碼行數(shù)或者所采用的編程語言的數(shù)量。
一個(gè)典型的錯(cuò)誤案例是出于自己同時(shí)是公司員工的身份，被命令將 maintainers 的人數(shù)發(fā)展到某個(gè)數(shù)字。這種指標(biāo)只關(guān)注數(shù)字而不關(guān)注具體的人，而且往往定得脫離實(shí)際。公司員工迫于指標(biāo)壓力很容易降低 maintainers 的標(biāo)準(zhǔn)，逮到一個(gè)算一個(gè)的湊人頭，或者為了 diversity 對不同背景的 contributor 采取不同的標(biāo)準(zhǔn)。這樣發(fā)展出來的 maintainers 不僅不能分擔(dān)項(xiàng)目維護(hù)的職責(zé)，還很有可能因?yàn)椴粍偃味a(chǎn)生新的問題。
另一個(gè)典型的錯(cuò)誤經(jīng)常出現(xiàn)在個(gè)人項(xiàng)目上，當(dāng)個(gè)人項(xiàng)目發(fā)展壯大，唯一的 maintainer 想要發(fā)展新成員時(shí)，很容易陷入到要找一個(gè)自己的分身的誤區(qū)。也就是說，新的 maintainer 必須和自己一樣能夠關(guān)注到項(xiàng)目的方方面面。這是不對的。沒有兩個(gè)人完全相同。只要一個(gè) contributor 有足夠的信譽(yù)，并且能在項(xiàng)目或社區(qū)的維護(hù)的某個(gè)方面上承擔(dān)職責(zé)，他就是一個(gè)好的 maintainer 人選。
不過，這里講到的信譽(yù)是一個(gè)非常主觀的概念，提名 maintainer 的傾向每個(gè)項(xiàng)目也各有不同。
?Perl 社區(qū)最初由 Larry Wall 獨(dú)裁。近年來，隨著他逐漸淡出核心成員圈子，Perl 社區(qū)的治理實(shí)際上已經(jīng)變成由 28 人組成的 core team 負(fù)責(zé)。?PostgreSQL 社區(qū)由 7 人組成的 core team 和 28 位 committers 處理所有工作。?ASF 治下的項(xiàng)目有一套比較固定的治理模型[7]。具體到每個(gè)項(xiàng)目，例如?Apache Pulsar[8]?和?Apache Flink[9]?會有自己具體的要求和傾向。?Spring Project 社區(qū)的 committers 都是 Pivotal 公司或 VMWare 公司的員工。但是它顯然也是誕生于開源協(xié)同的作品。?Linux Kernel 基本上還是由 Linus 獨(dú)裁。同時(shí)，海量的驅(qū)動(dòng)和架構(gòu)支持有各自的 maintainer 進(jìn)行維護(hù)。參考?Linux Kernel Maintainers 頁面[10]。?Netty 社區(qū)沒有明確的規(guī)則。Trustin Lee 發(fā)起項(xiàng)目并獨(dú)自維護(hù)了三年。隨后，Norman Maurer 和 Scott Mitchell 等少數(shù)幾個(gè)人持續(xù)參與，成為 maintainer 并共同維護(hù) Netty 項(xiàng)目至今。
如果讓我對 maintainer 提一個(gè)基礎(chǔ)要求，我會希望他在項(xiàng)目或社區(qū)中做出了卓越的貢獻(xiàn)，并且當(dāng)前的 maintainers 團(tuán)隊(duì)樂于和他一起工作。
Structure processes
除了增加項(xiàng)目維護(hù)的人員，另一個(gè)基本的減少時(shí)間浪費(fèi)的手段就是結(jié)構(gòu)化流程。我們分點(diǎn)介紹其內(nèi)涵。
第一點(diǎn)是直覺大于文檔。對于托管在 GitHub 上的項(xiàng)目來說，help wanted 和 good first issue 標(biāo)簽是一個(gè)眾所周知的約定。合理標(biāo)記 issue 能讓 contributor 按照過往的經(jīng)驗(yàn)快速找到切入點(diǎn)。我在修訂 TiDB 社區(qū)的治理方案[11]的時(shí)候，也是以跟 GitHub 開箱即用的功能親和為主要目標(biāo)之一。如果參與一個(gè)開源項(xiàng)目有太多新東西要學(xué)，那么 maintainers 就有的是要解釋的東西了。大部分人效率最高的路徑是完全憑直覺做事，并取得好的結(jié)果。所以如無必要，請勿設(shè)立復(fù)雜的規(guī)則。
第二點(diǎn)是文檔大于口述。直覺畢竟只能解決部分問題，對于特殊的或者需要強(qiáng)調(diào)的內(nèi)容，明確記錄下來作為文檔絕對是個(gè)好主意。
不過文檔首要的還不是記錄流程，而是項(xiàng)目的目標(biāo)或者叫定位。這是每個(gè)對項(xiàng)目感興趣的人都會問的問題，高水平的 contributor 尤甚。他們不僅僅是想在開源社區(qū)里做簡單的工作，更想成為一個(gè)偉大的或富有價(jià)值的項(xiàng)目的締造者。如果你想為你的項(xiàng)目吸引到高水平的開發(fā)者，那么最好是確定一個(gè)清晰且令人振奮的目標(biāo)，并將它展示在最顯眼的地方。例如，Apache Flink 的定位是數(shù)據(jù)流上的有狀態(tài)計(jì)算，其中有狀態(tài)這點(diǎn)是開源世界里開創(chuàng)性的工作。例如，PostgreSQL 的定位是世界最先進(jìn)的開源關(guān)系型數(shù)據(jù)庫。例如，Elixir 語言的目標(biāo)是構(gòu)建可擴(kuò)展和可維護(hù)的應(yīng)用。
其次是約定俗成的文檔，包括 README 和 CONTRIBUTING 等等。其中一般包含項(xiàng)目的簡介，開始使用的方法，參與貢獻(xiàn)的基本流程，和指向更多文檔的鏈接。大部分 contributor 會嘗試尋找和閱讀這些文檔。如果他們能從其中解決自己的問題，就不需要 maintainer 花時(shí)間說明了。至少，在有人提問的時(shí)候，直接發(fā)一個(gè)文檔的鏈接，也能省不少事兒。
另一個(gè)值得強(qiáng)調(diào)的是 Code of Conduct 即行為準(zhǔn)則。提名新的 maintainer 之前最好確保被提名人知悉和理解社區(qū)行為準(zhǔn)則。行為準(zhǔn)則通常是一些涉及平等、尊重和避免冒犯的原則。雖然大多數(shù)開源社區(qū)很少遇到嚴(yán)重違反行為準(zhǔn)則的情況，但是 maintainers 應(yīng)該對此保持敏感。這類問題一旦處理不當(dāng)，很容易演變成政治斗爭，甚至導(dǎo)致社區(qū)分裂或項(xiàng)目停擺。
最后是設(shè)計(jì)文檔。Contributors 要深度參與技術(shù)貢獻(xiàn)需要了解相關(guān)代碼的設(shè)計(jì)背景和演進(jìn)過程，設(shè)計(jì)文檔就是最好的參考材料。良好的代碼質(zhì)量有助于避免 contributor 閱讀源碼時(shí)受挫，但是項(xiàng)目固有的復(fù)雜度還是需要設(shè)計(jì)文檔來輔助解釋。如果代碼質(zhì)量和設(shè)計(jì)文檔都缺位，想要深度參與技術(shù)貢獻(xiàn)的 contributor 就不得不指望 maintainer 花費(fèi)大量的時(shí)間解釋和指導(dǎo)了。這點(diǎn)對于 maintainer 自己也是一樣的。當(dāng)你想要做一個(gè)新的功能，如果沒有好的技術(shù)文檔，你也得懵圈，也得拉人反復(fù)對齊。
第三點(diǎn)是避免私下討論。有關(guān)項(xiàng)目和社區(qū)的討論，唯一的信源應(yīng)該是一個(gè)公開的渠道。例如，ASF 治下的項(xiàng)目要求所有有效的討論都應(yīng)該發(fā)生在郵件列表上。例如，大部分托管在 GitHub 上的項(xiàng)目隱含了討論應(yīng)該發(fā)生在 GitHub 平臺上。社區(qū)成員可能還會通過其他的溝通渠道輔助交流，例如即時(shí)通信軟件。但是這些輔助渠道的討論需要被抄送到唯一信源上才實(shí)際生效。這樣，contributor 才能在無需了解諸多渠道的前提下有能力獲取所有有價(jià)值的信息。
這些公開討論的內(nèi)容以及表現(xiàn)出來的做事方式，就是社區(qū)當(dāng)中的“活文檔”。模仿是人類的天性，如果你希望別人遵循某種做事方式以減少沖突，那么最好以身作則，再帶動(dòng)更多的人跟隨。前面討論 contributor 的參與技巧時(shí)候說過，加入社區(qū)并首先觀察別人是怎么做的，是一種避免浪費(fèi)時(shí)間的好方法。那么與之相對的，maintainer 也要在項(xiàng)目維護(hù)和日常交流方面為此提供方便。
Open Communications: as a virtual organization, the ASF requires all communications related to code and decision-making to be publicly accessible to ensure asynchronous collaboration, as necessitated by a globally-distributed community.?The Apache Way[12]
第四點(diǎn)是考慮自動(dòng)化。結(jié)構(gòu)化的流程更容易自動(dòng)化。當(dāng)你的流程越來越結(jié)構(gòu)化，那么是時(shí)候考慮自動(dòng)化它了。顯然，無需 maintainer 親自動(dòng)手的自動(dòng)化流程能夠減輕項(xiàng)目維護(hù)的壓力。
同樣，最好的自動(dòng)化是符合直覺的。GitHub 平臺提供了一系列自動(dòng)化的支持。尤其是?GitHub Actions[13]?發(fā)布以后，自動(dòng)化的靈活性得到了進(jìn)一步的提升。利用項(xiàng)目代碼托管的平臺提供的開箱即用的能力做自動(dòng)化，能夠最大程度的避免各種沖突。
自動(dòng)化還應(yīng)該建立在現(xiàn)有的成熟流程上，而不應(yīng)該憑空生造一個(gè)流程。好的案例包括提交文檔變更后自動(dòng)部署文檔頁面，利用 merge bot 提高 pull requests review 和 merge 的效率等等。
其中，后者的采用是有兩面性的。許多代碼提交極其活躍的開源社區(qū)也仍然不需要引入自動(dòng)化流程。當(dāng)然，測試基本是自動(dòng)化的，至少有腳本。不過 review 和 merge 還是可以人工完成的。我比較認(rèn)同 merge bot 的地方是有些實(shí)現(xiàn)了排隊(duì)合并功能以及 roll up 打包測試功能。這兩個(gè)功能在保證合入主分支的代碼是基于最新的主分支測試過的前提下，減少了需要進(jìn)行測試的次數(shù)和人為協(xié)調(diào)的負(fù)擔(dān)。但是，有些 merge bot 強(qiáng)制要求 review 和 merge 走非常嚴(yán)格的審批流程，把這個(gè)過程變得復(fù)雜不堪，這是我非常反對的。所以在引入 merge bot 之前，請確保你清楚地知道它如何改善協(xié)作效率，并保留回滾的能力。
另一個(gè)典型的錯(cuò)誤案例是 stale bot 的自動(dòng)關(guān)閉功能。真的，沒人喜歡這個(gè)功能。開發(fā)者來到社區(qū)是為了和人建立聯(lián)系，共同開發(fā)好的軟件，而不是為了被機(jī)器人支配。應(yīng)對 issue 或 PR 的積壓問題，首先應(yīng)該盡可能的及時(shí)處理。其次，大部分積壓的 issue 是無效的內(nèi)容，例如愿望清單和模糊的想法，這些只需要快速關(guān)閉即可。對于低優(yōu)先級的 bug issue 的積壓，既然問題是實(shí)際存在的，也不是 wontfix 的情形，憑什么關(guān)掉呢？如果當(dāng)前的 maintainers 積極主動(dòng)地處理 issue 和 PR 還是處理不過來，那么是時(shí)候?qū)ふ乙粋€(gè)新的 maintainer 了。
Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.?The ZeroMQ Community[14]
流程自動(dòng)化的標(biāo)桿案例包括?Kubernetes 社區(qū)[15]和?Rust 社區(qū)[16]。在學(xué)習(xí)這兩個(gè)社區(qū)的做法的時(shí)候，需要強(qiáng)調(diào)的是
1.請關(guān)注這兩個(gè)社區(qū)為流程自動(dòng)化投入了多少人力。2.請關(guān)注這兩個(gè)社區(qū)是在什么時(shí)候引入了何種自動(dòng)化邏輯。3.請關(guān)注這兩個(gè)社區(qū)的成員如何利用自動(dòng)化流程。4.請關(guān)注這兩個(gè)社區(qū)在流程自動(dòng)化上的異同。5.請關(guān)注這兩個(gè)社區(qū)推行流程自動(dòng)化時(shí)的討論，尤其是爭議。6.請勿貨物崇拜，直接照抄它們的方案。否則你會死得很慘。
既然 Rust 社區(qū)都不抄 Kubernetes 社區(qū)的方案，你為啥貿(mào)貿(mào)然就要抄？
Manage day-to-day events
前面講的是一些整體的做法，回到每個(gè) maintainer 身上，實(shí)際的項(xiàng)目維護(hù)工作其實(shí)是日常事務(wù)。
最常見的問題是開發(fā)的風(fēng)險(xiǎn)控制。開源項(xiàng)目通常會有自己的版本發(fā)布周期。有時(shí)候你希望下個(gè)版本能交付某幾個(gè)關(guān)鍵功能或改進(jìn)，而這些工作并不都是由你一個(gè)人完成。尤其是，你之所以想交付這些變更，是因?yàn)楣镜囊螅_發(fā)團(tuán)隊(duì)包括并非公司員工的成員。這個(gè)時(shí)候就需要你做好項(xiàng)目的風(fēng)險(xiǎn)控制。
從公司員工的角度，我介紹過開源項(xiàng)目和商業(yè)公司獨(dú)立運(yùn)營的協(xié)同模型。運(yùn)用這個(gè)模型，可以把商業(yè)上緊急的需求實(shí)現(xiàn)在 fork 倉庫上，交付 hotfix 應(yīng)對緊急情況。稍后，把改動(dòng) contribute back 到開源項(xiàng)目當(dāng)中。這樣就可以把商業(yè)要求和軟件開發(fā)的工程要求隔離開來，避免向開源社區(qū)傾倒粗糙的補(bǔ)丁。Stream Native[17]?就在公司組織下有 Apache Pulsar 的 fork 倉庫。我沒有仔細(xì)研究過他們的具體做法，但是顯然他們把一些公司關(guān)心的內(nèi)容都放在 fork 倉庫上記錄。讓上帝的歸上帝，凱撒的歸凱撒。這是好文明。
如果評估出來更合適的做法是把改動(dòng)直接做在上游，那么我會建議在需要嚴(yán)格控制風(fēng)險(xiǎn)的情況下，直接由公司員工組成開發(fā)團(tuán)隊(duì)。當(dāng)然，這些員工得靠自己的努力在開源社區(qū)當(dāng)中贏得信譽(yù)，而不是只根據(jù)職位就被允許直接提交代碼。如果同樣的需求已經(jīng)有其他團(tuán)隊(duì)在做，那么溝通就是必要的。如果信得過這個(gè)團(tuán)隊(duì)，保持關(guān)注并提供幫助即可。否則，可以嘗試接管項(xiàng)目開發(fā)。Flink 社區(qū)的?FLIP-85[18]?提案是我和 Uber 的工程師分別獨(dú)立提出的。經(jīng)過幾輪郵件列表上的討論，最終由阿里的工程師主導(dǎo)實(shí)現(xiàn)。我參與了 review 和提供了部分參考實(shí)現(xiàn)。
上面講的是一個(gè)好的案例。其實(shí)對于一個(gè)活躍的開源社區(qū)來說，PR 沖突的情況不會太少，種類也很多。
TiDB 社區(qū)發(fā)生過一起有名的?Xuanwo 事件[19]。完全相同的兩個(gè)補(bǔ)丁，后提交的反而先被合入，導(dǎo)致先提交的被迫關(guān)閉。尤其是這個(gè)事件發(fā)生在并不繁忙的倉庫上，并且兩個(gè)補(bǔ)丁提交的時(shí)間相差一個(gè)月。這是一種非常典型的情況，需要 maintainers 保持對項(xiàng)目范圍內(nèi)發(fā)生的活動(dòng)的關(guān)注。
Flink 社區(qū)有不少經(jīng)典的樂子。FLINK-10052[20]?作為我從 2019 年就和 @lamberken 配合修復(fù)完成并經(jīng)過生產(chǎn)環(huán)境驗(yàn)證的高嚴(yán)重性問題，在過去的三年里提交的三個(gè)補(bǔ)丁都因?yàn)槿狈憫?yīng)最終沒有合并。這也導(dǎo)致不少用戶被迫手動(dòng)打補(bǔ)丁。FLINK-11937[21]?是另一個(gè)例子。兩家員工提供了不同的方案，其中一方缺少社區(qū)話語權(quán)，無力單獨(dú)推進(jìn)合并，另一方有能力但是無意推進(jìn)，也不允許其他人推進(jìn)。同樣的案例還有?FLIP-44[22]?和?Queryable State[23]?等等。
Flink 的例子其實(shí)證明了商業(yè)公司需要通過 fork 倉庫的來應(yīng)對商業(yè)需求。另外也可以看到這些討論的發(fā)起人是如何被 stale bot 二次傷害的。
從開源協(xié)同的角度，contributor 不是程序，而是真實(shí)的人。上面提到的溝通手段，去掉公司員工的背景也同樣適用。商業(yè)公司要做風(fēng)險(xiǎn)控制，開源社區(qū)也是一個(gè)組織，也可以做風(fēng)險(xiǎn)控制。只不過，開源社區(qū)是一個(gè)開放式組織。在這個(gè)環(huán)境下控制風(fēng)險(xiǎn)的手段不是管控，而是協(xié)同。前面講到的文檔和結(jié)構(gòu)化的流程在這里同樣可以起作用。信息在 contributor 之間自由流通，就不會有 FUD 產(chǎn)生的傷害。平時(shí)保持和其他 contributor 的聯(lián)系，就能知道當(dāng)前的工作最應(yīng)該找誰一起做。
大部分情況下，contributor 是能夠自我驅(qū)動(dòng)和自我激勵(lì)的。他們爆發(fā)出的創(chuàng)造力不可小覷。單就時(shí)間上的風(fēng)險(xiǎn)而言，如果你在開發(fā)文檔里明確寫下開發(fā)周期和發(fā)布模型，contributor 是樂于見到自己參與或主導(dǎo)開發(fā)的工作隨新版本一起發(fā)布的。越是自我驅(qū)動(dòng)參與開源社區(qū)的 contributor 越重視積累信譽(yù)。這個(gè)過程中，如果你作為 shepherd 指導(dǎo)或參與進(jìn)去，只需要切實(shí)地關(guān)注和解決開發(fā)團(tuán)隊(duì)成員遇到的困難，并在需要時(shí)幫助他們管理好進(jìn)度。
其他的溝通技巧和 maintainer 的最佳實(shí)踐這里不再展開。Open Source Guides 提供了這個(gè)話題非常有益的補(bǔ)充，推薦延伸閱讀。
?Best Practices for Maintainers[24]?Leadership and Governance[25]?Building Welcoming Communities[26]
Have fun and take care of yourself
不論是 contributor 還是 maintainer 你都已經(jīng)通過參與開源社區(qū)為社會創(chuàng)造出了價(jià)值。時(shí)不時(shí)想想你為什么要參與或維護(hù)這個(gè)項(xiàng)目，回顧這個(gè)項(xiàng)目已經(jīng)取得的成就。你已經(jīng)做得很好了。
軟件都有自己的生命周期，開源軟件也不例外。開源社區(qū)的工作也不是你生活的全部。如果你找到了新的樂趣，完全可以把項(xiàng)目交給其他 maintainers 維護(hù)，或者直接歸檔。如果開源項(xiàng)目的維護(hù)已經(jīng)超出你的能力范圍或者消耗了太多的時(shí)間精力，也可以休息一段時(shí)間甚至放棄對項(xiàng)目的維護(hù)。作為開源社區(qū)成員的你沒有義務(wù)非得維護(hù)這個(gè)項(xiàng)目或者響應(yīng)別人的請求。你把自己的工作自由的提供給其他人利用，已經(jīng)創(chuàng)造了非常客觀的價(jià)值。
References
[1]?Participating in Open Source Communities:?https://www.linuxfoundation.org/tools/participating-in-open-source-communities/[2]?討論區(qū):?https://github.com/engula/engula/discussions[3]?聊天室:?https://discord.gg/AN6vgVXaHC[4]?如何優(yōu)雅地拒絕開源項(xiàng)目的 PR 邀請:?https://www.zhihu.com/question/475269038/answer/2045981148[5]?社區(qū)計(jì)劃:?https://github.com/engula/engula.github.io/pull/15[6]?關(guān)于 Dev Guide 的討論:?https://github.com/engula/engula/discussions/84[7]?治理模型:?http://www.apache.org/foundation/how-it-works.html#roles[8]?Apache Pulsar:?https://pulsar.apache.org/en/contributing/#becoming-a-committer[9]?Apache Flink:?https://flink.apache.org/contributing/how-to-contribute.html[10]?Linux Kernel Maintainers 頁面:?https://www.kernel.org/doc/html/latest/process/maintainers.html[11]?修訂 TiDB 社區(qū)的治理方案:?https://github.com/pingcap/community/issues/516[12]?The Apache Way:?https://www.apache.org/theapacheway/index.html[13]?GitHub Actions:?https://github.com/features/actions[14]?The ZeroMQ Community:?https://zguide.zeromq.org/docs/chapter6/[15]?Kubernetes 社區(qū):?https://github.com/kubernetes/test-infra/tree/master/prow[16]?Rust 社區(qū):?https://github.com/rust-lang/homu[17]?Stream Native:?https://github.com/streamnative/pulsar[18]?FLIP-85:?https://issues.apache.org/jira/browse/FLINK-16654[19]?Xuanwo 事件:?https://github.com/pingcap/tipb/pull/208[20]?FLINK-10052:?https://issues.apache.org/jira/browse/FLINK-10052[21]?FLINK-11937:?https://issues.apache.org/jira/browse/FLINK-11937[22]?FLIP-44:?https://cwiki.apache.org/confluence/display/FLINK/FLIP-44%3A+Support+Local+Aggregation+in+Flink[23]?Queryable State:?https://lists.apache.org/thread/snlsb5z9lcogdo7359dcwr4hn5qpymlo[24]?Best Practices for Maintainers:?https://opensource.guide/best-practices[25]?Leadership and Governance:?https://opensource.guide/leadership-and-governance[26]?Building Welcoming Communities:?https://opensource.guide/building-community/#growing-your-community
-關(guān)注我