随着 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

作者介绍

豌豆花下猫，关注 Python 技术、数据科学和深度学习领域。个人公众号：Python猫。

本文系作者投稿文章。欢迎投稿。

投稿内容要求

• 互联网技术相关，包括但不限于开发语言、网络、数据库、架构、运维、前端、DevOps（DevXXX）、AI、区块链、存储、移动、安全、技术团队管理等内容。
• 文章不需要首发，可以是已经在开源中国博客或网上其它平台发布过的。但是鼓励首发，首发内容被收录可能性较大。
• 如果你是记录某一次解决了某一个问题（这在博客中占绝大比例），那么需要将问题的前因后果描述清楚，最直接的就是结合图文等方式将问题复现，同时完整地说明解决思路与最终成功的方案。
• 如果你是分析某一技术理论知识，请从定义、应用场景、实际案例、关键技术细节、观点等方面，对其进行较为全面地介绍。
• 如果你是以实际案例分享自己或者公司对诸如某一架构模型、通用技术、编程语言、运维工具的实践，那么请将事件相关背景、具体技术细节、演进过程、思考、应用效果等方面描述清楚。
• 其它未尽 case 具体情况具体分析，不虚的，文章投过来试试先，比如我们并不拒绝就某个热点事件对其进行的报导、深入解析。

投稿方式

• 以 Word 或者 Markdown 文档的形式将稿件投递到 oscbianji@oschina.cn 邮箱

重要说明

• 作者需要拥有所投文章的所有权，不能将别人的文章拿过来投递。
• 投递的文章需要经过审核，如果开源中国编辑觉得需要的话，将与作者一起进一步完善文章，意在使文章更佳、传播更广。
• 文章版权归作者所有，开源中国获得文章的传播权，可在开源中国各个平台进行文章传播，同时保留文章原始出处和作者信息，可在官方博客中标原创标签。