Fuchsia 贡献者角色

概览

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

原则

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

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

角色

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

成员

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

职责

成员有责任按照 Fuchsia 行为准则行事。

成为会员

如需成为会员，您必须满足以下条件：

提交者

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

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

  • 寻找最具专业知识的人员来审核其代码更改。
  • 贡献经过充分测试的高质量代码。
  • 修复代码或测试中的 bug。

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

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

职责

提交者负责以下事项：

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

成为提交者

如需成为提交者，您必须满足以下条件：

  • 向项目贡献 10 个非琐碎的补丁，证明您能够编写经过充分测试的高质量代码。
  • 由已审核您代码的现有提交者提名。
  • 获得另外两位已审核您代码的提交者支持。
  • 确保您的提名不会被任何提交者屏蔽。

现有提交者可以向 committers@fuchsia.dev 发送电子邮件，提名您成为提交者，并在邮件中提供以下信息。请勿在提名电子邮件中抄送提名对象。

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

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

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

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

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

试用作业访问权限

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

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

  • 请与您合作的提交者（例如经常进行审核的人员）向 committers@fuchsia.dev 发送电子邮件，提名您获得试用作业访问权限。
  • 您必须提供电子邮件地址，并且至少简要说明您想要访问该账号的原因。
  • 同时提供姓名和公司隶属关系（如果有）也很有帮助。
  • 已经发布了一些补丁会非常有帮助，但不是绝对必要的。
  • 如果在 2 个（美国）工作日内没有人提出异议，我们会批准您访问该资源。授权可能还需要几天时间才能传播到所有系统。

所有者

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

我们建议提交者及时更新 OWNERS 文件。

职责

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

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

成为所有者

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

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

全球审批人

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

虽然全局审批人有权对大规模更改提供“Owners-override +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。

提交已获批准的更改

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

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

角色矩阵

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

角色 创建更改 对其他提交者的更改进行代码审核 提供代码审核 +2 提供 CQ+1（CQ 的模拟运行） 将已获批准的更改提交给 CQ 添加或移除所有者
成员 是 否 否 否 否 否
提交者 是 是 否 是 是 否
所有者（位于所拥有的子树之外） 是 是 否 是 是 否
所有者（在自己的子树中） 是 是 是 是 是 是
全球审批人 是 是 是 是 是 是

更改的生命周期

下图概述了更改推送到 Gerrit 后会经历的阶段。

alt_text

专门的角色

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

API 审核员

API 审核员负责确保 Fuchsia API Surface 的质量和长期运行状况。 API 审核员共同组成 API 委员会。

除了常规的 Code-Review+2 外，任何修改 Fuchsia API Surface 的更改都必须获得 API 委员会成员的 API-Review+1。

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

API 审核员会员资格

如需成为 API 审核员，您必须满足以下条件：

  • 成为提交者。
  • 对 API 的质量和长期运行状况有良好的判断力。
  • 根据 API 委员会章程，由 Fuchsia 项目的职能领域任命。

英语委员会成员

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

英格兰工程师理事会会员

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

撤消权限

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

场景

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

  • 未遵守 Fuchsia 行为准则。
  • 提交者在代码审核中反复忽略可测试性最佳实践。
  • 所有者劝阻用户请求代码审核。
  • 所有者不回复审核请求。

流程

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

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

撤消提交者角色应该是极少数的操作，并且需要获得治理机构的批准。社区管理员应参与撤消提交者角色的流程。

常见问题解答

作为 Fuchsia 会员，您可能会对如何申请代码审核有以下疑问：

  • 谁可以提供代码审核 +1？
    • 所有提交者、所有者和全局审批人。代码审核 +1 表示“看起来不错”，但仅 +1 不允许提交。其他人必须通过 +2 来批准更改。如需详细了解审核标签定义，请参阅 Gerrit 代码审核 - 审核标签。
  • Fuchsia 源代码的特定部分是否可以有不同的要求？
  • 我需要 API-Review +1 吗？
    • 影响 Fuchsia API Surface 的更改需要 API-Review +1，并且代码审核工具仅在需要时显示 API-Review 标志。