Python之父退位后，会有新任终身仁慈独裁者吗？怎么产生？

随着 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 未来的发展方向和方式。

日前，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