摘要

  • OpenTelemetry 当前公开文件的 project-maintainers 组有 162 个账号，servicedesk 组有 19 个。现任 Community Management 名单中的两位负责人只出现在前者。
  • 项目章程承诺 Community Managers 可访问 Service Desk；10 月 30 日获批的同步规则却把自动组定义为治理委员会与技术委员会。公开文件没有解释人工建号能否兑现这项章程权利。

分析

先看组名单，再看权利

治理文件可以授予一项权利，自动化也可以决定谁拿到实际账号。OpenTelemetry 的服务台规则把这两件事写在了不同文件里。

Governance Committee Charter 于 2026 年 2 月更新。章程允许治理委员会任命 Community Managers，负责跨 SIG 的项目、活动和社区工作；被任命者甚至可以来自 OpenTelemetry 项目之外。章程还把这项工作连接到 CNCF 的活动、传播和其他跨机构安排，明确写出 Community Managers 会有 Service Desk 访问权。

公开成员页 目前把两位负责人列在 Community Management 一栏。两人的 GitHub handle 也出现在 OpenTelemetry 当前 .project 文件的 project-maintainers 组中，却不在旁边的 servicedesk 组。前一组有 162 个账号，后一组有 19 个。

这不是从一个数字猜测某个人是否能登录。10 月 30 日，OpenTelemetry 合并了第 11 号名册同步请求，并把来源指向公开的社区成员数据。请求描述清楚写出生成规则：project-maintainers 由 Governance Committee、Technical Committee 和普通维护者合并而成；servicedesk 则只由前两个委员会合并而成。两种身份如何落入账号名单，已经变成自动同步规则的一部分。

CNCF 的9 月项目月报解释了规则的后果。没有 servicedesk 组，所有项目维护者默认保留服务台访问权；组一旦存在且有人，只有列出的 handle 获得被限定的自动访问，而且 handle 也必须同时列在维护者组。OpenTelemetry 是第一个使用该功能的项目。邮件列表仍按完整维护者名册同步，因此被缩小的是服务台权限范围，不是项目维护者身份，也不是代码决策权。

由此出现的差异很具体：章程把服务台权利授予 Community Manager 这个职务；自动组只按两个委员会的成员身份生成。当前公开的两位管理者是维护者，却不属于生成服务台名单的那两类。文件仍能各自自洽，合在一起就没有给出同一答案。

空名单保护不了被规则遗漏的岗位

CNCF 的 .project 自动化指南为无效名单设了保护：如果 servicedesk 为空，或没有解析出任何维护者，系统告警并保留既有权限。这能防止一次拼写错误就撤销整个项目的服务台席位。

OpenTelemetry 的名单并非空白，规则也能正常执行。空名单保护处理的是数据坏掉的情况，不是某个被章程明确提到的岗位没有被写进有效的筛选公式。机器可以通过格式检查，同时把权利漏在格式正确的名单之外。

这个差异会影响工作的落点。Community Managers 负责跨 SIG 项目、社区活动以及与 CNCF 的协作。如果一项任务需要提交服务请求，章程授予的权利却要先经过另一位成员或一条未公布的例外通道，正式任命与日常执行之间就多了一道无法核验的交接。

把角色与账号放进同一条规则

OpenTelemetry 不必把服务台席位重新开放给 162 名维护者。它需要公开说明谁因何种角色取得席位、各角色来自哪份上游名单、人工例外由谁批准，以及两份规则冲突时以哪份为准。

治理委员会可以把 Community Management 纳入自动组生成规则；也可以保留 19 人名单，同时发布一个可验证、能兑现章程权利的人工授权办法；还可以在明确决定后修改章程中的访问权。把差异搁着不管，则是让创建账号的自动流程替治理文件做了选择。

CNCF 应把答复与组生成规则一同公开，让下一位受任者知道这项职务对应哪条授权路径。

19 人的名单或许完全按其代码运行。正因如此，名单还需要说明它服务于哪些职责。好的权限记录不只列出账号，也要指出账号要支撑哪项制度工作。

来源