| RFC-0001：Fuchsia 请求意见稿 (RFC) 流程 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 用于做出项目级技术决策的流程。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2020-02-20 |
| 审核日期（年-月-日） | 2020-02-27 |
摘要
Fuchsia RFC 流程旨在提供一致且透明的方式来做出项目级技术决策。例如，RFC 流程可用于改进项目路线图和系统架构。
设计初衷
目前，Fuchsia 项目没有用于做出项目级技术决策的正式流程。在我们目前的规模下，这种非正式性会导致不同人对项目的进展和系统的组合方式有不同的看法，有时甚至不一致。通过建立一致且透明的项目级技术决策制定流程，所有利益相关方都可以对项目的技术方向充满信心。
设计
本部分介绍了 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 编辑者。Eng Council 可以帮助推进讨论，例如为讨论提供额外的结构或将讨论转移到其他论坛。无论讨论如何进行，任何非 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 不应推进的程度。将代码审核标志设置为 -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 标记为“Code-Review +2”，这样您就可以提交 RFC 了！
恭喜！您为项目贡献了一个有价值的工程工件！
如何做出判定
是否接受 RFC 由工程委员会决定，他们会在大致达成共识后做出决定。如果决策涉及的 RFC 的作者是工程委员会成员，则这些成员必须回避决策。
如果工程委员会无法达成大致共识，则 RFC 将不予接受。在决定是否接受 RFC 时，工程委员会会考虑以下因素：
- RFC 是否有助于推进项目目标？
- RFC 是否遵循项目的价值？
- 所有利益相关方是否在讨论中得到了适当的代表？
- 如果有任何利益相关方提出异议，工程委员会是否完全了解这些异议？
工程委员会做出的决定可以上报给项目的管理机构。
文档
此 RFC 可用作 RFC 流程的文档。
缺点、替代方案和未知
实施此方案的主要成本是，引入正式的决策流程可能会减慢决策速度。对于某些类型的决策，此流程可能过于繁琐。
在源代码库中记录决策会使这些决策更难更改。在某些情况下，这种影响可能是积极的，但在其他情况下，这种影响也可能是负面的。
“何时使用该流程”部分中的标准试图通过将流程范围限定为具有后果的情况来缓解这一缺点，但这种范围限定必然会产生假正例和假负例。
有许多可能的替代策略可用于解决根本问题。例如，我们可以使用以同步会议为中心的决策流程，但此类流程很难扩展到全球开源项目。我们还可以选择其他决策机制，使其更侧重于达成共识或更侧重于权威。
在先技术和参考文档
关于开源项目的决策流程，有很多先前技术。此提案深受以下现有流程的影响：
IETF RFC 流程。IETF 长期以来一直成功地运行着大规模的决策流程。本文档中介绍的流程借鉴了 IETF 流程中的许多想法，包括一些术语。
Rust RFC 流程。Rust 社区采用 RFC 流程，该流程在为类似的软件工程项目做出决策方面非常有效。本文档中介绍的过程直接模仿了 Rust RFC 流程。
Blink 实施意向流程。Chromium 项目会针对影响网页的行为运行决策流程。本文档中介绍的流程基于我（abarth）在帮助设计和运行该流程一段时间的经验。
FIDL 调整提案。Fuchsia 项目曾直接使用类似流程就 FIDL 语言做出决策。由于该决策流程取得了成功，我们才提出了此建议。