随着 Python 之父 Guido van Rossum 逐步卸任 BDFL,Python (本文特指CPython)的未来之路牵动了万千开发者的心。
目前,Python 社区共提出了 7 种治理方案,其最终胜出者,将决定 Python 未来的发展方向和方式。此话题事关重大,任何 Python 开发者最好都有所了解。
Python 的核心开发者之一、PEP-8015 的作者 Victor Stinner 对这 7 个治理提案做了全面的对比。下面是编程派的朋友“豌豆花下猫”(Python猫 公众号作者)的翻译投稿。
经译者同意,我对译稿进行了略微调整,将部分差异对比改为表格的形式,方便直接比较。另外,还添加了一个读者投票,欢迎大家发出自己声音。
以下是原文:
对几个治理提案(governance PEPs)的重要差异点,我做了一份比较。我选择忽略了一些不太重要的方面,比如专门的投票组织(详见每个PEP)。提取信息并总结它,这不是一件容易的事,所以我可能会出错。
我建议在给治理提案投票时,不要以它们的完整性来评判,而要聚焦其关于决策过程的部分,即谁能拍板做决策,以及怎么做?依我之见,那些还不够完整的 PEP 可以吸收其它 PEP 的创意(best ideas),来逐渐完善自身。
治理模式、核心开发者晋升等
双击查看大图
对比表格链接:
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 都有一个“最高决策层”(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)。
原文 :http://t.cn/EyhQd3b作者 :Victor Stinner译者 :豌豆花下猫(Python猫 公众号作者)
名词解释
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 以及配套的治理方案,该词不再特指某人。
你倾向于哪种治理模式?
欢迎留言和我们分享
如果觉得文章对你有所帮助,欢迎点赞并且推荐给你的好友。
题图:pexels,CC0 授权。
领取专属 10元无门槛券
私享最新 技术干货