| RFC-0001：Fuchsia 评论请求 (RFC) 流程 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 制定项目范围技术决策的流程。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 |
|
| 提交日期（年-月-日） | 2020-02-20 |
| 审核日期（年-月-日） | 2020-02-27 |
总结
Fuchsia RFC 流程旨在为制定项目范围的技术决策提供一致且透明的途径。例如，RFC 流程可用于改进项目路线图和系统架构。
设计初衷
目前，Fucsia 项目还没有正式的流程来制定整个项目的技术决策。在目前的规模下，这种非正式性会导致不同的人对项目的进展和系统整合方式持有不同，有时不一致的观点。通过建立一致且透明的途径来制定整个项目的技术决策，所有利益相关方都可以对项目的技术方向充满信心。
设计
本部分介绍了 RFC 流程的设计。
何时使用此流程
对 Fuchsia 的绝大多数更改都不需要 RFC。而是可以通过代码审核流程完成这些更改。但是，对于对整个项目具有广泛影响的技术决策，需要获得更广泛的一致意见，并且必须使用 RFC 流程与项目进行社交。
以下类型的更改必须使用 RFC 流程：
更改项目路线图。项目路线图描述了对整个系统具有广泛影响的更改，这些更改通常会涉及系统的大部分内容或者跨子系统之间的边界。
对未来开发施加限制。有些决策一旦做出，就会限制系统的未来开发。我们在做出此类决定时需要非常小心，因为这些决定以后可能难以修改。
制定项目政策。项目政策对整个系统具有广泛影响，通常会影响整个项目的贡献者。例如，更改支持的语言集会影响需要调试和了解系统的所有人，即使不是每个人都使用新语言。
更改系统架构。系统架构描述了系统如何作为一个整体组合在一起。从定义上来说，更改系统架构会跨越子系统之间的边界，并且需要与许多利益相关方仔细咨询。
委派决策权。项目通常需要频繁做出几类决策，这些决策可受益于专业的专业知识。项目可以将这些决策类别的决策权委托给另一个群组或流程，而不是通过 RFC 流程做出所有这些决策。例如，我们经常需要做出关于平台 API 的决策，这会对未来的开发施加限制，但对平台 API 的每项更改都使用 RFC 流程却并不切实可行。
问题上报。最后，有争议的更改可以受益于 RFC 流程的透明度和清晰度。如果技术方向存在分歧，且无法由个别技术主管解决，则可由任一不同方或其他贡献者将决策上报至 RFC 流程。
RFC 流程还可用于其他类型的更改，这些更改将从其结构化决策方法和持久的决策记录中受益。
角色与责任
用户可通过多种角色与 RFC 流程互动：
RFC 作者。RFC 作者是撰写 RFC 的人。为 Fuchsia 做出贡献的每个人都可以成为 RFC 作者。一个给定 RFC 可以有一个或多个作者。指定 RFC 的作者负责推进该 RFC 的流程。
利益相关方。利益相关方是指与项目是否接受给定 RFC 有关联的人。利益相关方通常是 Fuchsia 贡献者，但某些 RFC 可能还有 Fuchsia 项目以外的利益相关方。例如，利益相关方可能参与了其他使用 Fuchsia 的项目，或者以其他方式受到对 Fuchsia 所做更改的影响。利益相关方并不总是直接参与有关 RFC 的讨论。相反，利益相关方通常由某些人员代表，通常是技术负责人或负责一组利益相关方的其他人员。
工程委员会。工程委员会推动讨论，并就项目是否接受 RFC 做出最终决定。
该流程的运作方式
本部分介绍了 RFC 流程所涉及的每个步骤。
第 1 步：社交
RFC 流程的第一步是将您的想法与项目进行社交。 例如，您可能已经注意到某个您认为有必要解决的问题。其他人是否知道这个问题？可能其他人已在处理该问题，或者可能掌握了有关该问题的一些背景或背景信息，对您有帮助。您越早发现这些信息，就越好。
与流程中的其余步骤相比，此步骤相对简单。本文档并未严格说明如何将您的想法进行社交。将技术理念融入社交平台本身就是一种技能。
但是，建议您先与技术主管讨论与您尝试解决的问题相关的领域，提出此主题。例如，您可能需要咨询 OWNERS 文件中的人员，了解需要修改代码库的区域才能执行您的想法。
如果您不确定如何将您的想法付诸实践，请考虑向技术主管寻求建议。他们通常拥有更多社交想法的经验，并且可能会为您指点迷津。
示例：此 RFC 通过在工程论坛中进行讨论来实现社会化，这是 Google 内部关于参与此项目的各种工程领导者的定期会议。FTP 和 CTP 流程创建者也对 RFC 进行了社交，他们拥有这些流程的良好背景和背景信息。
第 2 步：草稿
通过社交收集到所有可以实现的背景和背景信息后，您就可以开始 RFC 流程的正式环节了。下一步是编写 RFC 文档本身的初稿。
从机制上讲，RFC 是 //docs/contribute/governance/rfcs 目录中的 Markdown 文件。要创建 RFC，您需要创建一个将文件添加到该目录的 CL。您应该首先复制 RFC 模板。虽然没有严格要求，但该模板旨在提示您考虑要以半结构化方式解决的问题，从而指导您编写高质量的 RFC。
在此阶段，您无需担心为 RFC 分配号码。请改用 0000 作为占位符。例如，文件名应类似于 0000_my_idea.md。一旦获得批准或被拒绝，RFC 会在着陆之前获得一个编号。
建议。在您准备好接收反馈之前，请考虑将包含 RFC 的 CL 标记为“进行中”。
第 3 步：迭代
创建包含 RFC 初稿的 CL 后，您就可以与相应的利益相关方一起迭代您的想法。希望您在将想法进行社会化的过程中已经发现了大多数合适的利益相关方，但在此阶段，您很可能会发现其他利益相关方。
与普通代码审核一样，您应该邀请利益相关方提供有关您的 RFC 的反馈，只需将其添加到 CL 中的“审核者”或“抄送”字段即可。利益相关方应通过在代码审核工具中评论您的 RFC 来向您提供反馈。
如果讨论对于代码审核工具来说过于复杂，请考虑安排与利益相关方的会议，以便进行更高效的讨论。会议结束后，您必须在 CL 的评论中发布会议摘要，以便未参加会议的人员了解会议期间的讨论内容。
如果讨论有争议，请上报给某位 RFC 编辑者。工程委员会可以帮助推进讨论，例如，为讨论提供额外的结构或将讨论移至其他论坛。无论讨论如何进行，任何 CL 之外的讨论的结果都必须记录在 CL 中，通常是以 CL 注释的形式发布讨论摘要。
如果您想撤回 RFC，则可以将包含 RFC 的 CL 标记为已放弃。如果情况发生变化，您或其他人可以随时恢复您的 RFC。如果您要恢复他人创建的 RFC，则应从头开始执行 RFC 流程，但您可以使用撤消的 RFC 作为起点，而不是使用 TEMPLATE.md。请与原始作者协商，确定他们是否希望继续将其姓名与新的 RFC 版本相关联。
建议。如果您对 RFC 感兴趣，不妨考虑将 Gerrit 代码审核工具配置为在 CL 修改
//docs/contribute/governance/rfcs目录时向您发送电子邮件 > 通知。
第 4 步：批准
当 RFC 的迭代收敛后，您就可以进入审批阶段了，在此阶段，利益相关方通过将 Code-Review 标志设置为 +1 或 +2 来签核 RFC。通常情况下，需要审批 CL（即 RFC 后续需经您签核的利益相关方）应以 +2 签核，而不需要审批的利益相关方应通过 +1 签核，但如果所有利益相关方希望表达自己对 RFC 的热情，可以使用 +2 签核。
如果利益相关方希望反对 RFC，可以将 Code-Review 标志设置为 -1 或 -2，具体取决于他们认为 RFC 不应继续推进的强烈程度。将 Code-Review 标记设为 -1 或 -2 时，利益相关方必须说明他们提出异议的理由，理想的方式是让他们能够清楚地了解异议，而不必阅读异议之前的完整讨论内容。
将 Code-Review 标志设置为 -1 或 -2 的利益相关方不一定会阻止项目接受 RFC。请参阅下文中的“如何做出决策”部分，详细了解项目如何决定是否接受 RFC。
在所有利益相关方就其代码审核标志做出权衡后，发送电子邮件至 eng-council@fuchsia.dev，提示工程委员会决定是否接受您的 RFC。
第 5 步：提交
如果项目决定接受您的 RFC，工程委员会的成员会对您的 CL 发表评论，声明 RFC 已被接受，并将为 RFC 分配一个数字（通常是系列中的下一个可用编号）。如果存在任何 -1 或 -2 代码审核标志，工程委员会将总结异议，并说明尽管存在异议，RFC 为何继续推进，以明确清除每个标志。
如果项目决定拒绝您的 RFC，工程委员会的成员会对您的 CL 发表评论，说明 RFC 被拒并提供拒绝理由。遭拒的 RFC 是有价值的工程工件。工程委员会将与 RFC 作者合作，提交标记为“已拒绝”的 RFC 版本，并纳入理由。
您应在 RFC 标题和文件名中上传带有指定编号的新 RFC 补丁集。如果您的 RFC 获得批准并需要实现，请确保您已在问题跟踪器中提交问题，并在 RFC 标头中添加指向该问题的链接。
然后，工程委员会会标记您的 CL 代码审核 +2，然后您就可以提交您的 RFC！
恭喜！您已为该项目贡献了一个有价值的工程工件！
决策方式
工程委员会通过彼此粗略共识来决定是否接受 RFC。如果此决定涉及将工程委员会成员作为作者的 RFC，这些成员必须自行撤回此决定。
如果工程委员会无法达成粗略共识，则不接受 RFC。 在决定是否接受 RFC 时，工程委员会将考虑以下因素：
- RFC 是否提高了项目的目标？
- RFC 是否支持项目的值？
- 所有相关负责人是否都能以适当的方式参与讨论？
- 如果有利益相关方提出异议，工程委员会是否充分了解这些异议？
工程委员会的决定可以上报给项目的管理机构。
文档
此 RFC 可用作 RFC 流程的文档。
缺点、替代方案和未知情况
实施此方案的主要代价是引入正式的决策流程可能会减慢决策速度。该过程可能会比某些类型的决策所需的工作更繁重。
将决策记录在源代码库中会使其更难以更改。这种影响在某些情况下可能是积极的，但在其他情况下也可能是负面影响。
“何时使用此流程”部分中的条件试图通过将流程限定为继发情况来减轻这种缺陷，但这样的范围难免会出现假正例和假负例。
对于解决底层问题，有许多可能的替代策略可供选择。例如，我们可以采用以同步会议为中心的决策流程，但这样的流程很难扩展到全球开源项目。我们还可以选择另一种决策机制，在共识或权力方面更平衡。
早期技术和参考资料
关于开源项目的决策流程，已有大量技术经验。此方案受到以下现有流程的强烈影响：
IETF RFC 流程。IETF 长时间进行过成功的大规模决策过程。本文档中介绍的流程从 IETF 流程中汲取了大量灵感，包括一些术语。
Rust RFC 流程。Rust 社区运行了 RFC 流程，该流程在为一些类似的软件工程项目做出决策方面卓有成效。本文档中介绍的流程相当直接地在 Rust RFC 流程的基础上进行了建模。
Blink intent 实现流程。针对影响网页的行为，Chromium 项目会运行一个决策流程。本文档中描述的过程基于我（abarth）帮助设计并运行该流程一段时间的经验。
FIDL 调整提案。Fuchsia 项目曾直接体验过使用类似的流程做出有关 FIDL 语言的决策。之所以提出该方案，是因为该决策过程的成功。