企业官网建设流程全解析

• 云原生
• 后端
• 前端
• 运维
• 可观测性
• 开发工具

Octant 是一个面向 Kubernetes 开发者的高度可扩展可视化平台，其社区治理遵循一份专门的成员制度文档（COMMUNITY_MEMBERSHIP.md）。本篇指南以该文档为骨架，系统讲解 Octant 当前唯一的社区角色——Approver（审批人）的职责边界、硬性准入门槛、完整的申请操作流程，以及长期不活跃成员的退出机制；同时结合仓库内真实的 CONTRIBUTING.md、approver 申请 Issue 模板 与 OWNERS 权限清单，帮助你理解并走通从普通贡献者到社区审批人的全路径。

Octant 社区成员体系：当前仅设 Approver 一种角色

Octant 的成员制度借鉴了 Kubernetes 社区的成员治理模型（该文档在开篇即声明其依据为 Kubernetes Community Membership 规范），但做了明显的简化：目前项目只设一个角色——approver，未来可能随社区规模增长而扩展更多角色。

这一表格是整个成员制度的浓缩：角色数量少、职责清晰、准入严格。文档 COMMUNITY_MEMBERSHIP.md 第 9～11 行即给出了该表，后续所有章节都是对这张表中"要求"与"定义方式"的展开说明。

从仓库结构可以印证这一"单一角色"设计的实际落地：根目录的 OWNERS 文件中，approvers一节列出了 7 位审批人（bryanl、GuessWhoSamFoo、lenriquez、mklanjsek、scothis、xtreme-vikram-yadav、wwitzel3），emeritus_approvers一节则登记了 4 位已转荣誉身份的成员。这与文档描述的"目前只有一种角色"完全一致——approver 是社区内唯一的正式成员身份，其余人统称为"贡献者"。

新贡献者的进入与引导

文档 COMMUNITY_MEMBERSHIP.md 专门开辟了 "New contributors" 一节，明确社区对新人采取"欢迎而非设限"的姿态：

• 现有成员应主动欢迎新贡献者进入社区；
• 帮助新人熟悉 PR（Pull Request）工作流；
• 引导新人阅读相关文档并接入沟通渠道。

这与 CONTRIBUTING.md 描述的沟通文化一脉相承：项目优先采用异步沟通（issue、邮件组 project-octant、GitHub Discussions），同时设有每周社区例会，并鼓励将同步讨论的结论回写到 issue 中，保证跨时区成员都能检索到信息。新贡献者可以据此快速找到协作入口，再逐步积累贡献记录。

成熟社区成员（Established Community Members）的通用标准

在进入 Approver 专属章节之前，文档先给出了一层"通用前置标准"——任何人想成为成熟社区成员，都应体现出：

• 对本文档所述原则的遵循；
• 对项目组织方式、角色体系、政策、流程和约定的熟悉；
• 一定的技术能力和/或写作能力。

这层标准相当于"准入门槛之上的底色要求"：Approver 不仅要有代码能力，还要理解社区如何运转，能够在评审中维护项目长期约定。随后的 Approver 准入要求都是在这一底色之上的具体量化指标。

Approver 角色详解：评审与批准的分工

文档对 approver 的核心职能做了明确区分：

• Code review（代码评审）：聚焦代码质量与正确性，包括测试和代码结构（factoring）；
• Approval（批准）：聚焦对贡献的"整体性接纳"（holistic acceptance），评审视野更宽，需要考量：
  • 向后 / 向前兼容性（backwards / forwards compatibility）；
  • 是否符合 API 与命令行参数（flag）约定；
  • 潜在的性能与正确性问题；
  • 与系统其他部分的交互影响。

定义方式：获得 Octant 仓库的 commit access（提交权限）。

重要约束：代码贡献的合入必须至少获得一名 approver 的批准（Acceptance of code contributions requires at least one approver）。也就是说，approver 既是质量的守门人，也是代码合入流程中不可绕过的环节。

从源码看，Octant 的 CI 与 PR 流程也确实围绕"review + approve"运转：仓库 .github/workflows 下配置了 lint、nightly、preflight-checks、verify-generated 等工作流，.github/PULL_REQUEST_TEMPLATE.md 要求 PR 说明改动目的、关联 issue 与 release note——这些都构成了 approver 评审时的具体检查对象。

成为 Approver 的量化准入要求

文档 COMMUNITY_MEMBERSHIP.md 在 "Requirements" 一节给出了硬性门槛，逐条如下：

1. 开启双重认证（2FA）：GitHub 账号必须启用 two-factor authentication。
2. 对 Octant 有多项贡献，具体贡献内容必须包含：
   • 在 GitHub 上至少撰写 3 个 PR；
   • 对至少 4 个非自己撰写的 PR提供过评审意见；
   • 在 GitHub 上提交（filing）或评论过 issue。
3. 阅读贡献者指南：CONTRIBUTING.md。
4. 由 2 名 approver 提名赞助，赞助人还有附加要求：
   • 赞助人与候选人必须有密切互动——例如参与代码 / 设计 / 提案评审、协调 issue 等；
   • 若当前活跃 approver 中有至少 3 人来自非 VMware 公司，则必须有一名赞助人来自非 VMware 公司，以体现跨社区的融合（从 OWNERS 可以看到项目既有 VMware 背景成员也有其他公司成员，这一条正是为保持社区多元治理而设）。
5. 在 Octant 仓库中开启一个申请 issue：
   • 确保两位赞助人在 issue 中被 @mention；
   • 完成模板清单上的每一项（.github/ISSUE_TEMPLATE/become-an-octant-approver.md 即为当前版本的清单模板）；
   • 确保列出的贡献清单能代表你在项目中的实际工作。
6. 等待赞助 approver 回复确认赞助：回复内容为+1。

申请模板清单的落地形态

文档所引用的申请清单在仓库中真实存在：.github/ISSUE_TEMPLATE/become-an-octant-approver.md。该模板是一个 GitHub Issue 模板，元数据部分设置了：

• 标题：Approver Request
• 标签：community
• 默认负责人（assignees）：wwitzel3

模板正文要求申请人逐项勾选确认，包括：已阅读贡献者指南、已启用 2FA、已加入 Kubernetes Slack 工作区与 #octant 频道、正在积极贡献、已有两名符合赞助要求的赞助人、且已提前与赞助人沟通并获其同意；随后填写赞助人 GitHub 账号，并列出自己对项目的贡献（撰写的 PR、评审过的 PR、响应过的 issue）。这张清单与 COMMUNITY_MEMBERSHIP.md 中的准入要求逐条对应，申请时可直接复制使用。

需要说明的是：文档中写到的templates/membership.md路径在当前仓库中未检索到对应文件，实际可用的申请清单以 .github/ISSUE_TEMPLATE/become-an-octant-approver.md 为准。

成为 Approver 后的责任与特权

获批成为 approver 之后，你将承担如下职责、获得相应特权（文档 "Responsibilities and privileges" 一节）：

• 负责项目质量控制：通过代码评审把关代码质量与正确性，包括测试和代码结构；也可以对更整体性的问题提出评审意见，但这不是强制要求；
• 对评审请求及时响应：被期待在合理时间内响应评审请求；
• 按专长被指派评审 PR：项目会根据 approver 的 expertise 分配相关 PR 供其评审；
• 获得 Octant 仓库的提交权限：这是 approver 身份最直接的落地形式。

对照仓库实际文件：提交权限的授予在 OWNERS 的approvers列表中体现；而"按专长指派评审"与"及时响应"则与 CONTRIBUTING.md 描述的评审节奏呼应——该指南要求新 PR 的评审目标在一个工作日内启动，以避免 PR 长期 stale，并鼓励大型改动拆分为更小的提交或多个 PR 以加快评审循环。

活跃度治理：12 个月不活跃即转入荣誉名单

文档专门设置了 "Inactivity" 一节，规定：

若某 approver 连续 12 个月不活跃，将被从 approver 名单中移除，并加入 emeritus approvers（荣誉审批人）名单。

这是一条温和但明确的治理规则：权限与活跃度挂钩，避免"占位不干活"的僵尸审批人长期持有提交权限。

该机制同样在仓库中有据可查：OWNERS 文件中的emeritus_approvers列表登记了 ipsi、mdaverde、nanaasiedu、shomron 四位成员；站点内容目录 site/content/emeritus 也为荣誉成员保留了独立页面（如 01-andrew-thorburn、02-mdaverde、03-nana-asiedu-ampem、04-oren-shomron），与 site/content/contributors 下的现任贡献者页面并列展示。从这套文件结构可以推断：emeritus 是对资深成员贡献的历史性认可，其本人不再承担 approver 的评审与审批职责，但身份与贡献仍被社区记录。

与贡献者指南的衔接：申请前的日常积累

Approver 的准入并非"一步到位"，而是长期贡献的自然结果。CONTRIBUTING.md 描述了几项申请 Approver 前就应养成的日常习惯，它们恰好对应 COMMUNITY_MEMBERSHIP.md 中的量化要求：

• DCO 签署：所有提交需在 commit message 末尾附带Signed-off-by: <姓名> <邮箱>行（可用git commit --signoff自动添加），确保贡献者有权利提交这些代码——这是"撰写 PR"的合规前提；
• CHANGELOG 文件：每个 PR 都应在 changelogs/unreleased 目录新增按pr-username命名的变更记录文件——这是 PR 评审的组成部分；
• 评审文化：指南鼓励成员相互评审（reviews for a new pull request are targeted within one business day），为满足"评审至少 4 个非本人 PR"的要求提供了日常场景；
• 提案流程：较大功能或重构建议以proposals/YYYYMMDD-title.md形式提交 PR 讨论——这类设计评审正是"与赞助人密切互动"的典型形式。

申请流程速查清单

综合 COMMUNITY_MEMBERSHIP.md 与 .github/ISSUE_TEMPLATE/become-an-octant-approver.md，一位贡献者从"想成为 approver"到"正式获批"的完整步骤如下：

1. 积累贡献：至少撰写 3 个 PR、评审至少 4 个非本人 PR、持续提交/评论 issue；
2. 开启 2FA：在 GitHub 账号启用双重认证；
3. 阅读指南：通读 CONTRIBUTING.md；
4. 确认赞助人：与两位 approver 提前沟通并获得同意，确保赞助人符合"密切互动"要求，必要时满足"非 VMware 赞助人"条款；
5. 发起申请：使用 .github/ISSUE_TEMPLATE/become-an-octant-approver.md 模板在仓库开启 Approver Request issue，勾选全部清单项，@mention 两位赞助人，附上代表性贡献清单；
6. 等待确认：赞助 approver 在 issue 中回复+1确认赞助；
7. 获批：获得 commit access，成为 OWNERSapprovers列表中的一员，开始履行评审与批准职责。

获批之后仍需保持活跃：若连续 12 个月不参与社区活动，将被移入 OWNERS 的emeritus_approvers名单，成为受社区铭记的荣誉成员。

• 云原生
• 后端
• 前端
• 运维
• 可观测性
• 开发工具