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之父退位后,会有新任终身仁慈独裁者吗?怎么产生?

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

相关推荐