Fuchsia 贡献者角色

概览

本文档定义了与为 Fuchsia 项目做出贡献相关的角色。

原则

Fuchsia 项目中的角色旨在体现以下原则：

• 透明度。我们会公开透明地说明角色和要求。
• 包容性。Fuchsia 允许任何人（无论其雇主是谁）为该项目做出贡献。我们认为，来自多元化开源社区的贡献对于改进 Fuchsia 至关重要。
• 责任。如果某人不再符合要求，其角色和权限可能会被撤消。

角色

以下是与 Fuchsia 项目关联的贡献者角色：

• 成员
• 提交者
• 所有者
• 全球审批者

成员

通过提供代码或文档补丁为项目做出贡献，并同意 Google Developers 的贡献者许可协议的任何人。

职责

成员有责任遵守 Fuchsia 行为准则。

成为会员

如需成为会员，您必须执行以下操作：

• 签署 Google Developers 的贡献者许可协议。
• 确认您已了解 Fuchsia 行为准则。

提交者

提交者是指对 Fuchsia 代码库具有写入权限的人员。提交者可以提交自己的 Gerrit 更改，也可以提交任何其他成员的 Gerrit 更改。

提交者不仅是能够做出更改的人，也是能够与 Fuchsia 社区的其他成员有效协作的人。合作活动的示例包括但不限于：

• 寻找最了解情况的人来审核其代码更改。
• 贡献经过充分测试的优质代码。
• 修复代码或测试中的 bug。

成员可以通过不同类型的贡献成为提交者。例如，从事文档或工具链工作的人员可以通过贡献高质量的文档或配置更改来满足成为提交者的要求，而这些贡献可能无法达到经过充分测试的代码的“传统”标准。

为了提交 Gerrit 更改，提交者需要成为受影响文件的 Owner，或者获得受影响文件的 Owner 的批准。

职责

提交者负责以下事项：

• 确保提交给 Fuchsia 的代码（由提交者提交）根据可测试性评分标准进行测试。
• 确保提交给 Fuchsia 的代码遵循测试最佳实践。

成为提交者

如需成为提交者，您必须执行以下操作：

• 向项目贡献 10 个非微不足道的补丁，展示编写高质量、经过充分测试的代码的能力。
• 获得一位已审核过您代码的现有提交者的提名。
• 获得另外两位审核过您代码的提交者的支持。
• 确保您的提名未被任何提交者阻止。

当前提交者通过向 committers@fuchsia.dev 发送包含以下信息的电子邮件来提名您。请勿在提名电子邮件中抄送被提名人。

• 您的姓名。
• 您的电子邮件地址。
• 说明您为何应成为提交者。
• 包含您的补丁的修订版本（约 10 个）的嵌入式链接列表。

另外两位提交者需要附议您的提名。如果在 5 个工作日（美国）内无人反对，您就成为提交者。如果有人反对或需要更多信息，提交者会进行讨论，通常会在 5 个工作日内达成共识。如果问题无法解决，则由当前提交者进行投票。

大功告成！您无需再采取任何行动。提交者做出决定后，会尽快回复您。

在最糟糕的情况下，这可能需要两周的时间。继续编写补丁！即使在极少数提名失败的情况下，异议通常也很容易解决，例如“补丁更多”或“不够了解此人的作品”。

获得现有提交者的批准后，Fuchsia 社区管理者会将您添加到 committers@fuchsia.dev，并与您联系，提供有关以外部贡献者身份提交贡献的其他信息。

尝试作业访问权限

如果您是补丁贡献者，但还不是提交者，您可能希望能够直接在 try 服务器上运行作业，而不是让提交者或审核者为您运行。

获取试用版职位访问权限的流程如下：

• 请与您合作的提交者（例如，经常审核代码的提交者）发送电子邮件至 committers@fuchsia.dev，提名您获得 try 作业访问权限。
• 您必须提供电子邮件地址，并至少简要说明您希望获得访问权限的原因。
• 最好还提供姓名和公司关联信息（如有）。
• 最好已经提交了一些补丁，但这不是绝对必要的。
• 如果无人在两（美国）个工作日内提出异议，您将获批访问权限。授权可能还需要几天时间才能传播到所有系统。

所有者

所有者负责 Fuchsia 项目中的文件或目录，并且对相应子树中的代码有全面的了解。所有者列在 OWNERS 文件中。对于不属于所有者职责范围的目录或文件，相应所有者拥有与提交者相同的权限。

我们鼓励提交者及时更新 OWNERS 文件。

职责

除了提交者和成员的职责外，所有者还负责以下事项：

• 提名其他所有者。
• 批准或移除其他所有者。
• 提供优质评价和设计反馈。
• 批准其子树中代码的更改。

成为所有者

如要成为所有者，您必须执行以下操作：

• 成为 Committer。
• 向受影响的子树提交大量非微不足道的更改。
• 提供高质量的评价和代码设计反馈。
• 及时提供代码审核。
• 自行提名或由其他提交者提名。
  • 如需自行提名，请提交 Gerrit 更改，将自己添加到所需代码库的 OWNERS 文件中。 当前所有者会评估您的更改，并接受或拒绝您的请求。

全球审批人

全局审批者是 owners-override@fuchsia.dev 群组的成员。全局审批人可以在 Gerrit 中调用所有者替换位，从而免除对更改的 OWNERS 要求。

虽然全局审批者有权为大规模更改提供所有者替换 +1，但他们无需全面了解整个 Fuchsia 代码库。预计全局审批主要用于以下情况：更改是系统性的、很大程度上是机械性的，并且影响了大部分代码库。在需要紧急更改来稳定树的情况下，全局审批可能也适用，例如用于停用测试的 CL 或无法自动批准的复杂回滚。

目前，Fuchsia 工程委员会的成员是全球审批者，此外还有少量审核者负责处理没有 FEC 成员的时区中的请求。如果提交者遇到现有代码所有者无法提供审核覆盖率的情况，建议先发送更改来更新本地 OWNERS 文件，或添加顶级文件级规则来覆盖特定类型的文件，例如 **/BUILD.gn 或 **/*.md。如果上述方法不足以解决问题，提交者应发送电子邮件至 owners-override@fuchsia.dev 讨论该问题。

职责

除了成员、提交者和所有者的职责之外，全局审批者还负责以下事项：

• 在 Gerrit 中使用 Owners-override +1 批准 Fuchsia 代码库中的大规模变更。
• 及时审核大规模变更。

代码审核操作

您可以提供的代码审核操作类型取决于您在 Fuchsia 项目中的角色。

启动 CQ 试运行

CQ 试运行会针对提交队列中的可用测试运行您的更改。 提交者、所有者和全局审批者可以启动 CQ 试运行。

对代码审核进行评分

代码审核

您请求代码审核后，审核者可以为您的更改评分。

审核者可以为您的更改添加 -2、-1、0、+1 或 +2 的评分。 如需详细了解审核标签定义，请参阅 Gerrit 代码审核 - 审核标签。

提交者、所有者和全局审批者可以对代码审核进行评分，但只有全局审批者或代码库所有者可以给出 +2。

提交已获批准的更改

您需要获得 Code Review Label +2 才能提交更改。Code-Review 标签 +2 分数只能由代码库所有者或全局审批者应用。

提交更改后，更改会移至提交队列 (CQ)。 提交队列会验证、提交并将更改合并到主分支。

角色矩阵

下表总结了每种 Fuchsia 贡献者角色可以执行的操作。

角色	创建变更	代码审核其他提交者的更改	提供代码审核 +2	提供 CQ+1（CQ 的试运行）	向 CQ 提交已获批准的更改	添加或移除所有者
成员	是	否	否	否	否	否
提交者	是	是	否	是	是	否
所有者（自有子树之外）	是	是	否	是	是	否
所有者（位于自己的子树中）	是	是	是	是	是	是
全局审批人	是	是	是	是	是	是

变更的生命周期

下图展示了更改推送到 Gerrit 后所经历的各个高级阶段。

专业角色

除了上述要求之外，Fuchsia 代码库中的各个区域可能还有自己的独特要求，定义了自己的角色和职责集。

API 审核人员

API 审核员负责确保 Fuchsia API 表面的质量和长期健康状况。 <0x0API 审核者共同组成了 API 委员会。

任何修改 Fuchsia API Surface 的更改都必须获得 API Council 成员的 API-Review+1，以及通常的 Code-Review+2。

如需详细了解 API 审核员的职责以及 API 委员会的运作方式，请参阅 API 委员会章程。

API Reviewer 会员资格

如需成为 API 审核员，您必须执行以下操作：

• 成为 Committer。
• 对 API 的质量和长期健康状况表现出良好的判断力。
• 根据 API 委员会章程，由 Fuchsia 项目的功能领域任命。

Eng Council member

Fuchsia 工程委员会是一个由少数高级技术领导者组成的小组，负责为 Fuchsia 提供连贯的技术愿景。工程委员会主要通过委托和批准的方式运作，在整个社区内传达工程标准、价值观和目标，然后审核并批准项目贡献者的具体工程提案。

Eng Council 会员资格

工程委员会的成员人数没有预先确定的数量。不过，为了提供连贯的技术愿景，委员会的成员人数较少。工程委员会成员由项目的管理机构任命。如需了解详情，请参阅 Fuchsia 工程委员会章程中的成员资格。

撤消权限

如果贡献者不再符合要求，其角色和相应权限可能会被撤消。

场景

以下是一些可能导致权限被撤消的示例情形，但不限于这些情形：

• 未按照 Fuchsia 行为准则行事。
• 提交者在代码审核中反复忽略可测试性最佳实践。
• 所有者阻止他人请求代码审核。
• 业主对评价请求不予回应。

流程

撤消个人在 Fuchsia 项目中的角色的流程包括以下步骤：

• 所有者向 community-managers@fuchsia.dev 提出撤消某人角色的建议，并说明理由。撤消所有者角色需要获得同一子树或更高级别子树中的所有者的批准。
  • 如果所有者不再积极贡献其关联的文件或目录，则所有权通常会被撤消。

撤消提交者角色应是一种罕见的操作，并且需要获得治理机构的批准。在撤消提交者角色的过程中，应让社区经理参与进来。

常见问题解答

作为 Fuchsia 成员，您可能对请求代码审核有以下疑问：

• 谁可以提供代码审核 +1？
  • 所有提交者、所有者和全局审批者。代码审核 +1 表示“Looks Good To Me”（在我看来不错），但仅有 +1 无法提交。其他人必须使用 +2 批准相应更改。如需详细了解审核标签定义，请参阅 Gerrit 代码审核 - 审核标签。
• Fuchsia 源代码的特定部分是否可以有不同的要求？
  • 可以。例如，API 更改有特殊要求，如 Fuchsia API 委员会章程中所述。
• 我是否需要 API-Review +1？
  • 影响 Fuchsia API Surface 的更改需要 API-Review +1，并且代码审核工具仅在需要时显示 API-Review 标志。