Fuchsia 贡献者角色

概述 {:#overview}

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

原则 {:#principles}

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

• 透明性。 我们对角色和要求是透明和公开的；
• 包容性。 Fuchsia 项目允许任何人参与项目贡献，而不管他们的职业。我们认为，来自多元化、开放源代码社区的贡献对于改善 Fuchsia 至关重要；
• 责任。 如果一个人不再符合要求，角色和特权可以被撤销。

角色 {:#roles}

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

• 成员
• 提交者
• 所有者
• 终审员

成员 {:#member}

任何通过提供代码补丁或文档来为项目做出贡献的人，并且同意了谷歌开发者的 贡献者许可协议{:.external}。

责任 {:#responsibilities}

委员们有责任遵守以下 Fuchsia 行为准则。

成为一个成员 {:#become-a-member}

要成为一个成员，您需要做到以下几点：

• 签署谷歌开发者的 贡献者许可协议{:.external}。
• 了解并遵守 Fuchsia 行为准则。

提交者 {:#committer}

提交者是一种对 Fuchsia repository{:.external} 有写权限的角色。一个提交者可以提交他们自己的 Gerrit 更改或来自任何其他成员的 Gerrit 更改。

提交者不仅是能对项目做更改的人，而且是表明有能力与 Fuchsia 社区的其他成员有效合作的角色。Fuchsia 社区的其他成员合作的能力。协作活动包括但不限于：

• 寻找最有见识的人审查他们的代码更改；
• 贡献高质量、经过良好测试的代码；
• 修复代码或测试中的 bug。

成员可以通过不同方式的贡献成为提交者。举个例子，从事文档或工具链工作的人可以通过贡献高质量的文档或工具链配置来满足成为提交者的条件，但这并不符合 “传统 “的测试良好的代码。

为了提交 Gerrit 更改，提交者要么需要成为被影响文件的 所有者，要么得到被影响文件的所有者的批准。

责任 {:#responsibilities}

提交者负责以下内容:

• 确保提交者提交到 Fuchsia 的代码满足 可测试性指标 的要求；
• 确保提交者提交到 Fuchsia 的代码是测试良好的。

成为提交者 {:#become-a-committer}

要成为一个提交者，您需要做到以下几点：

• 在项目中贡献十个有意义的补丁，展示出编写高质量、经过良好测试的代码能力；
• 被当前的提交者提名；
• 从至少两个不同的提交者上，获得这十个有意义补丁的审核和批准；
• 确保您的提名得到三个提交者的支持；
• 确保您的提名没有被任何提交者反对。

提交者提名将在初始提名请求后的七个工作日内进行评估。

所有者 {:#owner}

所有者对紫红色项目中的文件或目录负责，并对该子树中的代码有全面的了解。所有者们都在 OWNERS 文件下。对于不在所有者责任范围内的目录或文件，所有者的身份就和提交者相同。

责任 {:#responsibilities}

在提交者和成员的责任基础上，作为所有者还需要做以下几点：

• 提名其他所有者；
• 批准或删除其他所有者；
• 提供高质量的评论和代码设计反馈；
• 为提交者和成员审批代码更改。

成为一个所有者 {:#become-an-owner}

要成为一个所有者，您需要做到以下几点：

• 成为一个 提交者；
• 对受影响的子树提交重大的有意义的更改；
• 提供高质量的评论和代码设计反馈；
• 及时提供代码审查；
• 自提名或被其他提交者提名；
  • 对于自提名，提交一个 Gerrit 更改 添加您的名字到您想拥有的仓库下的 OWNERS 文件。该仓库的所有者将评估您的更改并同意或拒绝您的请求。

终审员 {:#global-approver}

终审员是 根目录下 OWNERS 文件{:.external} 中的所有者。终审员通常会进行大规模更改，从而影响整个 Fuchsia 代码库。例如，终审员是倾向于维持各种语言，工具链和其他构建系统组件。

有关终审员对项目的全部政策以及当前的终审员列表，请查看 根目录下 OWNERS 文件{:.external}。

虽然终审被授权对于大规模的修改提供 代码审查+2{:.external}，但终审并不期望对整个 Fuchsia 代码库有全面的了解。

责任 {:#responsibilities}

在成员、提交者、所有者的责任基础上，作为所有者还需要做以下几点：

• 在 Fuchsia 代码库中用 +2 的方式给 Gerrit 批准大规模的修改。
• 及时为重大代码更改提供审查。

成为终审 {:#become-a-global-approver}

要成为一个成员，您需要做到以下几点：

• 在整个 Fuchsia 代码库中，展示出在进行大规模变更方面的熟练程度；
• 自提名或被其他提交者提名；
  • 对于自提名，应该满足：
    • 提交一个 Gerrit 更改 添加您的名字到 根目录下的 OWNERS 文件{:.external}。该仓库的所有者将评估您的更改并同意或拒绝您的请求。
    • 向所有 现有的终审们{:.external} 发送电子邮件，说明您的相关 Gerrit 变更，并等待一个工作日的讨论和批准。现有的全球批准人将通过电子邮件发送给您，以提名您。

代码审查动作 {:#code-review-actions}

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

建立一个代码质量演示 {:#initiate-a-cq-dry-run}

代码质量演示（译文注：CQ Dry Run）是根据“提交队列”中的可用测试运行你的更改。提交者、所有者、和终审员都可以建立一个代码质量演示。

评分代码审查 {:#score-code-reviews}

代码审查 {:#code-review}

在您请求代码审查后，审查人可以对您的更改进行评分。

审查人可以为您的更改打上 -2, -1, 0, +1, 或 +2 的分数。有关审查标签定义的更多信息，请查看 Gerrit 代码审查 - 审查标签{:.external}

提交者、所有者、和终审员都可以评分代码审查，但是只有终审员或者仓库的所有者可以提供 +2 的评分。

提交批准的更改 {:#submit-approved-changes}

你需要代码审查标签 +2 来提交你的更改。一个代码审查标签 +2 分只能被仓库所有者或终审员使用。

当一个更改被提交（译文注：submit）后，更改会被移到提交队列中（CQ）。提交队列核实、提交（译文注：commit）、合并更改到主分支。

角色表 {:#role-matrix}

这个表格总结每个 Fuchsia 贡献者角色的作用。

更改的流程 {:#life-of-a-change}

下图描述了将更改推送到 Gerrit 之后发生什么变化的高级阶段。

专门的角色 {:#specialized-roles}

Fuchsia 代码库中的区域可能有其独特的要求，除了上面详述的内容之外，还需要定义自己的角色和责任。

API 审查员 {:#api-reviewer}

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

除了通常的 代码审查 +2 之外，修改 Fuchsia API Surface 的任何更改必须获得由API委员会成员提供的 API 审查 +1。

更多关于 API 审查员的责任和 API 委员会如何工作的详情，请查看 API 委员会章程

API 审查员成员资格 {:#api-reviewer-membership}

要成为一个 API 审查员，您需要做到以下几点：

• 成为一个 提交者；
• 表现出对 API 的质量和长期运行状况的良好判断。
• 被 Fuchsia 项目的功能区委托，按照 API 委员会章程

工程师委员会成员 {:#eng-council-member}

Fuchsia 工程师委员会是高级技术领导人的小组，负责为 Fuchsia 提供一致的技术远景。工程师委员会主要通过授权和批准来运作，在整个社区中交流工程标准，价值和目标，然后审查和批准项目贡献者提出的具体工程建议。

工程师委员会资格 {:#eng-council-membership}

工程师委员会没有预定的人数。通常情况下，但是，为了提供一致的技术远景，委员会中有少量成员。工程师委员会成员受该项目的管理机构委托。

更多关于工程师审查员的责任和 工程师委员会如何工作的详情，请查看 Fuchsia 工程师委员会章程

撤销特权 {:#revoking-privileges}

当贡献者不再符合要求，他们的角色和相应的特权将会被撤销。

情景 {:#scenarios}

撤销特权的示例情景包括但不限于以下情况：

• 不按照 Fuchsia 行为准测；
• 提交者在其代码审查中一再忽略可测试性；
• 所有者不鼓励人们请求进行代码审查；
• 所有者对审查请求没有回应。

流程 {:#process}

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

• 所有者向 community-managers@fuchsia.dev 提出建议，撤销某人的角色，并说明其理由。
  • 当所有者不再主动为其关联的文件或目录做出贡献时，所有权通常会被撤销。

撤销提交者角色应该是一种罕见的操作，并且需要得到管理机构的批准。社区管理者应参与撤销提交者角色的过程。

常见问题 {:#frequently-asked-questions}

作为一个 Fuchsia 成员，你可能会遇到如下关于请求代码审查的问题：

• 谁可以提供一个代码审查 +1？
  • 所有的提交者、所有者、和终审员。代码审查 +1 意味着“在我看来很好”，但一个 +1 不允许提交。别人必须以 +2 批准更改。有关审查标签定义的更多信息，请查看 Gerrit 代码审查 - 审查标签{:.external}
• Fuchsia 源代码的特定部分可以有不同的要求吗？
  • 是的。例如 API 修改有如上文所说的特定需要，请查看 Fuchsia API Council Charter；
• 我需要 API 审查 +1 吗？
  • 修改影响到了 Fuchsia API Surface 是需要 API 审查 +1的，并且代码审查工具将只显示 API 审查的标记当需要的时候。