• Python启用新的管理模式
  • 发布于 2个月前
  • 188 热度
    0 评论
早在10月底,当我们研究Python管理问题时(这个问题是由于Guido van Rossum辞职而产生的),大部分问题似乎都将在11月底进行投票后尘埃落定。在截至到12月1日的两周内,选民将对6项Python增强提案(PEPs)进行排名并投票;排序复选投票(原文:instant-runoff voting)将决定谁是获胜者。但在此期间,很多情况都发生了变化;投票期限、获胜者判定机制和需要考虑的PEP数量都各不相同。但投票最终在12月16日结束,并已宣布获胜者;11月初提交的PEP 8016(“管理理事会模式”)直冲榜首,一举夺魁。

就在我们发布上一篇文章的前后,Python 提交者讨论平台上启动了一个新话题,来讨论各种投票系统的优缺点。排序复选投票(原文:instant-runoff voting)不受欢迎;有人担心它不能真正代表选民的意愿,就像2009年Vermont州Burlington市的市长选举一样。事实上,它是在核心开发人员短时间亲自对话后以命令的形式宣布的自己强加的最后期限,而不是在讨论平台上或python提交者邮件列表上长时间讨论后解决的,这也可能是一个因素。正如Nathaniel J. Smith所说:

我对所有这些关于如何确定最后期限的花言巧语特别担心,每个人都必须排队。我也想尽快完成!但试图像这样压倒其他核心开发者,并像一些核心开发者那样通过纯粹的法令来解决这样的分歧,是一个非常不健康的先例。我觉得我们中的一些人对“确保我们看起来可以一起工作,一起做决定,一起举行合法的投票”这件事非常关心,但这恰恰削弱了我们一起工作,一起做决定,一起举行合法投票的能力。


Donald Stufft对许多不同的投票系统及其优缺点进行了长篇总结。没有人对使用“多数票表决”(也称为“得票多者胜”)感兴趣,但对其他可能性的看法则不同。最终,PEP 8001(“Python管理投票流程”)被更改为使用Condorcet原则(是指当存在2个以上的候选者时,只有一种办法能严格而真实地反映多数成员的愿望,这就是对候选者进行成对比较,若存在某个候选者,他能按过半数规则击败其他所有候选人,则他被称为Condorcet候选人,应由该候选者当选。)来确定获胜者。在Condorcet原则下,平局或循环都有可能(尽管可能性不大),这将导致在平局选项中必须进行重新投票。Condorcet原则已经被Debian和其他项目使用多年,这也是大家对该方法形成共识的部分原因。

获胜者

最终,采用Condorcet原则进行了选举,选举结果很明确,没有任何异议。正如Tim Peters——选举方法讨论中众多活跃开发者之一——指出:“不仅会有一个不折不扣的Condorcet (打败所有人)获胜者,即使我们把此获胜者移除,在剩下 的七个参选者中还是会有一个不折不扣 Condorcet获胜者 ——以此类推,一直到‘进一步讨论’”。考虑到选民人数相当少,只有94人,而实际投票的人数只有62人,结果可能会更加混乱。

在选举中落选较晚的人显然是赢家,这也许并不奇怪。Smith和Stufft起草了PEP;它可能受益于对其他pep的讨论以及一路上对它们所做的更改。这一点也不影响将其设计成无趣、简单和灵活的明确初衷。

与大多数其他提案一样,PEP 8016创建了一个理事会。在其他PEP中提出了不同的规模,但是PEP 8016的管理理事会由核心团队选出的5人组成。核心团队的定义与当今的核心开发人员或提交者在某种程度上不同。该PEP明确指出,“开发人员”以外的角色可以胜任核心团队。成为团队的一员只需要获得现有成员三分之二的票数即可,而不需要管理理事会的表决。

在PEP中没有很好地规定否决权,这是讨论过程中的一个问题。根据Smith的说法,这个想法来自Django管理文档,它对该PEP有很大的影响。人们希望它永远不会被使用,“但在替代方案更糟的情况下,可能就需要使用否决权”。当然还是有一个保留方案,比如发现需要移除核心团队成员时,理事会四个成员的绝对多数可以进行投票表决。

指导理事会

理事会被赋予“对项目作出决定的广泛授权”的权力,但目标是它尽可能少使用这种权力;它的目的是广泛地授权。PEP指出,理事会应该寻求共识,而不是发号施令,它应该定义一个标准的PEP决策过程,这个决策过程(希望如此)很少需要理事会投票来解决。然而,它是影响语言发展的决定的“终审法院”。但理事会不能改变管理PEP,这只能通过核心团队三分之二的投票来实现。

指导理事会的任务集中在Python和CPython实现的质量和稳定性等方面,并确保对项目做出贡献的途径是容易的,这样就会有更多的人对项目发展做出贡献。除此之外,维护核心团队和Python软件基金会(PSF)之间的关系是另一个难题。指导理事会成员的服务周期是单个Python特性版本的长度;每一个版本发布后,将选出一个新的理事会。候选人必须由核心团队成员提名;“批准投票”权将用于选择新的理事会。每个核心团队成员可以匿名投票给0到5名候选人;总票数最高的五名候选人将担任新一届理事会的成员,遇到票数相等时,由票数相等的候选人进行协商或随机选择决定。

还有一些利益冲突规则:“尽管我们相信理事会成员的行为符合Python的最佳利益,而不是他们自己或他们的雇主的利益,任何一家公司主导Python开发的出现都会损害其自身利益,并削弱其信任度。”因此,同一家公司的理事会成员不得超过两名;如果该公司有第三个人当选,他们将被取消资格,得票第二高的人将被提拔。如果在理事会任期内出现以下情况(例如更换雇主或收购公司),必须有足够多的理事会成员辞职,以确保理事会的组成。理事会的空缺(由于此原因或任何其他原因)将由理事会投票填补。

如果核心团队对理事会不满,可以进行不信任投票。核心团队成员可以要求进行这样的投票;如果有任何其他成员支持该呼吁,将举行投票。投票可以针对理事会的一个成员,也可以针对整个理事会。如果有三分之二的核心团队成员投了反对票,该理事会成员或整个理事会将被免职。在后一种情况下,新的理事会选举将立即举行。
其他一些PEP具体规定了一些事情,例如PEP将如何敲定或对任职于理事会的人员设置了各种限制。Victor Stinner对这七个提议的总结很好地概括了它们之间的共同点和不同点。许多在高度层面上完全相似,大多数明显地在理事会的规模上有所不同,当然还有一些其他实质性的差别。PEP 8010(“技术领导者管理模式”)或多或少保留了“仁慈的独裁者”模式,而PEP 8012(“社区管理模型”)没有中央权威,两者都是异类。有趣的是,8012在投票中排名第二,而8010是最不受欢迎的管理选项之一。

另一个选举

接下来是理事会选举。有两个阶段,每个阶段将持续两周;首先是提名期,然后是实际投票。Van Rossum并没有像有些人想的那样置身事,外甩手不管;他积极参与一些有关管理选举的议程,并率先开始组织理事会选举。他要求在新年之后开始选举过程,给人们一些时间在假期放松。Smith表示同意。他指出,从1月6日开始选举将导致从1月20日开始实际投票以及2月3日进行理事会选举,这没有任何影响。

总的来说,自从Van Rossum下台以来,这个过程进行得相当顺利,并且将在7月份正式采用新的管理模式。理事会似乎有很多不错的候选人,其中许多人积极参与了管理讨论。第一届新理事会将有很多事情进行决定,包括PEP审批过程,但它并没有那么多时间来做这些。与通常的18个月周期不同,该理事会的任期将缩短,直到Python 3.8发布,目前预定于2019年10月发布。在此之后当选的理事会将会有整整18个月的任期,当然,除非发布周期缩短。观看此次选举将非常有趣;再一次,敬请期待。
用户评论