Fuchsia 贡献者角色

概览

本文档定义了与以下内容相关的角色： Fuchsia 项目的一个 API。

原则

Fuchsia 项目中的角色力求体现以下原则：

  • 透明度。我们会公开透明地说明角色和要求。
  • 包容性。Fuchsia 允许任何人为项目做贡献，无论他们身在何处 我们相信，这些贡献来自多元化的开源软件， 社区对于改进 Fuchsia 至关重要。
  • 责任。如果用户未 才能满足要求

角色

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

成员

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

职责

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

成为会员

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

提交者

提交者 Fuchsia 代码库。提交者可以提交 更改自己的 Gerrit 更改，或从其他成员更改 Gerrit 更改。

提交者不仅是可以进行更改的人，还包括能够 展现出了与 其他 成员有效协作的能力。 Fuchsia 社区。协作活动的示例包括但不限于 更改为：

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

成员可以成为具有不同类型贡献的承诺者。对于 例如，处理文档或工具链的人员可以满足 通过贡献高质量的文档或配置来成为承诺者 这不符合经过充分测试的代码的“传统”标准。

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

职责

提交者负责以下方面：

  • 确保对提交者提交给 Fuchsia 的代码进行测试 以可测试性评分准则为基础。
  • 确保提交者提交给 Fuchsia 的代码遵循测试 最佳做法。

成为提交者

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

  • 为项目贡献 10 个重要的补丁，展现自己的能力 编写经过良好测试的高质量代码。
  • 由已审核您的代码的当前提交者提名。
  • 获得已审核您的代码的另外两名提交者的支持。
  • 确保您的提名没有被任何提交者阻止。

现有提交者通过向 committers@fuchsia.dev 发送包含 相关信息。请勿在提名电子邮件中抄送被提名者。

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

另外两名提交者需要对你的提名进行二次提名。如果 5 个工作日内无人提出异议（美国）， 你是提交者如果有人反对或想要了解更多信息，提交者会讨论 在 5 个工作日内达成一致意见。如果问题无法得到解决，则进行投票 当前提交者。

大功告成！您无需采取进一步行动。提交者将返回到 会及时向您提供帮助

在最坏的情况下，这一过程可能会延迟两周。继续写入补丁！即使是在极少数情况下， 如果提名失败，异议通常很容易解决，例如“提供更多补丁”或 “没有足够的人熟悉这个人的工作。”

获得现有提交者的批准后，Fucsia 社区管理者会将您添加到 committers@fuchsia.dev，并提供有关如何提交贡献的其他信息 作为外部贡献者

尝试作业访问

如果您正在贡献补丁，但尚未（尚未）提交提交者，您可能希望能够在 而不是让提交者或审核者为您代劳。

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

  • 请求与您合作的提交者（例如经常审核者）发送电子邮件到 committers@fuchsia.dev 推荐您申请试用职位访问权限。
  • 您必须提供电子邮件地址，并至少简要说明您希望获取访问权限的原因。
  • 此外，提供名称和关联公司（如果有）会很有帮助。
  • 已经发布一些补丁非常有用，但并非绝对必要。
  • 如果在两个工作日内（美国）内无人提出反对意见，您将获得批准访问。这可能需要 额外几天的时间让授权传播到所有系统。

所有者

Owner 负责 Fuchsia 项目中的文件或目录，以及 全面了解该子树中的代码。所有者列于 OWNERS 文件。对于所有者文件夹以外的目录或文件， 该 Owner 将拥有与 Committer 相同的权限。

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

职责

除了承诺者和成员的职责之外，负责人 负责以下事项：

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

成为所有者

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

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

全局审批人

全局审批者是 owner-override@fuchsia.dev 的成员 。全局审批者可以在 Gerrit，这放弃了变更的 OWNERS 要求。

而全局审批者则有权提供所有者替换 +1， 全球审批人员 全面了解整个 Fuchsia 代码库。符合预期 全球批准主要在更改 并且很大程度上是机械的，并且影响很大一部分 代码库。如果需要获得全球认可， 需要进行紧急更改以稳定树，例如使用 CL 来停用 测试或复杂的还原操作，无法自动批准。

目前，Fuchsia Engineering Council 的成员遍布全球 以及少量审核者以涵盖不同时区 没有任何 FEC 成员。提交者会遇到 代码所有者无法提供审核覆盖率，建议先 发送更改以更新本地 OWNERS 文件，或添加一个 按文件创建顶级规则，以涵盖特定类型的文件，例如 **/BUILD.gn 或 **/*.md。如果事实并非如此， 提交者应发送电子邮件至 owner-override@fuchsia.dev 来讨论 问题。

职责

除了成员、承诺者和负责人的职责之外， 审批人有责任执行以下操作：

  • 使用 在 Gerrit 中，所有者替换 +1。
  • 针对大规模更改及时进行审核。

代码审核操作

您可以提供的代码审核操作类型取决于您 Fuchsia 项目的一个 API。

启动 CQ 试运行

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

对代码进行评分

代码审核

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

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

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

提交已批准的更改

您需要使用代码审核标签 +2 才能提交更改。答 代码审核标签 +2 得分只能由代码库所有者或 全局审批人。

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

角色矩阵

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

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

变更的生命周期

下图大致描述了更改发生后的大致阶段 将映像推送到 Gerrit

alt_text

专用角色

Fuchsia 仓库中的区域可能有自己独特的要求， 定义自己的角色和职责的集合， 。

API 审核者

API 审核人员负责确保 运行状况 Fuchsia API Surface ，了解所有最新动态。 API 审核者共同构成 API 委员会。

任何会修改 Fuchsia API Surface 的变更都必须收到 API-Review+1。 除了常规的 Code-Review+2 之外，Google Workspace 也由 API 委员会成员提出。

有关 API 审核者的职责以及 API 如何 该委员会负责运作，请参阅 API 委员会章程。

API 审核者成员资格

要成为 API 审核者，您必须执行以下操作：

  • 成为承诺者。
  • 准确判断 API 的质量和长期运行状况。
  • 根据 API 理事会章程，由 Fuchsia 项目的职能领域任命。

工程委员会成员

Fuchsia Eng Council 由负责负责相关事务的高级技术领导小组 为 Fuchsia 提供了一致的技术愿景。英国工程委员会主要 其运作方式包括委托和批准、传达工程标准、 价值和目标，然后再进行审查和审批 项目贡献者提供的具体工程方案。

工程委员会成员资格

工程委员会并未预先确定具体人数。不过，为了 为提供连贯的技术愿景，委员会有少量 成员。工程委员会成员由 项目。如需了解详情，请参阅成员资格 。

撤消权限

当贡献者不再满足要求时，他们的角色和 相应的权限可以撤消。

场景

权限被撤消的示例情况包括但不限于： 以下：

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

流程

撤销个人在 Fuchsia 项目中的角色的流程 涉及以下步骤：

  • 所有者向community-managers@fuchsia.dev提出了建议 撤消某人的角色，并说明理由。撤消 Owner 角色 需要由同一子树中的 Owner 批准 或更高级别。
    • 当所有者不再活跃时，所有权往往会被撤消 为其关联的文件或目录贡献内容。

撤消提交者角色应该很少见，并且需要获得 治理权力社区管理者应参与 可以撤消 Committer 角色。

常见问题解答

作为 Fuchsia 成员，您在申请 代码审核：

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