Python 之父退位后，最高决策权花落谁家？

268@lemepe@silver-tabby-cat.jpg

随着 Python 之父 Guido van Rossum 逐步卸任 BDFL，Python （本文特指CPython）的未来之路牵动了万千开发者的心。目前，Python 社区共提出了 7 种治理方案，其最终胜出者，将决定 Python 未来的发展方向和方式。此话题事关重大，任何 Python 开发者最好都有所了解。Python 的核心开发者之一、PEP-8015 的作者 Victor Stinner 对这 7 个治理提案做了全面的对比，我将其翻译如下：

原文 ：http://t.cn/EyhQd3b

作者 ：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+本精选电子书。