etcd 社区成员体系详解：Member、Reviewer 与 Maintainer 的权责、要求与晋升路径

本文基于 etcd 仓库中的 社区成员文档，系统梳理 etcd 项目三级贡献者角色（Member、Reviewer、Maintainer）的职责划分、准入要求、选举流程与退出机制，并结合仓库根目录的 OWNERS、OWNERS_ALIASES 与 GOVERNANCE.md 等文件，说明这些角色在代码仓库中是如何被实际定义和执行的。读完本文，你将了解从第一次提交 PR 到成为 Maintainer 的完整成长路径、每一级的硬性门槛，以及角色升降级的具体操作步骤。

三级社区角色总览

etcd 通过一套清晰的角色体系来组织社区贡献者。原始文档以一张表格总览三级角色的核心差异：

角色	职责	要求	定义方式
Member	社区中的活跃贡献者	由 2 名 Reviewer 推荐，且有多次贡献记录	etcd GitHub 组织成员
Reviewer	审查其他成员的贡献	有审查和提交的贡献历史	OWNERS 文件中的 reviewer 条目
Maintainer	制定项目方向与优先级	表现出责任感与出色的技术判断力	OWNERS 文件中的 approver 条目

从表格可以提炼出一条清晰的递进关系：

• Member 是身份门槛——加入 etcd GitHub 组织即获得 triage 权限，可以被分配 issue 和 PR；
• Reviewer 是质量门槛——其 LGTM（Looks Good To Me）计入了代码变更能否合并的决策；
• Maintainer 是决策门槛——由 OWNERS 文件的 approvers 条目定义，掌握技术方向、里程碑与发布的决策权。

值得注意的是一条隐含路径：文档明确指出，经常贡献代码的 Member 被期望主动进行代码审查，并朝着 Reviewer 方向发展。也就是说，Member → Reviewer → Maintainer 构成了一条事实上的“成长阶梯”，Reviewer 一般被视为通往 Maintainer 的阶梯（on the ladder towards maintainership）。

新贡献者的接入

文档对社区的新人接入提出了明确的期望：现有成员应当欢迎新贡献者进入社区，帮助他们熟悉 PR 工作流，并将他们引导至相关的文档与沟通渠道。这与 CONTRIBUTING.md 中的贡献者工作流相呼应——新贡献者可以从 Find something to work on 一节开始，按 good first issue、help wanted、priority/important 标签选择适合自己水平的任务。

已成型的社区成员（Established community members）则被期望展示对本文档所列原则的遵循、对项目组织结构/角色/政策/流程/惯例的熟悉，以及技术或写作能力。

Member：活跃贡献者的定义、要求与职责

Member 被定义为对社区持续活跃的贡献者：issue 和 PR 可以被分配给他们，且他们被期望保持活跃。

定义方式：etcd GitHub 组织（etcd-io organization）成员。

Member 准入要求

• GitHub 账户已启用双因素认证（two-factor authentication）
• 对项目或社区有多次贡献，贡献形式包括但不限于：
  • 在 GitHub 上创建或审查 PR，且至少一个 PR 必须已合并（merged）
  • 在 GitHub 上提交或评论 issue
  • 参与社区讨论（例如会议、Slack、邮件讨论组、Stack Overflow）
• 已订阅 etcd-dev 邮件列表（[e-mail]）
• 已阅读 contributor guide
• 由两名活跃的 Maintainer 或 Reviewer 推荐（sponsored）：
  • 推荐人必须来自不同的成员公司，以体现社区跨公司整合
  • 且其他 Maintainer 无异议
• 在 kubernetes/org 仓库上发起一个 membership nomination（成员提名）issue：
  • 确保 issue 中 @mention 了你的推荐人
  • 确保列出的贡献清单能够代表你在项目上的实际工作
• Member 可以被 Maintainer 的**超级多数（supermajority）**移除，也可以通过通知 Maintainer 主动辞职

其中“在 kubernetes/org 仓库发起提名 issue”体现了 etcd 成员管理的实际落地方式：由于 etcd 是 CNCF 项目且由 Kubernetes SIG-etcd 协作维护，成员身份的申请走的是 Kubernetes 组织的标准成员提名模板，而非 etcd 仓库内部的流程。

Member 职责与权限

• 对分配给自己的 issue 和 PR 保持响应
• 获得 etcd 项目的 "triage access"（问题分诊权限）
• 成为其所贡献代码的活跃 owner（除非所有权被显式移交）：
  • 代码有充分的测试
  • 测试持续通过
  • 在代码被接受后发现的 bug 或问题得到处理

注意：频繁贡献代码的 Member 被期望主动执行代码审查，并朝着 Reviewer 角色努力。

Reviewer：代码质量的守门人

Reviewer 是在审查他人代码方面展现出更高能力的贡献者，既熟悉代码库也熟悉软件工程原则。其 LGTM 计入代码变更合并的决策。

定义方式：OWNERS 文件中的 reviewers 条目。

Reviewer 准入要求

• 成为 Member 至少 3 个月
• 作为主 Reviewer 审查过至少 5 个 PR
• 审查或贡献过至少 20 个实质性（substantial）PR
• 熟悉代码库
• 由两名活跃的 Maintainer 推荐：
  • 推荐人必须来自不同成员公司
  • 且其他 Maintainer 无异议
• Reviewer 可以被 Maintainer 的超级多数移除，也可以主动辞职

Reviewer 职责与权限

• 代码审查者身份可能是接受大型代码贡献的前置条件
• 通过代码审查负责项目质量控制：
  • 聚焦代码质量与正确性，包括测试与代码结构（factoring）
  • 也可以审查更全局性的问题，但非强制要求
• 期望对审查请求保持响应
• 被分配与其专业领域相关的待审查 PR
• 被分配与其专业领域相关的测试 bug
• 获得 etcd 项目的 "triage access"

这与 CONTRIBUTING.md 中的 PR 审查流程形成闭环：所有 GitHub 与 Prow 检查通过后，贡献者可以向参与过原始讨论的人或 Maintainer 请求审查；根据 PR 复杂度，合并前可能需要 1 到 2 名 Maintainer 批准。而 Reviewer 的 LGTM 正是这一批准链条中的关键信号。

Maintainer：方向制定者与最高责任层

Maintainer 首先是贡献者，并且已经证明其致力于项目的长期成功。Maintainer 身份的本质是与现有 Maintainer 建立信任——成为一个可以被依赖、能够一贯地以项目最佳利益做出决策的人。

定义方式：OWNERS 文件中的 approvers 条目。

Maintainer 准入要求

• 对项目技术目标与方向的深刻理解
• 对项目技术领域的深刻理解
• 通过全部以下方式为项目的设计与方向做出持续贡献：
  • 创建并审查提案（proposal）
  • 发起、参与并推动解决各类讨论（邮件、GitHub issue、会议）
  • 在 PR 的设计与实现中识别出微妙或复杂的问题
• 通过实现和/或审查直接贡献于项目
• 由两名活跃的 Maintainer 推荐，并经超级多数选举通过
  • 推荐人必须来自不同成员公司
• 申请流程：向 [e-mail] 发送候选邮件：
  • 确保邮件中 @mention 了你的推荐人
  • 附上能代表你项目工作的贡献清单
  • 现有 Maintainer 会私下投票，并通过邮件回复表示接受或给出改进建议

获选后的入职动作清单

一旦候选被批准，新 Maintainer 需要完成一整套“入职”操作，这些步骤在原文档中被逐项列出：

1. 发起 PR，在 OWNERS 文件中添加自己的 approver 条目
2. 申请加入 [e-mail] 与 [e-mail] 邮件列表
3. 申请加入 etcd-io GitHub 组织的 etcd maintainers 团队
4. 申请加入 etcd Maintainer 的私有 Slack 频道
5. 申请访问 etcd-development GCP 项目（发布发布的发布渠道）
6. 申请获取 Maintainer 之间共享的密码
7. 通过向 [e-mail] 邮件申请 CNCF service desk 权限
8. 提交 CNCF service desk 工单，加入 cncf-etcd-maintainers 邮件列表

这一清单说明 Maintainer 权限并不只是一个头衔，而是与发布基础设施（GCP 项目）、密码管理、邮件列表、即时通讯频道等一系列具体访问权限绑定的。

Maintainer 职责与权限

• 做出并批准技术设计决策
• 设定技术方向与优先级
• 定义里程碑（milestone）与发布（release）
• 辅导和指导 Reviewer 及贡献者
• 在需要时参与安全披露与发布流程
• 确保项目的持续健康：
  • 有足够的测试覆盖率以支撑有信心的发布
  • 测试可靠通过（即不 flaky），失败时及时修复
• 确保健康的讨论与决策流程存在
• 与其他 Maintainer 协作，从整体上维护项目的健康与成功

退休机制：Emeritus Maintainer

生活重心与兴趣会变化，Maintainer 可以退休并转为 emeritus maintainer（荣誉 Maintainer）。文档对退出与降级给出了明确的程序化规则：

• 若某 Maintainer 需要卸任，应告知其他 Maintainer，并在可能的情况下帮助找到接手相关工作的候选人，至少要确保相关工作能够继续
• 若某 Maintainer 12 个月未履行职责，可被其他 Maintainer 移除：
  • 被移除者会先收到邮件通知；若情况没有改善，则执行移除
• 已退休的 emeritus maintainer 可以通过恢复贡献重新获得活跃角色，活跃 Maintainer 应当欢迎这种回归
• 移除其他 Maintainer 或恢复其地位，都需要至少两名活跃 Maintainer 的批准

退休的 Maintainer 必须完成以下收尾动作：

1. 发起 PR，在 OWNERS 文件中将自己移入 emeritus approvers 条目
2. 发起 PR 将自己从 etcd-io GitHub 组织的 maintainers 团队中移除
3. 移除自己对 etcd-development GCP 项目的访问权限
4. 提交 CNCF service desk 工单，取消自己在 cncf-etcd-maintainers 邮件列表中的 admin 身份
5. 申请从 etcd-maintainers 与 etcd-maintainers-private 两个 Google 组中移除

仓库证据：OWNERS 文件中的角色落地

社区文档描述的角色体系，最终都落在仓库根目录的 OWNERS 文件上。当前仓库的 OWNERS 文件内容印证了文档中的定义方式：

# See the OWNERS docs at https://go.k8s.io/owners

approvers:
  - sig-etcd-chairs     # Defined in OWNERS_ALIASES
  - sig-etcd-tech-leads # Defined in OWNERS_ALIASES
  - spzala              # Sahdev Zala <[e-mail]>
emeritus_approvers:
  - bdarnell
  - fanminshi
  - gyuho
  - hexfusion
  - heyitsanthony
  - jingyih
  - jpbetz
  - mitake
  - philips
  - ptabor
  - wenjiaswe
  - xiang90

从中可以观察到三点：

1. approvers 条目即 Maintainer 名单，与文档中“Defined by: approvers entry in the OWNERS file”完全一致；值得注意的是，etcd 的 approvers 不全是直接人名，而是引用了 sig-etcd-chairs 与 sig-etcd-tech-leads 两个别名组——这正是因为 etcd 由 Kubernetes SIG-etcd 协同治理。
2. 别名在 OWNERS_ALIASES 中展开：

aliases:
  sig-etcd-chairs:
    - ivanvc
    - jmhbnz
    - siyuanfoundation
  sig-etcd-tech-leads:
    - ahrtr
    - fuweid
    - serathius

也就是说，当前的活跃 approver 实际由两个别名的成员加上一名直接列出的成员构成。 3. emeritus_approvers 条目对应文档中的退休机制：文档要求退休的 Maintainer “Open a PR and move to emeritus approvers in the OWNERS file”，而当前 OWNERS 文件中确实存在 12 位 emeritus approver 的历史名单，这与 README.md 中的 "etcd Emeritus Maintainers" 章节相互印证——该章节说明这些荣誉 Maintainer 曾长期审查代码、分诊 bug 并推动项目前进。

与治理文档的衔接：决策与冲突解决

GOVERNANCE.md 明确了角色体系在治理中的位置：“Etcd project roles along with their requirements and responsibilities are defined in community membership”，即本社区成员文档就是角色体系的权威来源。与之配套的治理机制包括：

• 决策机制：决策建立在 Maintainer 之间的公开共识之上；提案与想法可以通过 GitHub issue 或 PR 提交，也可以发送邮件到 [e-mail]
• 冲突解决：技术分歧僵局时，任何贡献者都可以开 issue/PR 或发邮件到 Maintainer 列表；若 Maintainer 之间无法决断，则由 Maintainer 超级多数（supermajority）决定，并存在“lazy consensus”兜底——在 3 个工作周的投票不活跃期后，只要有 2 名 Maintainer 同意即可通过
• 治理变更：项目治理的变更可以通过发起 GitHub PR 启动

这里的“超级多数”“lazy consensus”等术语与社区成员文档中“Member/Reviewer can be removed by a supermajority of the maintainers”相互呼应，构成了从角色准入、角色退出到日常决策的完整规则闭环。

成长路径小结

综合原文档与仓库文件，etcd 贡献者的完整成长路径可以归纳为：

1. 外部贡献者：按 CONTRIBUTING.md 设置开发环境、找 issue、提交 PR（至少一个 PR 合并）
2. Member：满足双因素认证、多次贡献、订阅邮件列表、阅读贡献者指南、两名跨公司推荐后，在 kubernetes/org 仓库发起提名 issue，获批后加入 etcd-io GitHub 组织，获得 triage 权限
3. Reviewer：Member 满 3 个月、主审 5+ PR、审查/贡献 20+ 实质性 PR，获两名 Maintainer 推荐后，由 Maintainer 在 OWNERS 文件中加入 reviewers 条目
4. Maintainer：向私有 Maintainer 邮件列表发候选邮件，经私下投票与超级多数选举通过后，完成 OWNERS 文件 PR、GCP 项目访问、CNCF 邮件列表等一系列入职动作
5. Emeritus：退休后通过 PR 移入 OWNERS 文件的 emeritus approvers 条目，并完成 GCP 访问、Slack、邮件列表等权限的清理

这套体系的核心设计思路是：角色身份与仓库中的文件（OWNERS / OWNERS_ALIASES）强绑定，升降级全部通过 PR 走公开代码评审流程，配合“跨公司推荐”“超级多数”“lazy consensus”等规则，保证社区决策既透明又可追溯。