1. CNCF 项目提案流程 v1.5
1.1. 介绍
该治理政策规定了项目被云原生计算基金会（“CNCF”）接受的提案流程。对于寻求进入 CNCF 的现有项目和将在 CNCF 内形成的新项目，该过程是相同的。
1.2. 项目阶段
1.3. 时间线
TOC 不保证项目是否/何时会加入 CNCF 或升级。
对于沙盒提案，每两个月从最旧的申请到最新的申请进行一次审核，TOC 可能没有时间在每次会议上通过每个申请。最新列表可以在这里找到，如果不是每个人都被审查的话，它将在会议之间转移。
对于升级到孵化或毕业阶段，项目应计划从初始申请到批准至少 5 个月或更长时间。由于围绕 KubeCon + CloudNativeCon 的社区需求增加，新的公众评论期和公众投票将不会在 KubeCon + CloudNativeCon 后的 6 周内启动。项目在计划完成尽职调查时应考虑到这一点。
问：为什么 TOC 不是每次会议都通过沙盒列表？ 答：目前有很多项目想成为 CNCF 的一部分，TOC 的工作是仔细考虑它们是否适合基金会。这种审议需要时间，而且每次会议 TOC 可以通过的申请数量有限。如果有的话，从一次会议到下一次会议的延迟对项目来说是一个好处，因为它允许有更多时间来建立社区支持。
问：一旦我的应用程序进入，我的项目究竟需要多长时间才能移动级别？ 答：就像在开源中一样，工作完成就会完成。这可以从 5 个月到 15 个月不等，请与您的 TOC 发起人协调以确保一切正常进行。
问：我的项目还能在 KubeCon 的 6 周内申请移动关卡吗？ 答：是的，尽管获得 TOC 赞助商、进行任何尽职调查以及流程的任何其他步骤都将推迟到 KubeCon 之后。
问：为什么不能在 KubeCon 的 6 周内启动公众评论期或投票？ 答：进行尽职调查是一项非常重要的工作。进行采用者访谈需要时间，而且我们越接近每个 KCCN，时间安排就越困难。能够成功完成尽职调查以启动流程的公共部分变得非常困难，因为许多社区成员对会议有额外的责任。通过删除 KCCN 作为全新请求移动级别的目标帖子，我们希望不会耗尽采用者、TOC、维护者和其他社区成员。
1.4. 沙盒流程
注意：TOC 已将沙盒申请流程更改为更加透明和简化的工作流程📦 沙箱应用程序存储库 📦.
所有例外情况和“拒绝”或“推迟”结果均由 TOC 处理。在解决相应问题的申请评论中指出的领域后，可以鼓励项目重新申请。有关重新申请的更多详细信息，请参阅 Sandbox repo README中的说明。
申请沙盒
项目通过 Sandbox Repo 的Issue Form 申请沙箱。有关此过程的更多信息，请参见 Sandbox 存储库主页。
沙盒项目年度回顾
一旦进入沙盒，项目就会受到年度审查。
治理/法律问题
- NCF 工作人员处理治理/法律问题
- 鼓励项目参与/出席 TOC 会议，并联系 TAG 寻求建议或安排演示和讨论。
有关 CNCF 沙箱的定义和背后的动机，请参阅沙箱指南。
1.5. 孵化过程
注意：我们简化了孵化过程。
所有异常（和“无”结果）都由 TOC 处理。
项目提案
- 通过 GitHub 拉取请求提议的孵化
- 当 TOC 成员作为孵化发起人向前迈进时，提案将进入尽职调查阶段——请避免单独联系 TOC 成员担任项目发起人。
- 未完成的孵化提案的状态每月在 TOC 公开会议上报告。这会突出显示寻求赞助的项目，并提供对赞助项目的 DD 进度的检查。
- 潜在的赞助商可以表明他们有兴趣但目前没有能力在 DD 上工作，以设定项目的期望。
- TOC 可能同意该项目（尚未）满足孵化要求，并就出现这种情况的原因提供反馈。如果该项目尚未在 CNCF 中，TOC 可能会建议该项目改为申请 Sandbox。
- 如果 TOC 孵化发起人在提案 PR 提交后的两个月内没有挺身而出，项目可以通过将其添加到工作文档中来要求在即将举行的 TOC 会议上讨论他们的项目提案。讨论的结果要么是赞助商向前迈进，要么是 TOC 投票同意该项目进入沙箱，或者该提案被拒绝（项目可能会在六个月后重新申请）。如果即使在所有这些步骤之后，赞助商仍未向前迈进，则该提案将被拒绝。
- DD 通常会向 TAG 进行演示，但欢迎有兴趣的 TAG 随时安排项目演示。如果还没有 TOC 孵化赞助商，TAG 可以与他们的 TOC 联络人讨论他们对项目的建议或担忧。
- 虽然没有必要，但允许项目非正式地联系 TOC 成员寻求建议，包括询问潜在的赞助。TOC 成员应该让彼此了解这些方法，这样我们就可以避免成为“游说”的牺牲品（直接联系 TOC 成员自愿或管理行动或问题）。寻求帮助以成功申请的项目与货比三家寻求向 TOC 成员施加压力以获得赞助的项目之间存在细微差别。. TOC孵化赞助商
- TOC 孵化发起人负责推动流程，并与 TAG 协调以进行他们认为合适的审查和输入。
- TOC 孵化发起人是项目整个过程中的联络点。
- TOC 成员不得赞助他们有明显利益冲突的项目（例如，主要来自他们的组织）。这并不意味着他们完全不能参与 - 例如，贡献拉取请求或成为该项目的采用者，可以表明对有价值的项目有健康的兴趣和知识。. 尽职调查 2-3 个月
- TOC 孵化赞助商推动尽职调查（参见模板和指南）。
- TOC 孵化发起人可以将 DD 工作委托给 CNCF TAG 和/或其他 TOC 成员。
- 通常，DD 包括向 CNCF TAG 的演示，由 TOC 赞助商确定。如果 TOC 发起人认为有现成的和合适的视频演示 - 例如，因为 TAG 最近已经举行了演示，则可以省略此步骤。（我们不希望不必要的流程或官僚主义延迟一个广为人知和采用的项目加入 CNCF）。TOC 赞助商可酌情安排替代方案（例如，在 TOC 会议上安排问答环节）以确保有充足的机会提问。
- TOC孵化发起人可以要求项目维护者完成DD模板。（在实践中，项目维护者有时会选择在正式的 DD 流程之前开始，甚至在初始提案之前开始，因为这可以帮助他们确保满足所有要求。）TOC 孵化发起人应仔细审查和询问有关项目维护者准备的 DD 的问题，也可以请求 TAG 来帮助解决这个问题。
- CNCF 工作人员做治理和法律 DD。
- 在 DD 期间，一些对话可能会私下进行（例如，采用者希望保持匿名的采用者访谈）并酌情记录下来。
- TOC 成员不需要确定受访组织的直接采用者类型，而是他们应该使用自己的判断力和常见问题解答中为选定的受访组织定义的指南以及采访的性质，因为它最有助于项目，这可能包括对直接采用者和传递采用者进行联合访谈，以确定成熟度和互动。
- TOC孵化发起人确认项目符合孵化要求。
- TOC 孵化发起人决定 DD 何时“完成”。然后，DD 文档应该放在 GitHub 上，公开征求公众意见。. 尽职调查审查 2-6 周
- 当 DD 文档可供公众审查和评论时，TOC 孵化发起人会在 TOC 邮件列表上宣布，这可以在 GitHub、TOC 邮件列表或 TOC 公开会议上进行。
- TOC 孵化发起人决定何时召集 TOC 投票，在召集投票前至少留出两周时间征求公众意见。TOC 投票 最多 6 周
- TOC成员评估项目是否符合孵化标准
- 项目通过 TOC 的 2/3 绝对多数票被接受进入孵化。
- 如果投票在 6 周后仍未定论，TOC 主席可以延长投票时间，或得出沉默 = 弃权的结论
1.6. 毕业过程
提交毕业申请模板
- 项目在 cncf/toc GitHub repo 中的 pull request 中填写并提交毕业提案模板。
- 包含提案的文件应位于毕业提案目录中。
- 除了标准的毕业要求之外，该提案还解决了项目自孵化以来的发展情况以及孵化 DD 的任何问题。
- 项目将在申请时滚动审查，而不是每年召开两次会议。
- 如果 TOC 成员作为赞助商挺身而出支持该项目并确定毕业 DD 文件已定稿，则该 TOC 成员将在两周内开始在 TOC 邮件列表上征求公众意见
- 请避免单独联系 TOC 成员担任项目发起人。
- 该电子邮件应包含指向提案拉取请求和毕业 DD 文档的链接。
- 此时欢迎所有 TAG、采纳者、TOC 成员和社区成员在邮件列表上发表评论。
- 从历史上看，项目已经将 TOC 演示作为毕业过程的一部分。TOC 已经摆脱了演示文稿要求。
- 如果届时 TOC 不支持项目继续推进，他们将向项目提供反馈并关闭 PR。
- 如果毕业 DD 文档未最终确定，TOC 发起人将开始更新现有 DD 文档的流程并开始公众评论流程。
TOC投票
- TOC 成员评估项目是否符合毕业标准
- 项目必须获得 TOC 的 2/3 绝对多数票才能毕业
笔记
- TOC始终拥有最终决定权
- TOC 不必接受 TAG 推荐
- 结果可能是“否”，仅仅是因为赞助商没有在规定的时间内挺身而出
- TOC Triage 或 TAG 建议的结果可能是我们想要等待某些原因，例如项目积压；将类似的项目分批处理。在这些情况下，我们应该给项目一个解释并设定时间期望。
- 所有“否”结果和其他例外情况均由 TOC 讨论，然后与项目和 TAG 代表讨论。我们将尝试提供反馈，但这可能只是对项目缺乏信心。
- 如果项目关注时间表，觉得他们已经等了太久，或者需要伸出援手，请通过他们的邮件列表之一联系 TOC 或联系 CNCF 工作人员。
- 鼓励项目参与/参加 TOC 会议，并向 TAG 寻求建议或安排演示和讨论。