etcd PR 管理与评审策略：从测试触发、标签核验到双审合并的完整实践指南

本文基于 etcd 仓库官方贡献者文档 PR management，系统讲解 etcd 项目的 PR 管理（triage）流程：如何触发 CI 测试、如何跟进无响应的 PR 与评审人、如何核验关键标签，以及决定 PR 能否合并的评审策略。读完后你可以完整掌握 etcd 维护者/活跃贡献者管理一个 PR 从进入评审到合并（或被关闭）的全生命周期操作，并能定位仓库中定义评审人、模块 owner 与里程碑的具体文件。

PR 管理的目标与适用范围

etcd 项目通过标准化的 PR 管理流程来"加速 PR 流转"（原文 Purpose 一节即明确 Speed up PR management）。每一个 PR 都可以拥有多种 labels、milestones、reviewers 等属性，其中 labels 体系与 Kubernetes 项目对齐，可按 area、type、priority 等维度检索和归类。

文档给出的典型检索入口（在 etcd 仓库的 Pull Requests 列表中按条件过滤即可复现）：

• 按里程碑过滤：例如查看里程碑为 etcd-v3.6 的所有 Open PRs；
• 按标签过滤：例如查看所有标记为 Investigating（调查中）的 PRs。

文档同时明确了适用范围（Scope）：这份指南是 etcd 中管理 PR 和评审政策的首要参考文档。任何人都可以帮忙管理 PR，但文档中讨论的工作与职责主要是面向 etcd 维护者（maintainers）和活跃贡献者设计的。

确保测试已运行：/ok-to-test 与 Prow 机制

etcd 使用 Kubernetes Prow 和 GitHub Actions 来运行测试。当一个 PR 已经准备好接受测试、但仍带有 needs-ok-to-test 标签时，应在该 PR 下评论 /ok-to-test 来放行测试。

要理解这条规则，需要结合仓库内 Prow 作业说明：

• Prow 是基于 Kubernetes 的 CI/CD 系统，通过 PR 评论中的 /command 与 GitHub 交互（如 /test、/approve、/retest）；
• /ok-to-test 的作用是允许 Prow 在首次贡献者（first-time contributor）提交的 PR 上运行测试——因为外部 PR 无法访问受保护的 CI 资源，必须由 etcd-io 组织成员触发放行；
• /retest 则用于重跑之前因瞬时问题失败或 flaky 的作业；
• etcd 的作业类型包括 presubmits（合并前，如 pull-etcd-e2e-amd64 会在每个 PR 上运行 e2e 测试）、postsubmits、periodics（定时跑性能基准与稳定性检查）等。

因此"确保测试已运行"这一 triage 动作的实际含义是：检查 PR 上的 CI 是否因 needs-ok-to-test 而未真正跑过，若是，则由具备组织成员身份的 triage 者补发 /ok-to-test 评论，让完整测试矩阵（静态检查、单元、集成、e2e 等）覆盖到该 PR。

处理无响应的 PR：15 / 90 / 180 天规则

原文给出了一条清晰的"不活跃 PR 处理阶梯"，这是 etcd 保持 PR 队列新鲜度的核心机制：

阶段	时间条件	动作
催促作者	评审意见提出后 15 天未处理	向 PR 作者提醒（poke），请其回应评审意见
代为推进	作者 90 天未回复	在可行的情况下由维护者更新 PR（追加新 commit），使其保持可评审状态
关闭	仍不活跃	在 180 天后关闭该 PR

这条规则与仓库内 Issue 分诊指南 中"issue 报告者 30 天不回复则关闭"的机制形成对照：PR 的容忍周期更长（因为作者可能已投入较多工作量，维护者甚至愿意代为修复），而 issue 的容忍周期更短。

跟进评审人：10 天响应窗口

文档承认评审人通常响应及时，但"人人都有忙的时候"，因此给出如下约定：

• 请求评审后，若未获得快速响应，应先给予一定宽限时间；
• 若 10 天后仍未得到响应，可以通过三种方式联系评审人：
  1. 在 PR 中追加评论 @ 对方；
  2. 发送电子邮件；
  3. 在 Slack 上发消息。

那么"评审人"具体是谁？这由仓库中的 OWNERS 体系定义，见下一节。

核验关键标签：评审人、里程碑与 OWNERS 体系

triage 时需要确认两类"重要标签"是否到位：适当的 reviewers 已加入 PR，以及 milestone 已被标识。若缺失则补上；若无法判断正确的标签归属，应留评论请维护者处理。

里程碑（milestone）与发布线

etcd 按版本分支组织开发。仓库中 CHANGELOG 目录保留了 2.3 至 4.0 各版本的变更日志，可推断当前维护的主线/发布线包含 release-3.6 等分支（这与 Prow 说明 中 presubmit 作业覆盖 main、release-3.6、release-3.5、release-3.4 分支的描述一致）。因此 milestone 标识（如 etcd-v3.6）直接决定一个 PR 被纳入哪个发布里程碑，缺失 milestone 的 PR 会在版本规划中"隐身"，必须补全。

评审人从哪来：OWNERS / OWNERS_ALIASES

"submodule owner"（模块 owner）是评审策略中的关键角色，仓库内用 Kubernetes 风格的 OWNERS 文件来定义：

• 仓库根目录 OWNERS 定义了项目级 approvers（即维护者），包括 sig-etcd-chairs、sig-etcd-tech-leads 两个别名组及具名成员，同时保留了一份 emeritus_approvers（退休维护者）名单；
• OWNERS_ALIASES 定义了别名组成员：sig-etcd-chairs（SIG 主席）与 sig-etcd-tech-leads（技术负责人）各三人；
• 子目录拥有各自的 OWNERS 文件，例如 tests/OWNERS 声明 area/testing 标签、client/v3/OWNERS 声明 area/clientv3 标签、scripts/OWNERS 与 tools/rw-heatmaps/OWNERS 则分别列出具名 approver。

这些文件中的 approver 即为文档评审策略里说的"maintainer, reviewer, or submodule owner"。子模块 OWNERS 文件的 labels 字段还把目录与 area 标签绑定，使"给 PR 打 area 标签"与"找对应模块的 owner 评审"可以一一对应。

角色定义参考

"maintainer / reviewer / member"三类角色的具体职责与晋升条件，仓库在 社区成员资格文档 中有完整定义：reviewer 由 OWNERS 文件的 reviewers 条目定义、其 LGTM 计入合并条件；maintainer 由 OWNERS 的 approvers 条目定义、负责设定技术方向与里程碑。triage 人员在判断"该 PR 该找谁评审、谁有资格给出有效 approval"时，应以该文档与 OWNERS 文件为准。

评审策略：默认双审，低风险放宽

为"确保代码质量与共同所有权"（shared ownership），etcd 的评审策略适用于所有 PR，分为默认规则与例外两类。

默认规则：至少两个 approval

PR 在合并前应获得至少两个 approval（/lgtm 评论或 GitHub review approval）。

两条补充约束：

1. 审批人资格：approval 必须来自熟悉相关代码或领域的 maintainer、reviewer 或 submodule owner——即前文 OWNERS 体系定义的三类人，随意给出的 approval 不计入；
2. 分歧处理：若评审人之间存在分歧，维护者应当先讨论并达成一致，再执行合并。

例外：低风险 PR 可放宽为单审

对于影响面小的变更，规则可以放宽——一个 approval 通常就够。文档列举的低风险类别包括：

• CI 工作流变更（CI workflows）；
• 文档（Documentation）；
• 注释（Comments）。

但有一条硬性兜底：即使作者本人就是 maintainer，即使是上述小改动，也必须再获得另一位 maintainer、reviewer 或 submodule owner 的 approval。这防止了"自己改自己的代码自己合并"的路径，保证任何变更至少经过一双"额外的眼睛"。

这一策略与 Issue 分诊指南 中 type/area/priority 标签的判定逻辑互补：issue 侧用标签确定问题属性，PR 侧则用双审规则 + owner 体系确定质量门槛。

实践小结：一个 etcd PR 的 triage 检查清单

综合全文，维护者对一个待合并 PR 的例行检查可以整理为一张清单：

1. 测试：CI 是否完整跑过？外部 PR 是否还挂着 needs-ok-to-test？需要时以组织成员身份评论 /ok-to-test（机制见 Prow 说明）；
2. 活跃度：评审意见是否 15 天无人处理？作者是否已 90 天失联（可代为更新 PR）？是否已满 180 天（应关闭）？
3. 评审人：是否已 @ 对应模块的 reviewer/owner？10 天无响应则通过评论、邮件或 Slack 跟进。模块归属可查目录级 OWNERS 文件（如 tests/OWNERS、client/v3/OWNERS）；
4. 标签：milestone 是否设置？area 等标签是否与变更目录对应的 OWNERS labels 一致？无法判断时留评论交维护者；
5. 审批数：默认凑齐 2 个来自 maintainer/reviewer/submodule owner 的 approval；CI、文档、注释类变更可放宽为 1 个，但 maintainer 自提的 PR 无论如何都需他人审批；存在分歧时先由维护者对齐再合并。

以上流程全部出自仓库官方贡献者文档 triage_prs.md，其中角色定义、CI 机制与 OWNERS 文件均为仓库内可直接核验的事实来源。