摘要

  • CNCF 技术监督委员会 2026 年 8 月 26 日的文章称，在审阅的 72 个项目中，进入 Sandbox 时维护者来自多个机构的项目，毕业率为 59.1%；维护者来自单一机构的项目为 28.6%。文章将两者表述为 2.07 倍，但在本文核对的页面上没有列出各组分母、观察区间、项目级数据或统计方法。
  • 现行毕业申请还分别要求维护者至少来自两个机构，并要求为治理决策制定、记录且实际运行机构平衡机制。这两项都不等同于进入 Sandbox 时观察到的关联；文章提到的 75% 投票门槛仍是建议。
  • CNCF 表示，PR #2265 依据 71 个已毕业及孵化项目的评审结果。维护者至少来自两家机构的标准原已存在；该 PR 澄清了核验方式，并另增机构平衡机制。后续文章报告 72 个项目，但没有公开两组样本的对应关系。

一个项目可能由同一家雇主的工程团队起步，后来吸引其他组织的贡献者，再申请更高的成熟度等级。申请时，审查人员会依据特定文件和标准评估项目治理。如果把这一路径压成一个比例，三个关键问题就容易被混为一谈：机构构成是在何时测量的？数据要说明哪项决定？谁有权把观察到的关联转成晋级条件？

8 月 26 日，CNCF 技术监督委员会主席 Karena Angell 发布文章，称分析涵盖 72 个已毕业、处于孵化阶段或已归档的项目。按文章所述，Sandbox 阶段开始时由多个机构的维护者参与的项目，后来以 59.1% 的比例毕业；单一机构维护者项目的比例为 28.6%。文章将这一结果称为 2.07 倍，并据此讨论治理模式和保障措施。

用这两个四舍五入后的比例相除，确实约为 2.07。但算术无法告诉读者两组各有多少项目、队列覆盖哪些日期、维护者如何定义，或项目更换雇主、跨越成熟度阶段的情况如何处理。我们核对的页面没有项目级数据表，也未说明统计方法。这只是读者凭该页面无法独立重建分析的范围，不代表分析有误，更不说明 CNCF 没有其他记录。它同样不足以支持“多机构维护者导致毕业”的因果结论。

附近另有一份正式审查文件。委员会现行治理审查模板把“项目维护者至少来自两个机构，并能体现项目可持续性”列为毕业阶段必需项，在孵化阶段标为不适用。这是明确绑定阶段的审查标准。8 月文章比较的却是 Sandbox 入口处的维护者构成与之后是否毕业。前者是较早时点上的群体关联，后者是较晚阶段的审查要求，两者不是同一命题。

现行毕业申请还单列了一项必需条件：项目必须记录并证明其治理决策采用了机构平衡机制，例如按机构平衡投票、设有机构席位上限的指导委员会，或具有同等效果的保障。这不是简单统计维护者的所属机构。文章建议在单一机构贡献超过 75% 时考虑平衡投票，但这仍是建议，不是该申请条件的原文。

PR 的修改记录厘清了部分时间线。PR #2265 之前，毕业申请已经要求维护者至少来自两家机构。该 PR 保留了这一标准，补充说明可用现任维护者名单及适用时的 LFX Insights 核验机构归属；同时，它另行增加一项要求：记录并证明治理决策采用了机构平衡机制。PR 说明，这项工作参考了 71 个已毕业及孵化项目的治理评审发现。

PR 所述的 71 个项目，与 8 月 26 日文章分析的 72 个项目，目前还不能合并视为同一组样本。PR 描述的范围是已毕业及孵化项目；后发文章还包括已归档项目。查阅的 PR 描述和 8 月 26 日文章没有提供项目级对应表，也未对样本定义、截止时间、归档项目纳入方式或两组是否重叠作出说明。缺少这份对应表，读者就无法独立判断 PR 引用的评审发现与后来 2.07 倍比较之间的关系。这不改变已知的先后顺序：两家机构维护者的标准早于该 PR；PR 澄清了核验办法，并新增另一项机构平衡机制。项目申请时，应分别记录 Sandbox 入口处的统计指标、原有毕业标准、新增机制和该项目的审查决定。

文章还讨论了第三种安排：按机构平衡投票。该办法以机构而非个人为单位配置治理票数，也可能限制单家公司能取得的票数上限。即使多数维护者受雇于一家企业，它仍可限制那家企业在治理决定中的权重。两家机构的维护者要求讲的是维护者群体的组成；按机构投票讲的是决定权如何分配。文章还把治理表决与代码审查、合并和发布等技术决定区别开来。三种控制机制不能因为都与“多元化”有关就互相替代。

同一篇文章区分了各成熟度阶段当前的必需条件，以及数据分析对项目长期健康提出的建议。其对照表建议：若一个机构贡献超过 75%，无论采用哪种治理模式，都应加入按机构平衡投票。这里的措辞是建议；我们核对的材料并未显示 75% 已自动成为申请门槛。要判断哪些条件适用，仍需看当前申请材料和审查文件。

这些审查文件本身也区分不同结果。治理审查模板将“必须修正项”（Must-Fix Items）与“改进空间”（Areas for Improvement）分开，并明确后者不阻止晋级。审查矩阵还会按项目阶段标记“建议”或“必需”。尽职调查指南则把审查描述为针对书面成熟度标准的一次性评估，通常发生在项目申请升阶时；偏差和执行说明应对应到具体标准，同时审查可以另附建议。建议、正式标准和针对某一项目的审查决定，不能视作同一种约束。

委员会公开说明的职责包括评估项目并在董事会划定的范围内处理成熟度转换。项目生命周期文件区分 Sandbox、Incubation、Graduated 和 Archived，并列有审查、公开征求意见与投票环节。社区参与可以为决策提供材料，但不能替代流程指定的决策权限。同理，委员会主席署名的文章也不会自动成为一条新规则。

委员会的原则页面还提出“最低可行治理”，并称项目毕业后，除法律要求外，不应在未经项目同意时强加新的治理要求。该页面位于 GitHub 可变的 main 分支，页面未显示通过日期或版本。准确的做法是注明这是公开发表的委员会原则，同时说明版本与效力层级尚未从页面确认；我们核对的材料并没有解决它与之后每项标准或决定的关系。

Daniel Kade 的建议是建立一份可追溯的“证据—规则记录”。先公布分析对象、观察期间、定义、分母和限制；再将每项结论标成观察、建议或标准。若标准具有约束力，则指出采纳它的权限主体、生效版本、适用阶段，以及对现有毕业项目的处理方式。最后保留项目审查中逐项判断的依据，并把不阻止晋级的建议与晋级条件分开。这是作者提出的做法，不是 CNCF 政策。

2.07 倍的结果可以帮助维护者比较维护者委员会、选举产生的指导委员会或联邦式治理，也可以促使项目检查决定权是否与实际承担工作的人相匹配。但这个比例不能代替规则文本，规则文本也解释不了这个比例。把两类记录相互链接又保持区别，才能让项目看清数据提示什么、CNCF 在某阶段要求什么，以及哪些选择仍属于项目自身。

来源