etcd 社区成员体系详解Member、Reviewer 与 Maintainer 的权责、要求与晋升路径【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd本文基于 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 和 PRReviewer是质量门槛——其 LGTMLooks 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 邮件列表etcd-devgooglegroups.com已阅读 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 个实质性substantialPR熟悉代码库由两名活跃的 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 推荐并经超级多数选举通过推荐人必须来自不同成员公司申请流程向etcd-maintainers-privategooglegroups.com发送候选邮件确保邮件中 mention 了你的推荐人附上能代表你项目工作的贡献清单现有 Maintainer 会私下投票并通过邮件回复表示接受或给出改进建议获选后的入职动作清单一旦候选被批准新 Maintainer 需要完成一整套“入职”操作这些步骤在原文档中被逐项列出发起 PR在 OWNERS 文件中添加自己的 approver 条目申请加入etcd-maintainersgooglegroups.com与etcd-maintainers-privategooglegroups.com邮件列表申请加入 etcd-io GitHub 组织的 etcd maintainers 团队申请加入 etcd Maintainer 的私有 Slack 频道申请访问etcd-developmentGCP 项目发布发布的发布渠道申请获取 Maintainer 之间共享的密码通过向 projectscncf.io 邮件申请 CNCF service desk 权限提交 CNCF service desk 工单加入 cncf-etcd-maintainers 邮件列表这一清单说明 Maintainer 权限并不只是一个头衔而是与发布基础设施GCP 项目、密码管理、邮件列表、即时通讯频道等一系列具体访问权限绑定的。Maintainer 职责与权限做出并批准技术设计决策设定技术方向与优先级定义里程碑milestone与发布release辅导和指导 Reviewer 及贡献者在需要时参与安全披露与发布流程确保项目的持续健康有足够的测试覆盖率以支撑有信心的发布测试可靠通过即不 flaky失败时及时修复确保健康的讨论与决策流程存在与其他 Maintainer 协作从整体上维护项目的健康与成功退休机制Emeritus Maintainer生活重心与兴趣会变化Maintainer 可以退休并转为emeritus maintainer荣誉 Maintainer。文档对退出与降级给出了明确的程序化规则若某 Maintainer 需要卸任应告知其他 Maintainer并在可能的情况下帮助找到接手相关工作的候选人至少要确保相关工作能够继续若某 Maintainer12 个月未履行职责可被其他 Maintainer 移除被移除者会先收到邮件通知若情况没有改善则执行移除已退休的 emeritus maintainer 可以通过恢复贡献重新获得活跃角色活跃 Maintainer 应当欢迎这种回归移除其他 Maintainer 或恢复其地位都需要至少两名活跃 Maintainer 的批准退休的 Maintainer 必须完成以下收尾动作发起 PR在 OWNERS 文件中将自己移入 emeritus approvers 条目发起 PR 将自己从 etcd-io GitHub 组织的 maintainers 团队中移除移除自己对etcd-developmentGCP 项目的访问权限提交 CNCF service desk 工单取消自己在 cncf-etcd-maintainers 邮件列表中的 admin 身份申请从 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 spzalaus.ibm.com emeritus_approvers: - bdarnell - fanminshi - gyuho - hexfusion - heyitsanthony - jingyih - jpbetz - mitake - philips - ptabor - wenjiaswe - xiang90从中可以观察到三点approvers条目即 Maintainer 名单与文档中“Defined by:approversentry in the OWNERS file”完全一致值得注意的是etcd 的 approvers 不全是直接人名而是引用了sig-etcd-chairs与sig-etcd-tech-leads两个别名组——这正是因为 etcd 由 Kubernetes SIG-etcd 协同治理。别名在 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 提交也可以发送邮件到etcd-maintainersgooglegroups.com冲突解决技术分歧僵局时任何贡献者都可以开 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 贡献者的完整成长路径可以归纳为外部贡献者按 CONTRIBUTING.md 设置开发环境、找 issue、提交 PR至少一个 PR 合并Member满足双因素认证、多次贡献、订阅邮件列表、阅读贡献者指南、两名跨公司推荐后在 kubernetes/org 仓库发起提名 issue获批后加入 etcd-io GitHub 组织获得 triage 权限ReviewerMember 满 3 个月、主审 5 PR、审查/贡献 20 实质性 PR获两名 Maintainer 推荐后由 Maintainer 在 OWNERS 文件中加入 reviewers 条目Maintainer向私有 Maintainer 邮件列表发候选邮件经私下投票与超级多数选举通过后完成 OWNERS 文件 PR、GCP 项目访问、CNCF 邮件列表等一系列入职动作Emeritus退休后通过 PR 移入 OWNERS 文件的 emeritus approvers 条目并完成 GCP 访问、Slack、邮件列表等权限的清理这套体系的核心设计思路是角色身份与仓库中的文件OWNERS / OWNERS_ALIASES强绑定升降级全部通过 PR 走公开代码评审流程配合“跨公司推荐”“超级多数”“lazy consensus”等规则保证社区决策既透明又可追溯。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考