CNCF 项目进入 Sandbox 后贡献者应先查哪些流程

我第一次帮团队看 CNCF Sandbox 申请时，最容易误判的一点是：看到“Sandbox”就以为项目已经获得生产可用背书。其实它更像一个早期项目的公共孵化入口，允许项目继续快速变化，也允许贡献者在较低成熟度下参与验证。真正要查的不是某个项目的宣传页，而是申请条件、TOC 状态和仓库里的贡献入口。

官方入口：https://github.com/cncf/sandbox/

最稳妥的顺序是：先确认项目确实是可复用的云原生项目，再检查 Apache 2.0 与维护者资料，最后通过官方 Issue Form 申请；进入 Sandbox 后，贡献者仍要按项目自己的公开规则协作。

先弄清 Sandbox 代表什么

CNCF 的项目生命周期包含 Sandbox、Incubation、Graduation 和 Archived 等阶段。Sandbox 面向创新想法和早期项目，功能可能发生破坏性变化，发布流程也可能持续调整；它的价值是让项目获得公开可见度、逐步补齐社区和治理基础，而不是替使用者承诺稳定 API。

因此，贡献者读项目介绍时应把“值得试用”和“适合生产”分开。需要关注的是项目解决了什么云原生问题、代码是否可复用、是否有持续维护者，以及 issue 和发布记录是否能说明真实进展。

申请前先查四组容易漏掉的条件

这四项是我会先做的“申请前止损清单”。尤其是许可证和 MAINTAINERS：CNCF Sandbox README 明确把它们列为常见关闭原因。项目如果仍在另一个项目的 GitHub 组织中，还应先留下公开的拆分共识；这比在表单里临时解释更容易复查。

提交后如何读 TOC 的状态

申请使用 cncf/sandbox 的 Sandbox Application Issue Form，完成表单全部部分后提交。之后先看项目板和 Issue 评论，不要只等一封邮件。TOC 会先做完整性分流；资料不足时，申请可能被标记为 Need-Info 或 Postponed，评论会指出需要补充的内容。

New 表示仍在队列中，Returning 表示此前需要补充的信息已经处理、等待再次讨论，Approved 才表示申请获得通过。Need-Info 的正确动作是把补充内容写回原 Issue，并按项目仓库的说明标记已完成；如果是 Postponed，则先解决关闭评论中的问题，再根据规则重新打开或新建申请并关联旧 Issue。状态名很短，但每个状态背后都对应一个公开动作。

进入 Sandbox 后，贡献者从哪里开始

如果项目已经进入 Sandbox，我建议先读仓库 README，再依次找 Code of Conduct、CONTRIBUTING、MAINTAINERS、路线图和近期 Issue。先从文档修正、复现问题、测试补充或小范围 issue 讨论开始，通常比直接提交大功能更容易建立上下文。

贡献前还要确认仓库的分支策略、提交签名要求、讨论频道和发布节奏。CNCF 的项目承载关系不替代项目自己的技术判断；Sandbox 阶段仍可能快速改接口，所以贡献者要把版本、变更范围和回滚方式写清楚。对使用者来说，这些公开资料也是判断项目是否值得继续评估的依据。

几个容易混淆的问题

进入 Sandbox 就能直接用于生产吗？不能这样推断。它是早期阶段，项目可能有较大变化，是否适合生产要结合项目自己的稳定性、安全、发布和运维证据判断。

申请一定有固定处理时限吗？CNCF 官方流程没有承诺统一时限，审核顺序和项目复杂度都会影响等待时间。最有效的做法是保持 Issue 信息完整、及时回复公开评论，并持续维护仓库资料。

普通开发者如何参与？先从公开文档、Issue 和贡献指南开始，选择边界清楚的小问题；如果找不到入口，可以在项目公开渠道提问，而不是假设 CNCF 会替项目制定具体开发流程。