隨着 Python 之父 Guido van Rossum 逐步卸任 BDFL，Python （本文特指CPython）的未來之路牽動了萬千開發者的心。目前，Python 社區共提出了 7 種治理方案，其最終勝出者，將決定 Python 未來的發展方向和方式。此話題事關重大，任何 Python 開發者最好都有所瞭解。Python 的核心開發者之一、PEP-8015 的作者 Victor Stinner 對這 7 個治理提案做了全面的對比，我將其翻譯如下：
作者 ：Victor Stinner
譯者 ：豌豆花下貓（Python貓 公衆號作者）
備註 ：原文發佈於11月6日，翻譯基於11月27日版本
對幾個治理提案（governance PEPs）的重要差異點，我做了一份比較。我選擇忽略了一些不太重要的方面，比如專門的投票組織（詳見每個PEP）。提取信息並總結它，這不是一件容易的事，所以我可能會出錯。
我建議在給治理提案投票時，不要以它們的完整性來評判，而要聚焦其關於決策過程的部分，即誰能拍板做決策，以及怎麼做？依我之見，那些還不夠完整的 PEP 可以吸收其它 PEP 的創意（best ideas），來逐漸完善自身。
PEPs
來自 PEP 8000:
-
PEP 8010 - 技術領導人治理模式（The Technical Leader Governance Model）
維持現狀（continue status quo (ish)）
提案人: Barry Warsaw
-
PEP 8011 - 三巨頭治理模式（Python Governance Model Lead by Trio of Pythonistas）
類似現狀，但三人決策
提案人: Mariatta Wijaya, Barry Warsaw
-
PEP 8012 - 社區治理模式（The Community Governance Model）
沒有核心決策人
提案人: Łukasz Langa
-
PEP 8013 - 外部治理模式（The External Governance Model）
非核心監督（non-core oversight）
提案人: Steve Dower
-
PEP 8014 - 大衆治理模式（The Commons Governance Model）
核心監督（core oversight）
提案人: Jack Jansen
-
PEP 8015 - Python社區的組織模式（Organization of the Python community）
將多數決策交給團隊（push most decision-making to teams）
提案人: Victor Stinner
-
PEP 8016 - 指導委員會模式（The Steering Council Model）
引導治理的迭代（bootstrap iterating on governance）
提案人: Nathaniel J. Smith, Donald Stufft
差異點
大多數 PEP 都有一個“最高決策層”（top of the hierarchy）（指導委員會，理事會，三巨頭，GUIDO，等等），除了 PEP-8012 和 PEP-8014。
PEP 8011、8012 和 8015 定義了明確會參與決策過程的“工作組”（或“專家”或“Python 團隊”），這可以視爲第二級的決策層。
PEP 8014 允許所有人（任意 Python 用戶）參與投票。PEP 8013 將核心開發者排除在決策委員會之外。除了這兩個特例，其它所有的 PEP 中的決策過程都強依賴（strongly around）於核心開發者（候選人必須是核心開發者、只有核心開發者可以投票，等等）。
PEP 8010、8012、8013、8014 和 8016 提出了不信任投票 （No Confidence Vote）（譯註：即彈劾，可將任期內的“執政人員”趕下臺）。我不確定其它 PEP 若不包含這點，是否深思熟慮（deliberate）。我喜歡這個提議，所以，會把它加入到我提出的 PEP-8015 裏 :)
PEP 8015 和 8016 嚴格限定了在委員會裏，只允許少於 50% 的成員是企業（5人委員會裏最多有2個）。其它 PEP 不設限制。
有些 PEP（8010、8011 和 8014） 裏幾乎只關注於定義最高決策層，然而其它 PEP（8015 和 8016）還關注到核心開發者的選舉/淘汰（eject）、如何更新治理提案，等等。我不知道前者是故意爲之，還是因爲時間不足而來不及完善。
PEP 8011、8014 和 8015 提到了多樣性（譯註：即決策層成員的多樣性，如女性開發者），但卻沒有提到如何“促進”（enforce）多樣性的詳細規則。PEP-8011 說道：“盡全力去接納弱勢羣體”（take every effort into including members from underrepresented group into consideration）。
最高決策層
- PEP-8012 明確地避免它
- PEP-8014 有一個長老會（Council of Elders），負責決定如何及何時批准 PEP，決定是基於對所有人開放的投票（詳見下文關於 PEP 流程的部分）
其它 PEP 稱之爲技術領導人（Technical Leader），三巨頭（Trio），理事會（Council）, 指導委員會（Steering Committee）, 等等。
成員人數
- PEP 8010: 4 = 1 (領導人) + 3 (理事會)
- PEP 8011: 3 (“trio”) + 工作組
- PEP 8012: N/A (無領導，專家團隊自治)
- 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：(現役的) 核心開發者
- PEP 8012：N/A
- PEP 8013：核心開發者；當出現平局，主席可再投一票
- PEP 8014：投票對所有人開放（無需是核心開發者）
- 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：“因爲理事會的權力純粹是程序性的，最好是讓成員的服務時間長一點。但是，如果可以定期更新（reinstate）理事會，這也挺好”
- PEP 8015：3 年，輪換選舉 (每年更換1/3)，無任期限制
- PEP 8016：1 個 Python 版本, 無任期限制
不信任投票
- PEP 8010：可用於驅逐（evict）領導人，理事會一致決定時發起, 由全體核心開發者進行多數決議（未明確多數決議的閾值）
- 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（譯註：即 The Council of Pythonistas，智囊團，爲GUIDO提供參謀意見） 協商，確定專家人選”
- 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
- PEP 8010：PEP 代表，GUIDO是 PEP 決策的最終權威
- PEP 8011：三巨頭和/或工作組？
- PEP 8012：遵照現行的 PEP 流程。提案人確定 PEP 的選題方向。提案人負責收集與整合反饋（來自整個社區）。然後，相關領域的專家們彙總全部討論，並開啓爲期 14 天的最終評審，其評審結果不再需要社區性的投票。如果一個 PEP 很有爭議，任何專家成員都可發起動議（motion）來拒絕通過它（需2/3票數）
- PEP 8013：如果理事會不否決，PEP 自動被批准
- PEP 8014：投票對所有 Python 使用者開放（不僅僅是核心開發者）。理事會宣佈投票結果是否足以作出決定。它提出了一個決定。如果理事會採納了一個上訴（appeal），則獲得多數票的一方需做出論證（demonstrated）
- 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）的成員沒有投票權
更新治理模式
- 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票數
行爲守則（Code of Conduct）
- PEP 8010：行爲守則管制所有互動與討論
- PEP 8011：三巨頭需遵守 PSF 的行爲守則
- PEP 8012：依靠現有的 PSF 行爲工作組 (在 PEP 中命名爲“版主（Moderators）”)
- PEP 8013：N/A
- PEP 8014：N/A
- PEP 8015：依靠現有的 PSF 行爲工作組
- PEP 8016：指導委員會被鼓勵去設立 CoC 的流程，同時細節可以靈活制定
（原文完，以下內容爲譯者所加）
名詞解釋 ：
PEP：全稱是 Python Enhancement Proposals（Python 增強提案），現在數量將近500個，涵蓋 Python 功能實現、規範與周邊信息等各種內容。本文出現的 7 個提案，全是針對新的治理模式，後續還可能新增這方面的提案。若想加深理解 PEP，並找到哪些提案是必讀的，可閱讀我寫的《學習Python，怎能不懂點PEP呢？》。
PSF：全稱是 Python Software Foundation（Python 軟件基金會），非營利組織，其使命是促進 Python 社區發展，負責舉辦各種社區活動，例如開發 Python 的核心發行版、管理知識產權、舉辦開發者大會（如PyCon）、促進多元與國際化、以及募集發展基金，等等。
BDFL：全稱是 Benevolent Dictator For Life（終身仁慈獨裁者），曾特指 Guido van Rossum，被賦予絕對的最終決策權。2018年7月12日，他宣佈不再擔任此身份。本文的全部 PEP 都是圍繞如何選出新的 BDFL 以及配套的治理方案，該詞不再特指某人。
譯後記 ：
這是我首次嘗試翻譯工作，其中的艱難之處真是知者自知。但是，當翻譯完畢後，我所得的甘甜喜悅也真是知者自知！由於原文大部分內容都是極度概括性的短句，還有不少專有表述，所以，我採取的翻譯策略是儘量達意，因此，難免有翻譯錯誤和偏離原文之處，歡迎讀者與我（公衆號：Python貓 ）交流指正。本文翻譯乃個人行爲，純粹出於交流學習的目的，歡迎轉載，但請保證註明出處，切勿用於商業或其它不良用途。
-----------------
本文原創並首發於微信公衆號【Python貓】，後臺回覆“愛學習”，免費獲得20+本精選電子書。