项目治理很容易走向两个极端：小团队过早建立复杂委员会，或者项目已经拥有大量维护者和用户，却仍依赖少数创始人的口头决定。对 72 个 CNCF 项目的治理审查显示，更可靠的做法是区分两类问题：当前成熟度需要满足什么，以及为了长期健康还应该提前建设什么。
“必须满足”与“建议建设”不是一回事
CNCF 成熟度评估关注项目在相应阶段是否具备必要的治理能力，但最低要求并不等同于理想终点。一个项目通过当前阶段的检查，只能说明它在这一时点达到了对应门槛，不能证明其决策机制足以支撑未来增长。
实践中可以把治理事项分成两列：
| 类别 | 要回答的问题 | 典型证据 |
|---|---|---|
| 当前要求 | 项目在申请或维持当前成熟度时必须证明什么？ | 治理文档、维护者名单、行为准则、公开决策记录 |
| 长期建议 | 哪些机制能够减少人员增长和领导层变化带来的风险？ | 任期与轮换规则、利益冲突政策、申诉流程、继任机制 |
具体要求应以 CNCF 当前发布的成熟度标准和评审意见为准。团队不应把某个项目的治理文件直接当作通用合规模板，因为项目规模、风险和贡献者结构并不相同。
治理复杂度要跟着项目变化
小型项目最需要的是清晰，而不是层级。两三名维护者通常不需要多个委员会，但应明确谁能合并代码、如何新增维护者，以及争议无法达成共识时由谁处理。
进入增长阶段后，治理的重点会转向权力分配。维护者数量增加、厂商参与变多，单纯依靠“大家讨论后决定”会产生三个问题：决策何时结束不明确，弃权与反对无法区分，利益冲突缺少处理依据。此时可以引入投票门槛、法定人数、公开会议记录和回避规则。
成熟项目则要防止治理机制依赖具体个人。除了技术决策，还需要考虑安全响应、品牌或商标、行为准则执行，以及维护者退出后的权限回收。委员会不是成熟度的象征；只有在职责已经分化、单一维护者组无法有效承担工作时，拆分机构才有价值。
一个实用判断是：如果新增一个治理角色不能解决已发生的问题，也没有清晰的输入、权限和输出，就暂时不要创建它。
可以这样实践：把治理规则变成可检查的数据
下面是一个可改造的最小示例。它不是 CNCF 官方格式，而是一种团队内部实践：用 YAML 记录治理角色、决策门槛和评审周期，再通过脚本检查关键字段是否缺失。
创建 governance.yaml：
project:
name: example-project
stage: growing
roles:
maintainers:
- alice
- bob
- chen
security_contacts:
- alice
- chen
decisions:
routine:
method: lazy_consensus
review_days: 3
major:
method: vote
quorum: 2
approvals_required: 2
conflict_of_interest_recusal: true
membership:
nomination_required: true
documented_contributions_required: true
inactive_review_days: 180
records:
public_minutes: true
decision_log: docs/decisions
maintainer_list: MAINTAINERS.md
review:
governance_review_days: 180
再创建 validate_governance.py。运行前只需安装 PyYAML：
from pathlib import Path
import sys
import yaml
path = Path("governance.yaml")
data = yaml.safe_load(path.read_text(encoding="utf-8"))
errors = []
maintainers = data.get("roles", {}).get("maintainers", [])
major = data.get("decisions", {}).get("major", {})
records = data.get("records", {})
if len(maintainers) < 2:
errors.append("至少需要记录两名维护者，以降低单点依赖")
if not major.get("quorum"):
errors.append("重大决策缺少 quorum")
if not major.get("approvals_required"):
errors.append("重大决策缺少 approvals_required")
if not major.get("conflict_of_interest_recusal", False):
errors.append("重大决策没有明确利益冲突回避规则")
if not records.get("decision_log"):
errors.append("缺少公开决策记录目录")
if errors:
print("Governance validation failed:")
for error in errors:
print(f"- {error}")
sys.exit(1)
print("Governance configuration passed basic checks")
执行检查：
python3 -m venv .venv
. .venv/bin/activate
python -m pip install PyYAML
python validate_governance.py
这类检查不能判断治理是否公平，但能防止文档重构时意外删除关键规则。项目还可以把命令放进 CI，并检查 MAINTAINERS.md、决策日志目录和安全联系方式是否真实存在。
评审时不要只数文档
治理审查不应退化成文件清单。即使仓库中存在 GOVERNANCE.md，团队仍需要验证规则是否被实际执行：重大决策是否留下记录，新维护者是否按照公开标准加入，离任人员的权限是否及时撤销，以及利益冲突发生时是否真的回避。
建议每六个月或在以下事件之后复查治理结构：维护者人数显著变化、引入新的主要厂商、发生公开争议、核心负责人离开，或者项目准备申请新的成熟度阶段。
采用时可以保留一份简短清单：
- 当前 CNCF 阶段的正式要求已经逐项核对，并保留证据。
- 维护者、技术委员会和其他角色的权限边界可以被贡献者理解。
- 常规决策与重大决策使用不同且明确的流程。
- 新增、移除和长期不活跃成员都有公开规则。
- 利益冲突、行为准则和申诉问题有独立处理路径。
- 治理结构设有固定复查日期，不依赖某个人主动想起。
合适的治理结构不是最复杂的结构，而是当前团队能够真实执行、同时为下一阶段留出调整空间的结构。先满足明确要求，再根据已经出现的协作压力补充机制，通常比一次性复制成熟项目的全部委员会更稳健。