关键人物及其职能

审计委员会 (CoA) 是一个规模不定的委员会，通常由两到四人组成，任期为一个 Python 版本。CoA 的一名成员被视为主席，对其他成员拥有一些微小的权力。

CoA 负责审查核心开发团队成员撰写的 PEP 中有争议的决策。CoA 可以选择完全接受提交的 PEP，也可以要求澄清或修改。这些修改可以采取任何形式，原因不限。这种灵活性是故意的，并允许流程随着不同成员被选入 CoA 而随时间变化。有关预期请求类型的示例，请参阅本文档的后续部分。

CoA 只对提交给 python-committers 的 PEP 发表意见。不期望 CoA 关注或参与任何其他邮件列表。（请注意，这意味着只有核心开发者才能提交 PEP。非核心开发者可以在其他邮件列表上撰写和讨论提案，但如果没有核心开发者愿意支持该提案并请求其发表意见，则该提案无法被接受。这本质上与当前系统相同，但在此明确说明，以确保 CoA 成员不被期望处理未得到至少一名核心开发者支持的提案。）

CoA 不能将权力委托给未经核心开发团队选举产生的人员。（一个相关案例是，这改变了现有 BDFL-Delegate 系统的实施，尽管不一定改变该系统的精神。有关此点的更多讨论，请参阅后续部分，特别是示例场景四。）

发布经理 (RM) 也被允许像以前一样请求对任何指定其负责版本的 PEP 进行修改。功能冻结后，RM 保留其版本的此职责，而 CoA 则轮换并开始关注后续版本。这与当前流程没有区别。此提案未更改 RM 的选择流程。

核心开发者负责选举 CoA 成员，并具有对 CoA 成员发起“不信任投票”的能力。这些投票的详细信息将在后续部分讨论。

在核心开发者和 CoA 成员之间的讨论似乎正在进行但没有成效的情况下，主席可以介入推翻任何一方。如果讨论涉及主席，则应通过不信任投票来处理。

CoA 成员可以随时选择辞职。如果 CoA 仍有至少两名成员，他们可以请求重新选举以填补该团体。如果只剩下一名成员，选举将自动触发。（主席辞职的情况将在后续部分描述。）

预期的权力平衡是，核心开发者将选举能够反映开发团队方向并获得其信任的 CoA 成员，同时也有能力罢免那些未能履行选前承诺的成员。

常规决策流程

常规决策将照常进行。

为清晰起见，有争议的决策需要 PEP，而任何需要 PEP 的决策都将被视为有争议的。

可以请求 CoA 就某个决策是否最好通过有争议的决策流程来做出提供建议，或者 CoA 的个别成员可以主动提出此类建议，但核心开发团队不受此建议的约束。

争议决策流程

有争议的决策始终以 PEP 的形式写出，遵循现有流程。批准者（以前称为“BDFL-Delegate”）始终是 CoA，并且不再可以委派。请注意，这并不阻止 CoA 决定提名一名核心开发者来评估提案并向 CoA 提供建议，这本质上与当前的委派流程相同。

CoA 将对提交给 python-committers 并请求其发表意见的 PEP 发表意见。CoA 的任何成员或当前的 RM，都可能出于任何原因请求修改 PEP，前提是他们提供一些指示，说明需要进行哪些额外工作才能满足其期望。有关预期原因的示例，请参阅后续部分。

当 CoA 的所有成员和 RM 都表示他们对 PEP 没有疑虑时，该 PEP 将被正式接受。当 CoA 的一个或多个成员未在合理时间内做出回应时，CoA 主席可以选择将其解释为默示批准。主席未能回应的情况应通过不信任投票来处理。

选举任期

CoA 成员的任期为一个版本。成员在之前版本的特征冻结之前当选，并任职至其版本的特征冻结。

成员可以不限次数地寻求连任。没有任期限制。由核心开发者决定在有共识的情况下阻止 CoA 成员连任，如果该个人不应再次任职。

选举投票流程

每个 CoA 成员的选举流程如下：

• 发送一封提名邮件至 python-committers
• 发送一封附议邮件
• 被提名者暂时添加到 python-committers，以便介绍自己并陈述其立场
• 投票在之前版本的预定特征冻结前两周开始
• 通过修改私有 github 存储库中的文档来贡献选票
• 每个核心开发者都可以为任意数量的候选人投 +1 票
• 七天后，投票结束
• 得票最多的被提名者当选为 CoA 主席
• 得票第二多的前三名被提名者，且得票数至少为主席所得票数的 50%，当选为 CoA 的其他成员
• 在需要解决平局的情况下，RM 可以为他偏好的候选人多投一票
• 被接受的被提名者保留在 python-committers 中；其他人将被移除

不信任投票流程

不信任投票流程如下：

• 向 python-committers 发送一封不信任投票邮件，指明受影响的 CoA 成员，说明提名的理由，并可选择列出提名人认为应撤销的已接受 PEP
• 七天内发送一封附议邮件
• 被提名的 CoA 成员有七天时间回应，之后提名人或附议人可以撤回
• 如果没有可用的提名人或附议人，则不再采取进一步行动
• 投票立即开始
• 每个核心开发者可以通过修改私有 github 存储库中的文档来投票 +1（罢免 CoA 成员）或 -1（保留 CoA 成员）
• 七天后，投票结束
• 如果 +1 票多于 -1 票，则 CoA 成员将被从 python-committers 中移除，并且任何被提名的 PEP 都将被撤销
• 如果 CoA 的剩余成员要求，或者只剩下一名 CoA 成员，则可以按照常规流程举行新的选举来替换被罢免的成员。
• 在罢免 CoA 主席的情况下，最初获得第二多选票的候选人将成为主席。

场景 1 - 模糊 PEP 的案例

过去，初始提案常常缺乏足够的细节，以至于除了提案人之外，没有人能够实施。为避免这种情况，CoA 应在提交时“新鲜”阅读提案，而不推断或使用任何隐含的上下文。然后，当 PEP 的某个方面不清楚时，CoA 可以拒绝该提案并要求澄清。

由于提案被拒绝，因此必须对其进行修改和重新提交才能再次进行审查。CoA 将决定在拒绝 PEP 时提供多少指导，因为这将影响其可能需要重新提交多少次（从而影响 CoA 自身的工作量）。这确保了最终的 PEP 文本能够独立存在并包含所有必需的信息。

场景 2 - 无休止讨论的案例

偶尔，Python 贡献者之间的讨论可能不再有价值。例如，当大量的电子邮件重复已经处理过的内容，或者对他人表现出敌意时，继续进行“讨论”就没有意义了。

当在 python-committers 上就请求发表意见的讨论发生时，CoA 成员应通过拒绝提案来宣布该线程结束。在大多数已知情况下，此类讨论表明提案未能充分解决所有担忧，作者可能需要加强某些部分。

或者，在没有其他 CoA 成员拒绝的情况下，主席可以通过接受提案来宣布线程结束。理想情况下，这应该在与 CoA 和 RM 的其余成员直接确认他们都没有顾虑之后发生。

当此类讨论发生在其他列表中时，CoA 成员应被视为与其他核心开发者（特别是那些被指定为该领域专家核心开发者）相似的受尊敬的声音。虽然没有人有权结束线程，但预先声明阻止提案的意图是缓和可能无用的讨论的一种有用方法。自愿关注 python-committers 以外的讨论的 CoA 成员可以建议提案人撤回，但只能批准或拒绝正式提交以发表意见的提案。

场景 3 - 未考虑用户的案例

过去的一些提案可能在撰写并提交发表意见时，没有考虑到对特定用户群体的影响。例如，一项影响在各种机器上使用 Python 所需依赖项的提案，即使许多用户不受影响（因为依赖项通常默认可用），也可能对某些用户产生不利影响。

如果提案似乎没有考虑到所有用户，CoA 可能会选择运用其判断和过往经验来确定受该变更影响的用户比 PEP 中描述的要多，并要求 PEP 也考虑这些用户。他们应该足够清晰地识别用户群体，以便提案人能够识别这些用户，并阐明他们是如何被考虑的，或者对 PEP 进行修改以明确地考虑他们。（请注意，这不涉及评估该功能对不同用户群体的有用性，而仅仅是 PEP 是否表明该功能的有用性已被评估。）

如果提案似乎使用了错误的逻辑或不正确的数据得出了某个结论，CoA 可能会选择利用其他信息来源（例如先前的讨论或其他核心开发者的提交）来要求重新考虑某些观点。提案人不必一定使用 CoA 获取的确切信息来更新其提案，只要他们所做的任何修改都能让 CoA 满意。例如，PEP 可能表明 30% 的用户会受到影响，而 CoA 可能认为 70% 的用户会受到影响。成功的修改可能包括一个不同的但更可靠的百分比，或者可能被改写为不再依赖受影响用户的数量。

场景 4 - 委托决策的案例

某些提案可能需要专家在相关领域的审查和批准。历史上，这些将通过任命 BDFL-Delegate 来最终决定该提案。然而，在此模型中，CoA 不能委托最终决策过程。当 CoA 认为应由主题专家来决定某个提案时，CoA 可以任命一名或多名个人（或接受其自我提名）担任类似于 BDFL Delegate 的职位。这些专家的角色条款可由 CoA 自行决定，但 CoA 始终保留最终批准权。

作为具体例子，假设正在讨论一项关于新语言功能的新提案。支持者声称这将使新开发人员更容易学习该语言。即使在正式提案提出之前，CoA 也可能表明，除非 X 人批准，否则他们不会接受该提案，因为 X 人在 Python 教学方面有着悠久的历史，并且他们的判断受到信任。（请注意，X 人不必是核心开发者。）

获得此角色后，X 人能够引导讨论并迅速将其集中在可行的替代方案上。最终，X 人选择了他们最满意的替代方案，并向 CoA 表明他们已批准。提案将照常提交，CoA 将审查并接受它，同时考虑 X 人的意见。