剖析Docker項目的組織架構

DockOne的肖遠昊組織翻譯了Docker官方的Maintainer文檔，以便讓大家更好的了解Docker的組織架構。官方的 Maintainer文檔看起來比較亂，所以我們也調整了格式。官方文檔之所以無序，是因為他們還考慮到便于程序去解析，所以如何你想了解 Maintainer的信息，可以寫個程序去解析（基于TOML的解析器即可）這個文件。

DockOne組織翻譯了Docker官方的Maintainer文檔，以便讓大家更好的了解Docker的組織架構。官方的Maintainer文檔看起來比較亂，所以我們也調整了格式。官方文檔之所以無序，是因為他們還考慮到便于程序去解析，所以如何你想了解Maintainer的信息，可以寫個程序去解析（基于TOML的解析器即可）這個文件。

Docker有多個類型的Maintainer，他們分別承擔了不同的職責。但是所有的Maintainer都有三個共同點：

1. 他們都很關心項目的成敗。
2. 他們需要長期為項目投入很多的時間。
3. 他們需要做那些必須要做的事情，而不是那些最有意思的事情。
</ol>
可能很少會有人去夸贊Maintainer，因為他們大多都是默默無聞的工作著，修改Bug、穩步提高性能、保證某個版本的可靠性....但我們要知道，Maintainer做的事情是最最重要的事情。

Docker使用的是高效，但不完全公平的管理體系，在整個項目中，有一個仁慈的獨裁者（BDFL）的角色，當然他就是Solomon Hykes（Docker之父）。也就是說，所有的決策都是由Solomon做的，但Solomon肯定沒那么多精力，所以在實踐中，決策就延伸到了各種 Maintainer身上。

實際上，BDFL角色就像英國女王：擁有令人敬畏的王冠，卻不是日常進行運營的角色。一個BDFL的真實工作就是『永遠不能離開』。其他的每一項規則或許可以徹底改變，但是BDFL必須保持項目的哲學和原則，保有決定其命運的最終權威。這種方式讓我們可以靈活地嘗試不同管理模型，讓我們可以經常按下『重置按鈕』而不用擔心分裂或者死鎖。當然我們可以將美國國會當成一個反例。

BDFL的日常工作包括：


• 項目治理是否卡在了一個死鎖上或者可能有其他問題（irreversibly fragmented）？如果是，BDFL將重構項目的管理方式。
• 是否有一些逐步升級的核心問題或沖突？如果有，解決他們。
• 擦亮自己的王冠。
</ul>
那Maintainer或者BDFL如何做決策了？官方的回答是『EVERYTHING IS A PULL REQUEST』。

Docker是一個擁有開源設計哲學的開源項目，也就是說代碼倉庫就可以提現這些設計，包括它的哲學、設計、路線圖和API。如果它是這個項目的一部分，它就在代碼庫中。如果它在代碼庫中，它就是這個這個項目的一部分。

結果，隨著代碼庫的變化，所有的決策都能被表述。一個改變的實現就是源碼的一個改變。一個API的改變就是API說明書的一個改變。一個哲學的改變就是哲學宣言上的一個改變等等。

所有決策都影響著Docker，不論大與小，都需要遵循3個相同的步驟：


• 第一步：打開一個pull request。任何人都能做到這一點。
• 第二步：討論這個pull request。任何人都能做到這一點。
• 第三步：合并或者拒絕這個pull request。誰來做這一點是依賴于這個pull request的本質以及它將影響這個項目的哪個方面。詳情請見review flow。
</ul>
由于Docker是一個龐大且活躍的項目，因此每個人都需要知道誰負責決定哪個方面，這是由一套明確的規則來決定的。


• 對于這個項目的每一個決策，規則需要使用一種確定性的方式指派負責決定決策的人。
• 對于這個項目的每一個難題，規則需要使用一種確定性的方式指派負責修復難題的人。
• 對于這個項目的每一個問題，規則需要使用一種確定性的方式指派負責回答問題的人。
</ul>
Pull Request應該根據以下流程進行處理：


• 如果PR會影響到子系統，那子系統的Maintainer必須接受或者拒絕這次更新。子系統的Maintainer有責任及時處理對他們有影響的補丁。
• 如果代碼更新所影響到的不是一個子系統的某一部分，或者子系統Maintainer不能及時做出決定，那么這次更新必須由Maintainer來接受。
• 如果代碼更新影響的是用戶接口或者公共API，或者它代表體系結構上的一個主要更新，那么必須由架構師們接受或者拒絕這次更新。
• 如果代碼更新影響到項目的運營，那么它必須由相關的運營人員接受或者拒絕。
• 如果代碼更新影響到了項目的管理，哲學，目標或者規則，它必須由BDFL來接受。
• 一個pull request可能是以上五種不同情形中的一種，對于每一種情形都需要加上相應的標簽。Rule.review.states包括了每一種情形可能的目標列表。它們分別是：Triage、Design review、Code review、Docs review、Merge。
</ul>


Docker的組織架構

1. BDFL（仁慈的獨裁者，女王）
BDFL由Shykes（Solomon Hykes）擔任。同樣，作為首席架構師，他負責所有子系統技術架構的全局完整性，以及API與UI的一致性。UI、公共API和全局架構（比如說嵌入式系統）的更新都需要由首席架構師來接受。

2. 首席運營官
目前由spf13擔任，負責項目的日常運營，包括：


• 促進所有貢獻者之間的溝通；
• 跟蹤發行日程；
• 負責下游分發與上游依賴之間的關系；
• 幫助新貢獻者的介入，并幫助他們成為貢獻者和Maintainer。
• 負責管理和評測項目整體上的成功，并配合Docker治理咨詢委員會（DGAB）的工作。
</ul>
3. 運營

運營人員確保『火車』準點出發。他們負責項目的全局運作。這包括促進所有參與者之間的交流；幫助新人加入并成為貢獻者、Maintainer；跟蹤發行日程；管理下游分發與上游依賴之間的關系；制定項目成功的評測標準并衡量進度；設計和實現那些讓貢獻者和Maintainer更開心，更有效率的工具與過程。

4. 首席Maintainer

目前由crosbymichael擔任。首席Maintainer負責項目各方面的質量，包括代碼檢查、可用性、穩定性、安全性、性能等。首席Maintainer需要以榜樣來領導別人。所以對于一個新的Maintainer的第一天，最好的建議是向首席Maintainer學習如何工作。

5. 核心Maintainer

核心Maintainer就是項目的ghostbusters，如果有一個其他人都沒法解決的難題，那么他們就會出面解決這個難題。他們對技術實施和編碼風格具有最終決定權。他們負責代碼的所有形式有最終的責任：可用性的改進，bug的修復，性能，穩定性等等。當所有權能夠清晰地傳遞到一個子系統時，他們要負責這些東西并保持子系統Maintainer的責任感。如果所有權不明確，他們就是實際的擁有者。對于每個發行版（包括次要發行版），需要在核心Maintainer中分配一個 "release captain"。 鼓勵在所有Maintainer中進行輪換，來確保發行過程的清晰與最新。核心Maintainer共同的特點是可以通過"branch out"來加入或者開啟一個子系統。

6. Subsystems

隨著項目的推進，Docker將被分割成更恰當定義的子系統。其中每個子系統都有一組專屬的Maintainer，他們致力于這個子系統并負責它的質量。

各個子系統Maintainer的責任如下：


1. 公布一個清晰的路線圖。
2. 對于影響他們子系統的pull request，需要迅速反饋并決策。
3. 重視所有的問題、Bug、批評等等。收集渠道包括IRC、GitHub Request和郵件列表。
4. 確保他們的子系統遵守項目的哲學、設計和路線圖。
</ol>
7. Curator（監護者）

監護者會將收到的問題和pull request分類，借助他們對代碼倉庫活動的認知，他們能夠引導貢獻者到相關資料和討論上。他們從不進行代碼或者文檔的檢查，因此他們從來都不能進行代碼的合并。但是他們能夠做到：

• 當一個問題或者pull request重復，他們可以關閉它。
  
• 當一個問題或者pull request不太合適或者離題了，他們可以關閉它。
  
  來自：http://dockerone.com/article/340