上个月介绍了 Python 社区提出了 7 种新的候选治理方案，派友们也投出了自己的一票。前些天投票环节已经结束，最终社区的决定和你选择的一样吗？
从之前公众号投票结果来看，派友们更倾向于技术领导人这种类BDFL的治理方式，但最终胜出的方案是 PEP 8016，指导委员会治理模式。这种模式之前在 Django 的管理上已经有充分运用。
指导委员会：目标是引导治理的迭代
PEP 8016 治理方案采用指导委员会模式，其特点是引导治理的迭代，该方案由 Nathaniel J. Smith 和 Donald Stufft 提出。
指导委员会将作为 Python 的“最终上诉法院”，并将对决策过程拥有广泛的权力，包括接受或拒绝PEP的能力（Python增强建议），执行和更新项目的行为准则，创建子委员会和管理项目资产。
PEP 提出人如是说
Nathaniel Smith和Donald Stufft在 PEP 8016 中解释道：
我们不是管理专家，我们认为 Python 并不是一个好的实验对象，去实践新的或者没有经过证实管理模型。所以这个模型尽可能地成熟的，众所周知的，经过测试。大多数成功的F/OSS项目中最常见的是,一个大多数不干涉的理事会，而且详细的细节直接来自Django的管理模型。
理事会尽量不干涉或偶尔干涉PEP流程
Nathaniel Smith 和 Donald Stufft说，理事会的预期目标是采取更多不干涉和偶尔干涉的方式来发挥其权力。
指导委员会的任务是提供一种可访问的，可维护的，形式化的引入变更的方法，基于『一般的理念，即将大的变化分成一系列可以独立审查的小变化：而不是试图在一个PEP中做所有事情，我们专注于为进一步的治理决策提供最小但坚实的基础。』
新的 PEP 流程
基于这样的理念，PEP 8016 中也提出了新的 PEP 流程。
目前的 PEP 流程是提案人确定 PEP 的选题方向，提案人负责收集与整合来自整个社区的反馈。然后，相关领域的专家们汇总全部讨论，并开启为期 14 天的审查，之后进行社区投票。如果一个 PEP 很有争议，任何专家成员都可发起动议来拒绝通过它，这需要超过 2/3 的票数。
PEP 8016 的 PEP 流程：理事会在必要时可直接地批准/否决 PEP，但最好是设置流程来避免这样做决策，例如，将决策权委派给团队或者 BDFL 代表。
对开发者的影响
最后，简单聊聊 Python 启用新治理模式之后，对作为 Python 开发者的你又有什么影响？
可能是消极的影响：
好的影响：
题图：pexels，CC0 授权。
点击阅读原文，查看更多 Python 教程和资源。
