Python 之父退位后,最高决策权花落谁家?
0

随着 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+本精选电子书。

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!