Fuchsia 贡献者角色

概览

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

原则

Fuchsia 项目中的角色力求遵循以下原则：

• 透明度。对于角色和要求，我们秉持公开透明的原则。
• 包容性。Fuchsia 允许任何人为该项目做贡献，无论他们的雇主如何。我们相信，来自多元化、开源社区的贡献对于改进 Fuchsia 至关重要。
• 责任感。如果用户不再满足相关要求，则其角色和权限可能会被撤消。

角色

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

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

成员

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

职责

成员有责任按照紫红色行为准则行事。

成为会员

要成为会员，您必须做到以下几点：

• 签署 Google Developers 的贡献者许可协议。
• 确认紫红色行为准则。

提交者

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

提交者不仅能进行更改，还能证明自己能够与 Fuchsia 社区的其他成员有效协作。协作活动的示例包括但不限于：

• 寻找知识最渊博的人员来审核他们的代码更改。
• 贡献经过充分测试的优质代码。
• 修复代码或测试中的 bug。

成员可以成为具有不同贡献内容的提交者。例如，处理文档或工具链的人员可以通过贡献高质量的文档或配置更改来满足成为提交者的要求，这不符合经过充分测试的代码的“传统”标准。

如需提交 Gerrit 更改，提交者必须是受影响文件的所有者或获得受影响文件所有者的批准。

职责

提交者负责以下事项：

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

成为提交者

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

• 为项目贡献 10 个重要的补丁，展现您编写经过充分测试的优质代码的能力。
• 由已审核过您的代码的当前提交者提名。
• 由已审核过代码的另外两名提交者提供支持。
• 确保您的提名不会被任何提交者阻止。

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

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

另外两名提交者需要接受您的提名。如果在 5 个工作日（美国）内无人表示异议，那么您就是提交者。如果有任何人反对或想要了解更多信息，提交者会展开讨论并通常在 5 个工作日内达成共识。如果问题无法解决，由当前提交者进行投票。

大功告成！您无需采取任何进一步的行动。提交者做出决定后，会与您联系。

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

您获得现有提交者的批准后，Fuchsia 社区管理员会将您添加到 committers@fuchsia.dev，为您提供有关以外部贡献者提交贡献的更多信息。

试用作业访问权限

如果您贡献了补丁，但还不是提交者，您可能希望能够直接在尝试服务器上运行作业，而不是要求提交者或审核者为您执行此操作。

获取 try 作业访问权限的过程如下：

• 您可以请与您合作的提交者（例如，审核常客）向 committers@fuchsia.dev 发送电子邮件，推荐您试用作业。
• 您必须提供一个电子邮件地址，并至少简要说明一下您希望获得相应访问权限的原因。
• 最好同时提供姓名和关联公司（如果有）。
• 已经发布一些补丁非常有用，但并非绝对必要。
• 如果在两个工作日内没有人反对，您将获得批准访问。授权可能还需要几天时间才能传播到所有系统。

企业主

Owner 对 Fuchsia 项目中的文件或目录负责，并全面了解该子树中的代码。OWNERS 文件中列出了所有者。对于不由所有者负责的目录或文件，所有者与提交者拥有相同的权限。

建议提交者使 OWNERS 文件保持最新。

职责

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

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

成为所有者

要成为所有者，您必须做到以下几点：

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

全球审批人

全球审批人是 Owner-override@fuchsia.dev 群组的成员。全局审批者可以调用 Gerrit 中的所有者替换位，这样就免除了对更改的 OWNERS 要求。

虽然全球审批者能够针对大规模更改提供所有者替换 +1 建议，但全球审批者并不需要全面了解整个 Fuchsia 代码库。预计全球审批将主要用于此类更改是系统性的，主要是机械的，并且会影响大部分代码库。

目前，Fuchsia Engineering Council 的成员既是全球批准者，也是少量审核者，以涵盖没有 FEC 成员的时区。如果提交者遇到现有代码所有者无法提供审核覆盖范围的情况，我们建议先发送更改以更新本地 OWNERS 文件，或添加针对某一文件的顶级规则，以涵盖特定类型的文件，例如 **/BUILD.gn 或 **/*.md。如果这被证明不充分，提交者应发送电子邮件至 Owner-override@fuchsia.dev 讨论相关问题。

职责

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

• 通过在 Gerrit 中使用所有者替换 +1 来批准在 Fuchsia 代码库中进行大规模更改。
• 及时审核大规模的更改。

代码审核操作

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

启动 CQ 试运行

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

为代码审核评分

代码审核

在您申请代码审核后，审核者可以对您的更改进行评分。

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

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

提交已获批准的更改

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

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

角色矩阵

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

角色	创建更改	代码 - 审核其他提交者的更改	提供代码审核 +2	提供 CQ+1（CQ 试运行）	将已批准的更改提交到 CQ	添加或移除所有者
成员	是	否	否	否	否	否
提交者	是	是	否	是	是	否
Owner（拥有的子树外部）	是	是	否	是	是	否
Owner（在自己的子树中）	是	是	是	是	是	是
全球审批者	是	是	是	是	是	是

变更的生命周期

下图描述了在将更改推送到 Gerrit 后更改的概要阶段。

专用角色

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

API 审核者

API 审核者将共同组建 API 委员会。

除了通常的 Code-Review+2 之外，任何修改 Fuchsia API Surface 的更改还必须收到 API 委员会成员的 API-Review+1。

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

API 审核者成员资格

要成为 API 审核者，您必须做到以下几点：

• 是提交者。
• 对 API 的质量和长期运行状况做出明智的判断。
• 根据 API 委员会章程，由 Fuchsia 项目的职能部门任命。

工程委员会成员

Fuchsia 工程委员会是一个由高级技术主管组成的小规模群体，负责为 Fuchsia 提供一致的技术愿景。工程委员会主要通过委托和批准运作，在整个社区中传达工程标准、价值和目标，然后审核和批准项目贡献者提出的具体工程提案。

工程委员会成员

工程委员会没有预定人数。不过，为了提供一致的技术愿景，该委员会仅设立了一小部分成员。工程委员会成员由项目的管理机构任命。如需了解详情，请参阅 Fuchsia 工程委员会章程中的成员资格。

撤消权限

当贡献者不再满足要求时，其角色和相应权限可能会被撤消。

场景

撤消权限的示例场景包括但不限于：

• 未遵守紫红色行为准则。
• 提交者在代码审核中屡次忽略可测试性最佳实践。
• 所有者煽动用户拒绝请求代码审核。
• 所有者未回复审核请求。

流程

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

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

撤消提交者角色应该很少见，并且需要获得政府机关的批准。社区管理员应参与撤消提交者角色的过程。

常见问题解答

作为 Fuchsia 成员，您可能有以下关于请求代码审核的问题：

• 谁可以提供代码审核 +1？
  • 所有提交者、所有者和全局审批者。代码审核 +1 的意思是“看起来不错”，但仅凭 +1 是无法提交内容的。 必须有人批准此更改，并获得 +2 的批准。如需详细了解评价标签的定义，请参阅 Gerrit 代码审核 - 评价标签。
• Fuchsia 源代码的特定部分可以有不同的要求吗？
  • 可以。例如，API 变更具有 Fuchsia API 委员会章程中所述的特殊要求。
• 我需要 API-Review +1 吗？
  • 影响 Fuchsia API Surface 的更改需要 API-Review +1，并且代码审核工具仅在需要时显示 API 审核标志。