Python发展模式大转向，开发社群决定采取指导委员会管理模式

在7月时，Python之父Guido van Rossum由于疲于处理社群争议，决定卸下仁慈的独裁者（Benevolent Dictator For Life，BDFL）位子，而经过社群热烈讨论与票选后，接受了PEP 8016指导委员会（Steering Council Model）的提案，以填补Python社群决策角色空缺。

为了解决Python PEP 572指派表示式（Assignment Expressions）提案的争议，在社群讨论还未到一个阶段时，Guido van Rossum独裁的做出决定，径行决定接受PEP 572，而这项决定引来了社群内大批反对者的攻击，Guido van Rossum在身心俱疲的情况，对社群发出公开信，表示将从BDFL的位子卸任，且不会指定BDFL的继任者，他要社群透过提案的方式，决定Python重要事务的决策方法。

而之后总共出现了7项治理模型的PEPs（Python Enhancement Proposals），投票已经在12月16日结束，最后被接受的提案为PEP 8016指导委员会模型。PEP 8016和大多数提案一样，核心都是创立一个委员会，但订定的委员会规模不同，PEP 8016的指导委员会由核心团队选出的5人组成。而其定义的核心团队与现行的核心开发人员或提交者不同，该PEP明确指出除了开发者之外，其他角色也能获得核心团队的资格，只需要现有成员的三分之二多数票就能成为团队成员，而且委员会无否决权。

PEP中没有明确定义委员会否决权，而这是在提案中有被讨论到的问题，核心开发者Nathaniel J. Smith认为，这个想法来自Django治理文件，而这对该PEP产生了重大影响。社群希望否决权永远不会被使用，但是在必要的情况，当有需要移除不适任的核心团队成员，超过四分之一的委员会成员投票同意就能执行。

PEP 8016委员会的设置任务重点，便是维护Python专案的品质以及CPython的实作，确保社群可以容易的对专案进行贡献。指导委员会模式赋予委员会广泛的决策权力，但同时又希望委员会尽可能不使用该权利，而是进行广泛地授权，积极寻求共识而非下指令，并且能定义一个标准的PEP决策过程，希望不需要透过委员会投票决定，委员会应该成为最终上诉的组织。委员会不能改变治理PEP，只有核心团队三分之二投票同意才能进行。

指导委员会的服务时间以一个功能版本发布为周期，每次版本发布后进行改选，候选人由核心团队成员提名，每个核心团队成员可以匿名投票给0到5名候选人，总票数最高的5人成为指导委员会成员。PEP也规范了利益回避原则，以避免委员会遭企业控制，委员会中不能有2个以上的成员来自同一企业，该情况如在委员会任期中发生，则必须有足够人数的成员辞职以符合规定。

大多数参与票选的治理模型PEP的核心思想都很相似，除了委员会规模不同外，也有部分有特别差异，像是PEP 8010提出的技术领袖治理模型，或多或少想保留仁慈的独裁者的模式，而PEP 8012的社群治理模型，则是一个去中心权威的模型，与PEP 8010的设计理念完全相反，而有趣的是，PEP 8012得票数第二，PEP 8010则是最不受欢迎的选项。