企业官网建设流程全解析

Kubernetes Code of Conduct 委员会成员交接指南：Onboarding 与 Offboarding 全流程详解

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

Kubernetes Code of Conduct Committee（CoCC，行为准则委员会）是负责维护与执行 Kubernetes 社区行为准则的专门机构，其成员的任期轮换（Incoming）与离任（Outgoing）交接，直接关系到委员会在 Slack、邮件列表、Google Drive、GitHub 组织等多个平台的权限是否连续、安全与合规。本文以 onboarding-offboarding.md 为核心，结合本仓库中的 sigs.yaml、OWNERS_ALIASES、charter.md 与 election.md 等源码与治理文档，系统拆解 CoCC 成员交接中每一项权限、通讯与知识转移动作，读者可据此直接编排一次完整的成员交接。

交接机制概览：三类成员的分工

交接不是某一个成员的独角戏，文档明确将参与成员划分为三类，并规定每类成员负责的动作边界：

这一设计的核心考量在于权限最小化与责任隔离：离任成员自己动手退出 Slack（避免留任成员遗漏其私人会话），留任成员负责 GitHub/Google 侧的增删（保证权限变更由仍在任、仍具治理上下文的人执行），而对外宣布交接结果的动作则"任何人都可以执行，唯独离任成员不可以"（防止离任成员在过渡期对外表态带来歧义）。这背后与 charter.md 中"委员会努力平衡流程透明度与涉事个体隐私"的宗旨一脉相承。

权限交接（Permissions）

交接的第一大块是权限的迁移，分为 Slack 频道成员与 Kubernetes/Google 权限两类，下面逐一展开。

Slack 频道成员交接

执行人：Offboarding 时由 Outgoing members 自行将自己移出频道；Onboarding 时由 Carryover members 将 Incoming members 加入。

需要维护的频道共三组：

• kubernetes.slack.com上行为准则委员会的公开与私密频道
• kubernetes.slack.com上的#kubernetes-moderators与#slack-reports私密频道
• cloud-native.slack.com上的 Code of Conduct sync 同步频道

其中#kubernetes-moderators与#slack-reports属于社区审核与举报处理的敏感通道，离任成员退出这些通道意味着其对历史举报信息访问权的终止；同时 incident-process.md 提到委员会维护"triage rotation schedule（至少两人盯守来报事件）"，因此留任成员必须确保新任成员在交接完成前已具备这些频道的访问能力，避免出现无人值守的空窗期。Slack 侧权限的实现在仓库中亦有对应配置：communication/slack-config/下的channels.yaml、usergroups.yaml与各 SIG 子目录共同描述了 Slack 频道的组织方式，可作为了解频道治理结构的参考。

Kubernetes/community 与 Google 权限

执行人：Carryover members 负责确保 Outgoing members 被移除、Incoming members 被邀请。

这一部分涉及四个仓库/配置文件的更新，是交接中技术性最强、最容易被遗漏的环节：

• 更新kubernetes/community仓库的sigs.yaml
• 更新kubernetes/k8s.io仓库：
  • OWNERS_ALIASES
  • groups.yaml（位于groups/committee-code-of-conduct/路径下）

    注意：该文件控制邮件列表与 Google Drive 的访问权限！若未更新此文件，通过界面手工添加成员的操作会被持续回滚，直至该文件被更新。

    • conduct@kubernetes.io邮件列表
    • Google Drive
• 更新kubernetes/org仓库：
  • OWNERS_ALIASES
  • config/kubernetes/org.yaml

其中两个细节值得特别注意：一是k8s.io/groups.yaml被文档标注为"控制邮件列表与 Google Drive 访问权限的单一事实源"，手工 UI 操作在其未同步前会反复被还原，因此交接必须以 PR 方式更新该文件为准，而不是点几个按钮了事；二是kubernetes/org仓库中的config/kubernetes/org.yaml控制 GitHub 组织级成员身份，离任成员若不从其中移除，将仍保留对 GitHub 团队、仓库的直接访问权。

仓库中的真实依据：sigs.yaml 与 OWNERS_ALIASES

交接清单要求更新的sigs.yaml正是本仓库的权威治理数据源。在 sigs.yaml 中，committee-code-of-conduct节点完整定义了委员会的名称、使命声明、charter 链接、label、领导成员（chairs 与 emeritus_leads，含 GitHub 账号、姓名、公司与邮箱）以及联系方式（Slack 频道、私密邮件列表conduct@kubernetes.io、GitHub Teamcode-of-conduct-committee、Steering 联络人）。例如：

committees: - dir: committee-code-of-conduct name: Code of Conduct mission_statement: > The Kubernetes Code of Conduct Committee (CoCC) is the body that is responsible for enforcing and maintaining the Kubernetes Code of Conduct. charter_link: charter.md label: code-of-conduct leadership: chairs: - github: AnaMMedina21 name: Ana Margarita Medina company: Upbound emeritus_leads: - github: AevaOnline name: Aeva Black contact: slack: code-of-conduct private_mailing_list: conduct@kubernetes.io teams: - name: code-of-conduct-committee description: General Discussion liaison: github: BenTheElder name: Benjamin Elder

与此同时，仓库根目录的 OWNERS_ALIASES 中维护了committee-code-of-conduct别名（当前指向AnaMMedina21、divya-mohan0209、endocrimes、jeremyrickard、stmcginnis），该别名会被各级 OWNERS 文件引用以授权审阅与批准权限。

重要机制：本仓库的sigs.yaml并非仅供人读，而是"单一事实源"。根据 generator/README.md，委员会 README 由生成器依据sigs.yaml自动产出（对应模板为 generator/committee_readme.tmpl），成员列表即来自sigs.yaml中的leadership字段。因此交接时更新sigs.yaml后，committee-code-of-conduct/README.md 中的 Members 与 Emeritus Members 名单会随生成流程同步刷新；仓库还提供了 hack/verify-generated-docs.sh 用于校验生成文档与sigs.yaml的一致性。也就是说：改sigs.yaml一处，即可驱动成员名单在 README 与各类清单中的全局更新，这比手工维护多份名单要可靠得多。

对外沟通（Communications）

执行人：除 Outgoing members 之外的任何人。

• 在月度 Community meeting 上给出成员变动通告
• 向kubernetes/dev邮件列表发送邮件

之所以限定"离任成员不得执行"，是因为换届消息由仍在任或新任成员发布，才能准确代表委员会当前立场。月度社区会议是 Kubernetes 社区的例行沟通窗口，仓库中 events/community-meeting.md 记录了会议的组织方式；而kubernetes/dev邮件列表则是社区开发者周知的公告渠道。对外沟通的意义不止于告知：它还配合 election.md 中"选举结果需重新确认当选者任职意愿后再向kubernetes-dev列表公告"的约定，确保成员变动的每个环节都有公开、可追溯的记录。

知识转移与团队流程（Knowledge transfer and group procedures）

执行人：Carryover members 主导。

• 向新成员引荐相关联系人（Steering 联络人、社区管理子项目、事件响应相关方等）
• 重新评估每周会议时间（新成员的时区与日程可能改变原定时间）
• 为新成员安排培训与知识管理会议

知识转移环节看似软性，实则与委员会的高敏感性工作直接相关。根据 charter.md 与 incident-process.md，委员会需要处理的是高度保密的举报事件——charter 明确"过去的事件通常会向新成员传达，使其具备处理未来问题的历史背景"。这意味着交接不仅是把权限转交出去，更要把历史事件背景、保密义务、triage 轮值安排、调解与回避（recusal）惯例一并交接清楚。同时 bootstrapping-process.md 中"由处理过相关问题的人员向 CoCC 做历史与现状简报"的约定，在常规换届中即由留任成员承担。此外，charter.md 还规定委员会会议在简单多数到场时即达成法定人数（quorum，当可用成员不超过 4 人时 quorum 为 2），因此留任成员在新成员加入后重新确认会议时间，也是保证法定人数可持续满足的前提。

交接的治理上下文：成员从何而来、为何而换

理解交接清单，还需要知道成员的产生与任期机制，这部分由仓库中的治理文档给出：

• bootstrapping-process.md：CoCC 由 5 名成员组成，首次选举中得票前三者任期 2 年、后两者任期 1 年；提名可由 Steering Committee 与 SIG Chairs 发起，最终由 Steering Committee 投票选出。文档还列出了提名候选人的参考特征（无需是 Kubernetes/CNCF 社区成员、有伦理/行为准则委员会经验者优先、具备社区工具使用经验等），这些特征与 election.md 中的候选资格一致。
• election.md：后续每届任期为 2 年，每年交替有 2 或 3 个席位到期，以保持连续性；投票由 Steering Committee 成员进行，同时是提名者则不可投票；选举通常在 7 月发出提名征集、8 月前任期满前公布结果。其中"单一雇主最大代表数为 QUORUM - 1（即 5 人委员会中同一公司最多 2 人）"的限制，正是为了减少事件处理中成员必须回避（recusal）的概率（见 incident-process.md）。
• charter.md：定义了成员移除（需其他成员一致同意）、辞职（须书面通知委员会与 Steering，建议至少提前 30 天）以及席位空缺时由 Steering 任命替补等规则——这些正是触发 Offboarding 与 Onboarding 的具体场景。
• incident-process.md：新成员上岗后需要立即熟悉的实际工作流——举报受理（通过conduct@kubernetes.io或 Slack 私信）、初步 triage、回避判定、制定应对计划、与涉事方沟通、最终处置与对外传达，全部在私密空间内进行。

可以看到，交接清单中的每一项动作（移除 Slack 成员、更新sigs.yaml、更新邮件列表、发布公告、知识转移）都能在上述治理文档中找到其必要性来源：权限随任期开始而授予、随任期结束而收回，知识随人员更替而传承。

交接检查清单速查

最后，将 onboarding-offboarding.md 的完整清单汇总为一张可逐项打勾的速查表，供交接负责人直接使用：

按照"先更新groups.yaml/sigs.yaml等声明式配置、再处理 Slack 与公告、最后安排知识转移"的顺序推进，即可在不中断委员会事件响应能力的前提下，完成一次安全、透明、可追溯的 CoCC 成员交接。

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community