OpenTelemetry 已经成为云原生可观测性体系中的关键公共依赖，但“广泛使用”并不自动等于“可持续维护”。2026 年 4 月，CNCF、OpenTelemetry 项目与 Bloomberg 开源项目办公室共同推动了一项为期十周的贡献者 cohort。它延续了一个重要转变：企业不能只管理自己引入了哪些开源依赖，还需要思考如何参与这些依赖的长期治理。
来源摘要没有披露每周安排、参与人数或最终产出，因此下面不会虚构项目成绩，而是聚焦这种十周协作机制为何值得关注，以及团队可以怎样把它改造成可执行的贡献流程。
十周解决的不是一个 Issue，而是贡献路径
大型开源项目通常不缺“想帮忙的人”，真正稀缺的是能够持续工作的贡献者。新人第一次进入 OpenTelemetry 这类项目时，需要同时理解多个层面：
- 项目的仓库边界、SIG 分工和治理规则；
- Issue 分类、设计讨论、代码评审与发布流程；
- API、SDK、Collector、语义约定等组件之间的兼容关系；
- 测试、文档、向后兼容和跨语言一致性要求。
如果企业只安排一次贡献日，参与者往往刚完成环境配置，活动就结束了。十周 cohort 的价值在于提供足够长的反馈周期：参与者可以选题、提交小改动、接受评审、修正方案，再观察改动如何进入项目日常维护流程。
这也是“依赖管理”与“stewardship”的分界线。前者关注版本、许可证、漏洞和升级成本；后者还要回答三个问题：谁理解这个依赖，谁能与上游协作，谁愿意承担持续维护责任。
Cohort 需要同时服务新人和维护者
贡献者计划不能只统计 Pull Request 数量。一个仓促合并的小改动，未必比一份准确的问题复现、测试补充或维护文档更有长期价值。更合理的衡量维度包括：
- 参与者是否完成了从 Issue 到评审的完整闭环；
- 是否有人在计划结束后继续参与讨论或维护；
- 维护者是否沉淀了更清晰的入门任务和反馈机制；
- 企业内部是否建立了贡献时间、法务审批和技术支持机制；
- 工作是否减少了维护负担，而不是制造更多待审请求。
边界同样重要。维护者不是企业培训服务的无限资源。Cohort 应限制并发任务数量，提前确认导师容量，并优先选择范围清晰、能够在数周内得到反馈的工作。涉及公共 API、协议语义或跨语言一致性的变更，通常需要更长讨论，不适合作为追求快速合并的入门任务。
可以这样实践：把十周计划写成可检查的配置
下面是一个可改造的最小方案，并非来源披露的 OpenTelemetry cohort 原始日程。它把每个阶段的目标、交付物和退出条件写进 YAML，适合企业 OSPO 或平台团队管理内部参与者。
将 owner、repository 和任务内容替换为团队的实际信息，然后保存为 cohort.yaml：
name: otel-contributor-cohort
length_weeks: 10
owner: platform-observability
repository: https://github.com/open-telemetry/your-target-repository
phases:
- name: orientation
weeks: [1, 2]
deliverables:
- development environment documented
- governance and contribution guides reviewed
exit_criteria:
- participant can run the relevant test suite
- name: issue-selection
weeks: [3, 4]
deliverables:
- scoped issue agreed with an upstream maintainer
- reproduction or acceptance criteria recorded
exit_criteria:
- maintainer confirms scope
- name: implementation
weeks: [5, 6, 7]
deliverables:
- tests added or updated
- pull request opened
exit_criteria:
- automated checks pass
- name: review
weeks: [8, 9]
deliverables:
- review comments addressed
- user-facing documentation updated when needed
exit_criteria:
- no unresolved blocking feedback
- name: continuation
weeks: [10]
deliverables:
- maintenance notes written
- next contribution identified
exit_criteria:
- ownership after the cohort is explicit
可以再用下面这个只依赖 Python 标准库的脚本检查周次是否恰好覆盖 1 到 10。脚本假设安装了 PyYAML；运行前执行 python -m pip install pyyaml。将脚本保存为 validate_cohort.py：
from pathlib import Path
import sys
import yaml
config_path = Path(sys.argv[1] if len(sys.argv) > 1 else "cohort.yaml")
data = yaml.safe_load(config_path.read_text(encoding="utf-8"))
expected = set(range(1, data["length_weeks"] + 1))
assigned = []
for phase in data["phases"]:
weeks = phase.get("weeks", [])
if not phase.get("deliverables"):
raise SystemExit(f"{phase['name']}: missing deliverables")
if not phase.get("exit_criteria"):
raise SystemExit(f"{phase['name']}: missing exit criteria")
assigned.extend(weeks)
actual = set(assigned)
duplicates = sorted({week for week in assigned if assigned.count(week) > 1})
if actual != expected or duplicates:
missing = sorted(expected - actual)
extra = sorted(actual - expected)
raise SystemExit(
f"invalid schedule: missing={missing}, extra={extra}, duplicates={duplicates}"
)
print(f"OK: {data['name']} covers weeks 1-{data['length_weeks']}")
运行检查：
python -m pip install pyyaml
python validate_cohort.py cohort.yaml
这份配置的重点不在 YAML 本身，而在于强迫组织写清楚退出条件。比如“打开一个 PR”只是动作，“自动化检查通过且没有阻塞性反馈”才是可以验证的阶段结果。
企业接入前应确认什么
准备类似计划时，可以用一份简短清单降低双方成本：
- 选定一个明确的 OpenTelemetry 子项目，不要把整个生态当成单一仓库；
- 先与上游维护者确认任务范围和评审容量；
- 为参与者保留固定工时，而不是依赖业余时间；
- 从测试、文档、问题复现和小型修复开始建立上下文；
- 不用合并数量单独评价参与者或维护者；
- 在第十周明确后续负责人、沟通渠道和下一项工作；
- 记录没有完成的任务及原因，避免把延期包装成成果。
十周不会自动创造维护者，也无法解决所有项目可持续性问题。它提供的是一个足够长、又有明确边界的协作窗口。真正决定计划价值的，是 cohort 结束之后，企业是否仍然给工程师时间，上游是否获得了可持续的帮助，以及参与者是否已经从“使用 OpenTelemetry”走向“理解并共同维护 OpenTelemetry”。