关键人物及其职能

审计委员会 (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 没有疑虑时，它将正式被接受。当一名或多名 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 代表来处理，由他们对提案做出最终决定。但是，在这个模型中，CoA 可能不会委托最终的决策过程。当 CoA 认为主题专家应该决定一项特定提案时，CoA 可以提名一个或多个人（或接受他们自荐）担任类似于 BDFL 代表的职位。这些专家的角色条款可以由 CoA 视情况而定，但 CoA 始终保留最终批准权。

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

在被赋予这一角色后，X 人能够推动讨论，并迅速将其集中在可行的替代方案上。最终，X 人选择他们最满意的替代方案，并向 CoA 表明他们批准。该提案像往常一样提交，CoA 在考虑 X 人的意见后，进行审查并接受它。