附录 A：OpenTelemetry 项目组织

OpenTelemetry 是一个大型项目。OpenTelemetry 项目的工作被划分为特殊兴趣小组（SIG）。虽然所有的项目决策最终都是通过 GitHub issue 和 pull request 做出的，但 SIG 成员经常通过 CNCF 的官方 Slack 保持联系，而且大多数 SIG 每周都会在 Zoom 上会面一次。

任何人都可以加入一个 SIG。要想了解更多关于当前 SIG、项目成员和项目章程的细节，请查看 GitHub 上的 OpenTelemetry 社区档案库。

规范

OpenTelemetry 是一个规范驱动的项目。OpenTelemetry 技术委员会负责维护该规范，并通过管理规范的 backlog 来指导项目的发展。

小的改动可以以 GitHub issue 的方式提出，随后的 pull request 直接提交给规范。但是，对规范的重大修改是通过名为 OpenTelemetry Enhancement Proposals（OTEPs）的征求意见程序进行的。

任何人都可以提交 OTEP。OTEP 由技术委员会指定的具体审批人进行审查，这些审批人根据其专业领域进行分组。OTEP 至少需要四个方面的批准才能被接受。在进行任何批准之前，通常需要详细的设计，以及至少两种语言的原型。我们希望 OTEP 的作者能够认真对待其他社区成员的要求和关注。我们的目标是确保 OpenTelemetry 适合尽可能多的受众的需求。

一旦被接受，将根据 OTEP 起草规范变更。由于大多数问题已经在 OTEP 过程中得到了解决，因此规范变更只需要两次批准。

项目治理

管理 OpenTelemetry 项目如何运作的规则和组织结构由 OpenTelemetry 治理委员会定义和维护，其成员经选举产生，任期两年。

治理成员应以个人身份参与，而不是公司代表。但是，为同一雇主工作的委员会成员的数量有一个上限。如果因为委员会成员换了工作而超过了这个上限，委员会成员必须辞职，直到雇主代表的人数降到这个上限以下。

发行版

OpenTelemetry 有一个基于插件的架构，因为有些观察能力系统需要一套插件和配置才能正常运行。

发行版（distros）被定义为广泛使用的 OpenTelemetry 插件的集合，加上一组脚本或辅助功能，可能使 OpenTelemetry 与特定的后端连接更简单，或在特定环境中运行 OpenTelemetry。

需要澄清的是，如果一个可观测性系统声称它与 OpenTelemetry 兼容，那么它应该总是可以使用 OpenTelemetry 而不需要使用某个特定的发行版。如果一个项目没有经过规范过程就扩展了 OpenTelemetry 的核心功能，或者包括任何导致它与上游 OpenTelemetry 仓库不兼容的变化，那么这个项目就是一个分叉，而不是一个发行版。

注册表

为了便于发现目前有哪些语言、插件和说明，OpenTelemetry 提供了一个注册表。任何人都可以向 OpenTelemetry 注册表提交插件；在 OpenTelemetry 的 GitHub 组织内托管插件不是必须的。