项目如何毕业，决定由谁作出
一句话总结
CNCF 项目要经过 Sandbox → Incubating → Graduated 三个阶段，并由 TOC（Technical Oversight Committee）批准。在 Kubernetes 内部，SIG 拥有代码和决策，WG 处理跨 SIG 的主题，重大变更以 KEP 提出。贡献从签署 CLA 和遵守行为准则开始，经 OWNERS 文件中的 reviewer 和 approver 用 /lgtm 和 /approve 批准后自动合并。
为什么需要它
KCNA 的 Cloud Native Architecture 领域考查的不只是工具，还有创建工具的人们的组织结构。原因很实际。要判断是否采用某个项目，它是 Sandbox 还是 Graduated 是成熟度的第一个信号；遇到 bug 时，要知道该向哪个 SIG 提 issue 才能得到回复；功能为什么这样设计，答案就写在 KEP 里。不了解社区结构，就不是在使用开源，而只是在下载而已。
工作原理
CNCF 项目的成熟度与 TOC
根据 CNCF TOC 仓库，TOC 是 CNCF 的技术治理机构，负责接收并监督所有项目，制定技术愿景和原则，在理事会（Governing Board）划定的范围内批准新项目，对项目进行调整、移除和归档，并把最终用户技术咨询委员会的意见反映到项目中。成员名单中，由理事会任命的委员、由 TOC 任命的委员和由最终用户任命的委员，任期均记为 2 年。
项目阶段由 TOC 流程文档 定义。
| 阶段 | 文档中的定义 |
|---|---|
| Sandbox | 早期的实验性、创新性项目。可能失败，预计会有重大变更和兼容性破坏，正在根据早期采用者的反馈不断完善 |
| Incubating | 采用增多、开始显现稳定性的中间阶段。变更速度放缓，带版本的 API 趋于稳定，也是TOC 开始积极评估采用情况的节点 |
| Graduated | 最成熟的阶段。在稳定性、功能和市场上的广泛采用方面已得到证明，具备成熟的实践、安全措施和活跃的社区参与 |
| Archived | 因活动停滞或很少，TOC 不再支持或不建议使用的项目 |
CNCF 项目页面 把 Graduated 和 Incubating 项目介绍为“被视为稳定，并已在生产环境中成功使用”，Sandbox 页面 则说明 Sandbox 是扩展现有 CNCF 项目的新项目、尝试新方法的独立项目，以及 CNCF 委托的实验项目的归属地。在采用决策中，阶段是“经过了多少验证”的信号，而不是“有多好”的信号。文档还写明，即使是 Sandbox，也有部分组织在生产中使用。
Kubernetes 的 SIG、WG 与委员会
根据 Kubernetes 治理 文档，项目主要按 SIG（Special Interest Group）组织。SIG 由来自多家公司和组织的成员组成，针对网络、文档等特定主题，共同推动项目发展。目标是形成分散的决策结构和代码所有权，并规定项目中每一个可识别的部分（GitHub 组织、仓库、目录、API、测试、issue、PR）都归某个 SIG 所有。SIG 的类型分为垂直型（Network、Storage、Node、Scheduling）、水平型（Scalability、Architecture）和项目支持型（Testing、Release、Docs、Contributor Experience）。每个 SIG 至少有一位、最好有两位主席（chair），并且必须有一份章程（charter），写明范围、职责、权限、角色的选举方式、决策方式和冲突解决方式。SIG 治理 规定，SIG 至少每 3 周召开一次不少于 30 分钟的公开会议，公开会议纪要和录像，并提交年度报告。SIG 内部有子项目（subproject），SIG 列表 则记录了每个 SIG 的主席、联系方式和会议时间。
WG（Working Group）按治理文档，属于 Kubernetes 范围之内，但用于讨论跨越 SIG 边界的主题，SIG 列表文档称之为有时限（time bounded）的小组。委员会（Committee）负责安全或行为准则这类需要审慎处理的主题，与 SIG 不同，它不是开放式成员制，也并非始终公开运作。指导委员会（Steering Committee）根据需要设立委员会并确定其成员。
KEP——提出变更的方法
根据 KEP 指南，KEP（Kubernetes Enhancement Proposal）是向 Kubernetes 提出、沟通和协调新工作的方法。起点是把想法告知赞助 SIG——发到邮件列表或列入会议议程，确认其他人认为这件事值得做并愿意帮忙评审后，再按 KEP 模板撰写。文档对“是否需要写 KEP”的回答是“大体上需要”——可能引起争议的变更、除极小功能外的大多数新功能、对现有功能的重大变更，以及影响项目大部分内容的变更，都需要 KEP。几乎所有 KEP 都放在 SIG 的子目录中，这一流程的灵感来自 IETF RFC、Python PEP 和 Rust RFC。KEP 的价值在于，通过有批准人和评审人的明确流程留下决策，并且之后可以查到这些决策。
行为准则
Kubernetes 社区行为准则 页面写明，Kubernetes 遵循 CNCF 行为准则（v1.3），并转载了全文。承诺的要点是：无论以报告 issue、请求功能、更新文档、提交 PR 还是参加活动等任何方式参与，都要尊重每一个人，并保证在年龄、残障、民族、经验水平、性别、国籍、种族、宗教、性取向等任何方面都没有骚扰地参与。适用范围是项目和社区空间，以及参与者的言行针对 CNCF 项目或其他参与者时的其他空间。由 Linux 基金会以专业人员运营的 CNCF 活动，遵循单独的活动行为准则。CNCF 行为准则页面 除准则正文外，还整理了 FAQ、行为准则委员会及其章程、事件解决流程、管辖与上诉策略、透明度报告和监察专员。
贡献——issue、PR、评审
贡献者指南 把提交代码之前要做的事分为三件——创建 GitHub 账户、签署 CLA（Contributor License Agreement，最简单的方式是向练习用仓库 kubernetes-sigs/contributor-playground 发起 PR）、阅读行为准则和社区价值观。这三件事会在首次提交时由机器人自动检查。开发环境的设置只在提交代码变更时才需要，也可以通过文档或 issue 来贡献。
PR 指南 所说明的评审分为两个阶段。在相应目录的 OWNERS 文件 中被列为 reviewer 的人添加 /lgtm，表示代码已通过受信任评审者的检查；被列为 approver 的人添加 /approve，表示已通过最终检查、可以自动合并。合并由 Prow 机器人完成。OWNERS 文件可以放在每个目录中，也适用于子目录，其灵感来自 Chromium 的 OWNERS 文件。评审速度受限于能评审的人数，评审质量受限于对该代码的熟悉程度，所以用 OWNERS 划分责任，是同时解决这两个问题的办法。
活动
CNCF 活动页面 把活动分为四类。KubeCon + CloudNativeCon 是在全球范围内汇聚采用者和技术人员的旗舰大会；Co-located Event 是聚焦特定项目、CNCF Landscape 层级或行业领域、与 KubeCon 同期举办的 CNCF 主办活动；Project Event 是围绕特定项目的沉浸式聚会；KCD（Kubernetes Community Days）是由本地社区主办、CNCF 提供支持的活动，为首次演讲者和刚加入社区的人提供较低的门槛。
在现场相遇的样子
“这个项目能用吗？” 先在 CNCF Landscape 中查看阶段。Graduated 意味着已有多个组织在生产中验证过；Sandbox 则意味着你要做好兼容性被破坏的准备，以早期采用者的身份加入。阶段是 TOC 的判断，而不是厂商的广告。
发现了 bug，却不知道该提到哪里。 在 Kubernetes 仓库的相应目录中打开 OWNERS 文件，就能看到拥有该代码的 SIG 和评审者。在 SIG 列表中找到会议时间和 Slack 频道并先去询问，是避免 issue 被搁置的办法。
下一项测验要确认什么
测验会考查成熟度阶段的定义和 TOC 的职责、SIG 与 WG 的区别、需要 KEP 的变更、贡献前的必要流程、/lgtm 与 /approve 的执行者，以及活动的种类。