治理 - amp.dev - AMP 框架

词汇表

咨询委员会 (AC)。 一个由来自 AMP 各个选区（包括用户、最终用户和协作者）的代表组成的小组，他们向技术指导委员会提供建议。
协调员。 治理机构的成员，负责促进基于共识的决策过程，并作为其他治理机构的代表。
治理机构 任何咨询委员会、技术指导委员会和工作组。
用户。 使用 AMP 但尚未为其做出贡献的开发人员。
最终用户。使用 AMP 格式消费内容的人员。
技术指导委员会 (TSC)。 一个制定 AMP 技术和产品方向的小组。
工作组 (WG)。一个对特定领域有熟悉度和兴趣的人员组成的小组；可能是跨领域的（例如“文档”），也可能是专注于特定领域的（例如“盈利”或“性能”）。这些小组由 TSC 正式认可，但也可能以非正式形式成立。

咨询委员会向技术指导委员会提供意见和建议。此建议不具有约束力。

TSC 应由在技术和产品层面为 AMP 做出重大贡献的成员组成。
TSC 的成员资格没有时间限制。
TSC 的目标规模为 6-12 名成员，但没有固定规模。
一旦成立，TSC 将通过基于共识的流程确定其自身的成员资格。
TSC 的目标是来自同一雇主的 TSC 成员不超过三分之一。鉴于 TSC 的成员资格要求具有公认的 AMP 技术和/或产品经验，这在 TSC 成立时可能不可行，但 TSC 应积极朝着这一目标努力。
可以授予实体（例如公司）在 TSC 中的席位。在这种情况下，可以对席位施加某些条件（例如，维持对项目的承诺资源）。实体可以指定在 TSC 中代表该实体的个人，并可以自行决定更改此人。
TSC 将从其成员中指定一名协调员，以促进基于共识的决策过程。

工作组是社区中对 AMP 特定领域（例如 UI、运行时、基础设施、文档）具有知识/兴趣的组成部分，并已获得 TSC 的认可。
TSC 定义每个工作组的任务，其中可能包括对某些 AMP 特性、系统和/或代码的责任。工作组通常在其具有任务的领域内独立运作，同时遵守 AMP 的项目指南、愿景/使命和技术/产品路线图。
每个工作组都由一组对该特定领域具有知识/兴趣的协作者 + 其他相关方组成。
每个工作组的协调员负责
- 促进工作组内基于共识的决策。
- 向 TSC 代表工作组。
- 根据需要从工作组内选择指定人员来承担这些责任。
工作组内的决策遵循决策政策，并由协调员或其指定人员协助进行。

TSC 创建工作组并分配初始成员。成员应包括一些提交者，但也可能包括其他相关方。
工作组可以通过基于共识的方法添加或删除成员并更改协调员。
拥有共同兴趣的一群人可以一起工作，而无需正式的工作组，这是可以接受且预期的。这些小组可以选择通过向 TSC 提出提案（包括其目的和拟议的成员资格）来正式获得工作组的认可。
TSC 可以根据需要解散/重组工作组。

AMP 咨询委员会、TSC 和工作组的决策应使用基于共识的方法（类似于 Node.js 使用的方法和 JS Foundation）。
当讨论似乎达成共识时，协调员将询问是否有人对表面上的共识有异议。成员可以要求投票以最终确定决策，但这只应作为最后手段。在小组中另外两名成员同意的情况下，将进行投票，否则将继续寻求共识的过程。
当要求投票时
- 投票时间应设置为允许小组中人员有合理的参加时间。此时间应公开宣布。
- 任何无法在投票时间参加的人都可以提前登记他们的投票。
- 除了对咨询委员会或 TSC 成员的更改需要三分之二的票数外，其他都将采用简单多数票。
对于在工作组内做出的决策，应尽一切努力在工作组内解决问题；工作组内无法解决的问题可以升级到 TSC。
咨询委员会、TSC 和工作组做出的决策必须公开记录（除非出于法律或安全原因不能公开）。
决策应通过异步通信渠道进行。如果不是通过异步渠道进行（例如通过视频会议或面对面会议），则应允许一段合理的时间来提出异议，然后才能批准该决策。
如果有新的技术信息可用，则可以重新审视决策。
咨询委员会、TSC 和工作组可以举行电话会议、视频会议和面对面会议。这些会议应提前充分宣布，并发布议程。应提供社区可以为议程提出项目的机制。

AMP 项目要求所有所有者、协作者和打开拉取请求的贡献者必须接受个人贡献者许可协议 (CLA) 的条款或受公司 CLA 的保护，以保护贡献者和用户在知识产权问题上的权益。
尚未受个人或公司 CLA 保护的 TSC 成员必须在加入 TSC 时获得保护。
AC 成员并非正式要求必须受 CLA 约束，但如果他们决定以某种方式为项目做出贡献（例如，贡献代码、文档、规范或设计文档），而确保知识产权承诺对于保持项目开源和免版税至关重要，那么他们将被要求受 CLA 约束。