隨著 Python 之父 Guido van Rossum 逐步卸任 BDFL，Python(CPython)的未來之路牽動了萬千開發者的心。沒了首領，Python 今后的發展會怎么樣?社區將如何運作?誰來領導 Python 這門語言和社區呢?這些問題不得不解決，而用什么樣的方式解決，這就需要先由社區討論并最終決定。目前，Python 社區共提出了 7 種治理方案，分別是 PEP 8010、PEP 8011、PEP 8012、PEP 8013、PEP 8014、PEP 8015 與 PEP 8016。這些提案都匯總在 PEP 8000 之下，其中最終勝出者，將決定 Python 未來的發展方向和方式。

[[252629]]

日前，Python 的核心開發者之一、PEP-8015 的作者 Victor Stinner 對這 7 種治理提案做了對比分析，本文引用他的分析為讀者提供一個較為全面的視圖。

背景知識

先簡單了解一下背景知識，便于后文理解。

• PEP：全稱是 Python Enhancement Proposals，Python 增強提案，現在數量將近 500 個，涵蓋 Python 功能實現、規范與周邊信息等各種內容。本文出現的 7 個提案，全是針對新的治理模式，后續還可能新增這方面的提案。若想加深理解 PEP，并找到哪些提案是必讀的，可以另外查閱相關文獻。
• PSF：全稱是 Python Software Foundation，Python 軟件基金會，非營利組織，其使命是促進 Python 社區發展，負責舉辦各種社區活動，例如開發 Python 的核心發行版、管理知識產權、舉辦開發者大會(如 PyCon)、促進多元與國際化，以及募集發展基金等。
• BDFL：全稱是 Benevolent Dictator For Life，終身仁慈獨裁者，該位置被賦予絕對的最終決策權，曾特指 Guido van Rossum。2018 年 7 月 12 日，Guido 宣布不再擔任 BDFL。本文的全部 PEP 都是圍繞如何選出新的 BDFL 以及配套的社區治理方案，該詞不再有特指意義。
• CoP：全稱是 The Council of Pythonistas，Pythonistas 委員會，為 Guido 提供參謀意見的智囊團。

目前 Python 社區的 PEP 流程是這樣的：提案人確定 PEP 的選題方向，提案人負責收集與整合來自整個社區的反饋。然后，相關領域的專家們匯總全部討論，并開啟為期 14 天的最終評審，其評審結果不再需要社區性的投票。如果一個 PEP 很有爭議，任何專家成員都可發起動議來拒絕通過它，這需要超過 2/3 的票數。

7 種方案一覽

• PEP 8010：技術領導人治理模式

維持現狀

• 提案人: Barry Warsaw
• PEP 8011：三巨頭治理模式

類似現狀，但三人決策

• 提案人：Mariatta Wijaya、Barry Warsaw
• PEP 8012：社區治理模式

沒有核心決策人

• 提案人: Łukasz Langa
• PEP 8013：外部治理模式

非核心監督

• 提案人：Steve Dower
• PEP 8014：大眾治理模式

核心監督

• 提案人：Jack Jansen
• PEP 8015：Python 社區的組織模式

將多數決策交給團隊

• 提案人：Victor Stinner
• PEP 8016：指導委員會模式

引導治理的迭代

• 提案人：Nathaniel J. Smith、Donald Stufft

區別對比

Victor Stinner 總結了 7 個 PEP 的主要區別，同時他建議在給這些治理提案投票時，不要以它們的完整性來評判，而要聚焦其關于決策過程的部分，即誰能拍板做決策，以及怎么做?他希望那些還不夠完整的 PEP 可以吸收其它 PEP 的精華，并逐漸完善自身。

總的來看，在這些 PEP 中，除了 PEP-8012 和 PEP-8014，其它的都設有一個***決策層，一般的形式包括指導委員會、理事會、三巨頭、Guido 等。

• PEP 8011、8012 和 8015 定義了明確會參與決策過程的工作組/專家/Python 團隊，這可以視為第二級的決策層。
• PEP 8014 允許任意 Python 使用者參與投票，PEP 8013 將核心開發者排除在決策委員會之外。除了這兩個特例，其它 PEP 中的決策過程都強依賴于核心開發者，候選人必須是核心開發者，或者只有核心開發者才可以投票。
• PEP 8010、8012、8013、8014、8015 和 8016 都提出了不信任投票，也就是彈劾機制，可將任期內的當權者趕下臺。Victor 認為沒有這一項是不明智的。
• PEP 8015 和 8016 嚴格限定了在委員會里，只允許少于 50% 的成員是企業(5 人委員會里最多有 2 個)，而其它 PEP 不設限制。
• PEP 8010、8011 和 8014 幾乎只關注于定義***決策層，而 PEP 8015 和 8016 還關注到核心開發者的選舉/淘汰、如何更新治理提案等。
• PEP 8011、8014 和 8015 提到了決策層成員的多樣性，比如女性開發者是否能有一席之地，像 PEP-8011 就指出“盡全力去接納弱勢群體”，但卻沒有提到如何去促進多樣性的詳細規則。

下邊具體拆解出各個治理方案的各項對比：

***決策層

• PEP 8012 明確地避免它
• PEP 8014 有一個長老會，負責決定如何及何時批準 PEP，該決定基于對所有 Python 使用者開放的投票
• 其它 PEP ***決策層的形式為技術領導人、三巨頭、理事會、指導委員會等。

成員人數

• PEP 8010：4，包括 1 名領導人和理事會 3 人
• PEP 8011：3 (三巨頭) + 工作組
• PEP 8012：無領導，專家團隊自治
• PEP 8013：2-4 ，含 1 名主席
• PEP 8014：5-10 (理事會)
• PEP 8015：5 (委員會) + Python 團隊
• PEP 8016：5 (委員會) ，或者再加其它團隊/多委員會/代表等，據需求而定

候選人的條件要求

• PEP 8010：核心開發者
• PEP 8011：核心開發者、 PSF 的投票成員、三巨頭、盡全力去接納弱勢群體
• PEP 8012：N/A
• PEP 8013：決不能是核心開發者
• PEP 8014：不要求是核心開發者、***是多元化的委員會、成員應了解 Python 與 Python 社區
• PEP 8015：核心開發者、 最多 2 名企業成員
• PEP 8016：由核心開發者提名、 最多 2 名企業成員

選舉：誰投票，怎么投?

• PEP 8010：核心開發者
• PEP 8011：active 狀態的核心開發者
• PEP 8012：N/A
• PEP 8013：核心開發者，當出現平局時，主席可再投一票
• PEP 8014：投票對所有 Python 使用者開放
• PEP 8015：核心開發者，若平局則進行二次投票，若二次投票還是平局，則由 PSF 董事會 選擇
• PEP 8016：核心開發者，若出現平局，可由候選人協商解決，否則隨機選擇

任期長度與限制

• PEP 8010：領導人任期 4.5 年，經歷 3 個 Python 版本;委員會 3 年一屆
• PEP 8011：5 年
• PEP 8012：N/A
• PEP 8013：1 個 Python 版本，可連任
• PEP 8014：認為理事會的權力純粹是程序性的，***是讓成員的服務時間長一點。但是又表示如果可以定期更新理事會也挺好
• PEP 8015：3 年，輪換選舉，每年更換 1/3，可連任
• PEP 8016：1 個 Python 版本，可連任

不信任投票

• PEP 8010：可用于彈劾領導人，理事會一致決定時發起，由全體核心開發者進行多數決議，但未明確多數決議的閾值
• PEP 8011：N/A
• PEP 8012：N/A
• PEP 8013：投票需要大于 2/3 票數，針對單個理事會成員
• PEP 8014：1 名長老，或者 10 名核心開發者的團體，或者 PSF 投票成員，可以申請即時生效的投票，針對整個理事會
• PEP 8015：N/A
• PEP 8016：投票需要 2/3 票數，針對單個成員或整個委員會

團隊/專家的任免

• PEP 8010：對單個 PEP，Guido 與 CoP 協商確定專家人選
• PEP 8011：3-5 人組成的工作組給三巨頭提建議，不需要是核心開發者
• PEP 8012：專家自組織成特定興趣領域的子團隊，這避免了大多數投票和委員會設計。解散某個專家團隊時，需要大于 2/3 票數
• PEP 8013：N/A
• PEP 8014：N/A
• PEP 8015：自組織式的 Python 團隊，委員會可允許他們批準自己的 PEP 打包團隊(Packaging Team)，要求核心開發者和貢獻者
• PEP 8016：N/A

PEP 流程

• PEP 8010：PEP 代表，Guido 是 PEP 決策的最終權威
• PEP 8011：三巨頭和(或)工作組?Victor 也不確定
• PEP 8012：遵照現行的 PEP 流程，提案人確定 PEP 的選題方向，提案人負責收集與整合來自整個社區的反饋。然后，相關領域的專家們匯總全部討論，并開啟為期 14 天的最終評審，其評審結果不再需要社區性的投票。如果一個 PEP 很有爭議，任何專家成員都可發起動議來拒絕通過它(需 2/3 票數)
• PEP 8013：如果理事會不否決，PEP 自動被批準
• PEP 8014：投票對所有 Python 使用者開放，而不僅僅是核心開發者。理事會會決定投票結果是否采用。一般投票，票數高者獲勝，根據投票結果理事會是應該直接作出決定的，但是如果落后方此時進行申訴，而理事會有所動搖，那么此時已經獲得多數票的一方需要做出論證。理事會最終會做出決定
• PEP 8015：委員會在 PEP 代表(一般來自 Python 團隊)之間做選擇，或者交給核心開發者投票，需大于 2/3 票數
• PEP 8016：理事會在必要時可直接地批準/否決 PEP，但***是設置流程來避免這樣做決策，例如，將決策權委派給團隊或者 BDFL 代表

核心開發者考核

晉升

• PEP 8010：N/A
• PEP 8011：N/A
• PEP 8012：核心開發者投票，要求全員投票通過，每個 -1 都算作否決權
• PEP 8013：核心開發者投票，要求全員投票通過，每個 -1 都算作否決權
• PEP 8014：N/A
• PEP 8015：核心開發者投票，需 2/3 票數
• PEP 8016：核心開發者投票，需 2/3 票數，理事會有否決權

淘汰

• PEP 8010：N/A
• PEP 8011：N/A
• PEP 8012：不信任投票，需大于 2/3 票數
• PEP 8013：N/A
• PEP 8014：N/A
• PEP 8015：實施工作組臨時禁令，移除核心開發者身份
• PEP 8016：指導委員會投票，需大于 4/5 票數。此外處于“inactive”狀態的成員也會失去特權，直到他們再次變為“active”狀態

更新治理模式

• PEP 8010：N/A
• PEP 8011：N/A
• PEP 8012：N/A
• PEP 8013：N/A
• PEP 8014：N/A
• PEP 8015：委交給核心開發者，需 4/5 票數
• PEP 8016：委交給核心開發者，需 2/3 票數

行為守則

• PEP 8010：行為守則管制所有互動與討論
• PEP 8011：三巨頭需遵守 PSF 的行為守則
• PEP 8012：依靠現有的 PSF 行為工作組，這在 PEP 中命名為“版主(Moderators)”
• PEP 8013：N/A
• PEP 8014：N/A
• PEP 8015：依靠現有的 PSF 行為工作組
• PEP 8016：指導委員會被鼓勵去設立 CoC 的流程，同時細節可以靈活制定

參考：Comparison of the 7 governance PEPs

作者介紹

豌豆花下貓，關注 Python 技術、數據科學和深度學習領域。個人公眾號：Python貓。