Fuchsia RFC 流程

Fuchsia RFC 流程从以下 RFC 发展而来：

• RFC-0001：Fuchsia 评论请求流程
• RFC-0006：Zircon 的 RFC 流程附录
• RFC-0067：向 Fuchsia RFC 流程添加内容
• RFC-0017：FTP 流程已终止，RFC 流程万岁！
• RFC-0122：RFC 利益相关方

此页面会整理上述 RFC 并捕获当前流程。

查看此过程后，您可以按照此指南来创建 RFC。

总结

Fuchsia RFC 流程旨在为制定项目范围的技术决策提供一致且透明的途径。例如，RFC 流程可用于改进项目路线图和系统架构。

设计初衷

在 RFC 流程之前，Fucsia 项目没有正式的流程来制定整个项目的技术决策。在目前的规模下，这种非正式性会导致不同的人对项目的进展和系统整合方式持有不同，有时不一致的观点。通过建立一致且透明的途径来制定整个项目的技术决策，所有利益相关方都可以对项目的技术方向充满信心。

设计

本部分介绍了 RFC 流程的设计。

何时使用此流程

RFC 流程可用于对 Fuchsia 的任何更改，从其结构化决策方法和持久的决策记录中受益。

绝大多数更改不需要 RFC。require而是可以通过代码审核流程完成这些更改。但是，对于对整个项目具有广泛影响的技术决策，需要获得更广泛的一致意见，并且必须使用 RFC 流程与项目进行社交。

以下类型的更改必须使用 RFC 流程：

• 对未来开发施加限制。有些决策一旦做出，就会限制系统的未来开发。我们在做出此类决定时需要非常小心，因为这些决定以后可能难以修改。

• 制定项目政策。项目政策对整个系统具有广泛影响，通常会影响整个项目的贡献者。例如：更改一组支持的语言（会影响需要调试和了解系统的所有人）、废弃广泛使用的 API，以及针对各种代码更改更改测试要求。

• 更改系统架构。系统架构描述了系统如何作为一个整体组合在一起。从定义上来说，更改系统架构会跨越子系统之间的边界，并且需要与许多利益相关方仔细咨询。

• 委派决策权。项目通常需要频繁做出几类决策，这些决策可受益于专业的专业知识。项目可以将这些决策类别的决策权委托给另一个群组或流程，而不是通过 RFC 流程做出所有这些决策。例如，我们经常需要做出关于平台 API 的决策，这会对未来的开发施加限制，但对平台 API 的每项更改都使用 RFC 流程却并不切实可行。

• 问题上报。最后，有争议的更改可以受益于 RFC 流程的透明度和清晰度。如果技术方向存在分歧，且无法由个别技术主管解决，则可由任一不同方或其他贡献者将决策上报至 RFC 流程。

除了上述一般性考虑因素之外，一些方面还会声明其他条件。请参阅以下文档（若相关）：

领域	条件 RFC
组件框架	RFC-0098
FIDL	RFC-0049
软件交付	RFC-0103
锆石	RFC-0006

可能受益于 RFC 流程的其他更改是需要手动或自动对代码库进行大规模更改的更改。例如，如何编写日志或如何处理错误路径。开发者希望找到最佳模式并将其统一应用于整个代码库，而不是孤立于一致性孤岛中。

角色与责任

用户可通过多种角色与 RFC 流程互动：

• RFC 作者。RFC 作者是撰写 RFC 的人。为 Fuchsia 做出贡献的每个人都可以成为 RFC 作者。一个给定 RFC 可以有一个或多个作者。指定 RFC 的作者负责推进该 RFC 的流程。

• 工程委员会。工程委员会 (FEC) 会推动讨论，并就项目是否接受 RFC 做出最终决定。

• 教员。FEC 指定的人员，通过 RFC 流程照管此 RFC。目前，此人必须是 FEC 成员。

• 利益相关方。利益相关方是指与项目是否接受给定 RFC 有关联的人。利益相关方通常是 Fuchsia 贡献者，但某些 RFC 可能还有 Fuchsia 项目以外的利益相关方。例如，利益相关方可能参与了其他使用 Fuchsia 的项目，或者以其他方式受到对 Fuchsia 所做更改的影响。利益相关方并不总是直接参与有关 RFC 的讨论。相反，利益相关方通常由某些人员代表，通常是技术负责人或负责一组利益相关方的其他人员。

• 审核者。当 FEC 决定接受或拒绝 RFC 时，系统会考虑 +1 或 -1 的利益相关方。（虽然 +2 表示代码 CL 的“批准”，但我们倾向于让评估人员通过 +1 或 -1 来表明他们支持还是不赞同，并且希望教员在获得批准后对其 +2。）

• 咨询。已就 RFC 征求反馈，但在 FEC 决定接受或拒绝 RFC 时，不考虑其 +1 或 -1 的利益相关方。

该流程的运作方式

本部分介绍了 RFC 流程所涉及的每个步骤。

第 1 步：社交

RFC 流程的第一步是将您的想法与项目进行社交。 例如，您可能已经注意到某个您认为有必要解决的问题。其他人是否知道这个问题？可能其他人已在处理该问题，或者可能掌握了有关该问题的一些背景或背景信息，对您有帮助。您越早发现这些信息，就越好。

请注意，在开始此步骤之前，不需要深化这种思路。 最好尽早开始社交，以获得反馈，以了解想法是否可行以及方向是否正确。这样可以为作者节省时间和精力，以防想法未实现或方向需要重大更改。

虽然从机械角度来看，RFC 采用通过 Gerrit 代码更改审核的 Markdown 文件，在社交阶段使用比代码审核更动态的媒介（例如 Google 文档或其他）更有益。如果选择另一种媒介进行社交，强烈建议将相关上下文从较为动态的媒介中转交给 RFC 撰写。例如，来回对话可能会导致添加其他“已考虑的替代方案”条目。

与流程中的其余步骤相比，此步骤相对简单。本文档并未严格说明如何将您的想法进行社交。将技术理念融入社交平台本身就是一种技能。 但是，建议您先与技术主管讨论与您尝试解决的问题相关的领域，提出此主题。例如，您可能需要咨询 OWNERS 文件中的人员，了解需要修改代码库的区域才能执行您的想法。

在此阶段，RFC 作者应开始确定此 RFC 的利益相关方。

如果您不确定如何将您的想法付诸实践，请考虑向技术主管寻求建议。他们通常拥有更多社交想法的经验，并且可能会为您指点迷津。

示例。此 RFC 通过在工程论坛中进行讨论来实现社会化，这是 Google 内部关于参与此项目的各种工程领导者的定期会议。FTP 和 CTP 流程创建者也对 RFC 进行了社交，他们拥有这些流程的良好背景和背景信息。

退出条件：没有明确说明。这由作者自行决定。 此步骤旨在帮助作者明确目标和可能的解决方案。如果他们认为已经完成了此步骤，则可以继续执行下一步。

第 2 步：草稿

通过社交收集到所有可以实现的背景和背景信息后，您就可以开始 RFC 流程的正式环节了。下一步是编写 RFC 文档本身的初稿。

从机制上讲，RFC 是 //docs/contribute/governance/rfcs 目录中的 Markdown 文件。如需创建 RFC，您需要创建一个将文件添加到该目录的 CL。您必须先复制 RFC 模板。该模板旨在提示您考虑要以半结构化的方式解决的问题，从而指导您编写高质量的 RFC。

RFC 中包含的任何其他文件（如图表）都可以添加到 resources 目录下，位于与 RFC 本身同名的子文件夹下。示例：//docs/contribute/governance/rfcs/resources/<RFC_name>/diagram.png。

在此阶段，您无需担心为 RFC 分配号码。请改用 NNNN 作为占位符。例如，文件名应类似于 NNNN_my_idea.md。RFC 会在着陆前不久获得一个编号。

RFC 作者应与其 RFC 领域内的专家协商，建议一组初始利益相关方。这组利益相关方最初可能会留空或不完整。如有任何歧义，他们应咨询 FEC，以协助确定利益相关方。

提示：如需了解有关起草和迭代 RFC 的建议，请参阅 RFC 最佳实践文档。

建议。在您准备好接收反馈之前，请考虑将包含 RFC 的 CL 标记为“进行中”。

只需上传 CL 即可为您的 RFC 分配教员。FEC 将新的 RFC CL 作为信号进行监控，以确定适合新 RFC 的促进者。

创建包含 RFC 初稿的 CL 后，您就可以与相应的利益相关方一起迭代您的想法。希望您在将想法进行社会化的过程中已经发现了大多数合适的利益相关方，但在此阶段，您很可能会发现其他利益相关方。RFC 作者应要求 FEC 尽早确定所有利益相关方，从而降低提交步骤出乎意料的可能性。

但实际上，您应该邀请利益相关方提供有关您的 RFC 的反馈，方法是将其添加到 CL 中的“审核者”（对于需要 +1 的利益相关方）或“抄送”字段（对于“咨询的”利益相关方），就像普通代码审核一样。此外，您还可以通过电子邮件将您的 CL 发送至 eng-council-think@fuchsia.dev，以征求更多反馈。利益相关方应通过在代码审核工具中为您的 RFC 添加注释来提供反馈。

任何人都可以通过评论 RFC CL 为给定 RFC 提议其他利益相关方（包括他们自己），但这些提议有时不会被接受。如果存在广泛协议，则 RFC 作者应添加利益相关方。FEC 可能还会要求作者添加利益相关方。

利益相关方可能会选择拒绝并要求将其移除，也可能会将其审核委托给相关领域的其他专家。FEC 可以要求将某个利益相关方从“审核者”中移除或改为“咨询”。

如果讨论对于代码审核工具来说过于复杂，或者讨论所花的时间超出您的预期，请考虑安排与相关利益相关方的会议，进行更高效的讨论。会议结束后，您必须在 CL 的评论中发布会议摘要，以便未参加会议的人员了解会议期间的讨论内容。

如果您在讨论过程中遇到任何问题或延迟，请告知辅导员。以下是在这些讨论过程中会出现的一些常见问题：

• 讨论变得有争议或没有效果。通常，与文字交流相比，面对面会议可以更高效地将讨论恢复到正常状态。
• 利益相关方过于挑剔（即兴致意），或者拖慢讨论（无回应）。有时，利益相关方不喜欢提案，但没有坚实的技术理由，或许在不知不觉间，就针对这些延迟问题。
• 您收到了许多人的评论、建议和反驳，但不确定哪些评论来自相关利益相关方。此类反馈通常与核心问题无关，并且不会阻止 RFC 被接受。
• 相关讨论过于久没收敛。

如果讨论有争议，或者您难以获得利益相关方的反馈，请告知教员。您的教员可以帮助推进讨论，例如，为讨论提供额外的结构或将讨论移至其他论坛，例如同步会议或工程评审。无论讨论如何进行，任何脱离 CL 的讨论的结果都必须记录在 CL 中，通常是通过将讨论摘要发布为 CL 注释。

反馈可能包含非利益相关方的评论。作者应根据需要回复这些评论，但不必解决这些评论就进入“最后调用”阶段了。如果评论指向谁是利益相关方，FEC 可以帮助解决此问题。

如果您想撤回 RFC，则可以将包含 RFC 的 CL 标记为已放弃。如果情况发生变化，您或其他人可以随时恢复您的 RFC。如果您要恢复他人创建的 RFC，则应从头开始执行 RFC 流程，但您可以使用撤消的 RFC 作为起点，而不是使用 TEMPLATE.md。请与原始作者协商，确定他们是否希望继续将其姓名与新的 RFC 版本相关联。

审核者注意事项：RFC 流程旨在鼓励各种观点和热烈的讨论。通常情况下，在公共论坛上给出负面反馈可能很难。如果需要，审核者可以联系其负责人、同行或工程委员会，帮助他们制定反馈，以便在 CL 中有效地提供。

建议。如果您对 RFC 感兴趣，不妨考虑将 Gerrit 代码审核工具配置为在 CL 修改 //docs/contribute/governance/rfcs 目录时向您发送电子邮件 > 通知。

退出标准：工程委员会确定和批准的所有利益相关方；征集并纳入反馈。

第 3 步：上次通话

RFC 讨论接近尾声后，作者必须要求其教员将 RFC 状态移至“上次通话”。教员会将 RFC 标记为在跟踪器中的“最后一次通话”中，这会自动生成发送至 eng-council-think@fuchsia.dev 的电子邮件，并在 CL 上发表评论，在进入决策步骤之前征求任何最终反馈。在接下来的 7 个日历日里，RFC 可接受反馈。

通常情况下，评估人员可以用 +1 来签字，辅导员可以用 +2 来签字。咨询的利益相关方如果希望表达他们对 RFC 的热情，也可以用 +1 或 +2 来签字（尽管这并非强制要求）。

如果利益相关方希望反对 RFC，可以将 Code-Review 标志设置为 -1 或 -2，具体取决于他们认为 RFC 不应继续推进的强烈程度。将 Code-Review 标记设为 -1 或 -2 时，利益相关方必须说明他们提出异议的理由，理想的方式是让他们能够清楚地了解异议，而不必阅读异议之前的完整讨论内容。

将 Code-Review 标志设置为 -1 或 -2 的利益相关方不一定会阻止项目接受 RFC。请参阅下文中的“如何做出决策”部分，详细了解项目如何决定是否接受 RFC。

在所有利益相关方就其代码审核标志做出权衡后，发送电子邮件至 eng-council@fuchsia.dev，提示工程委员会决定是否接受您的 RFC。

退出条件：所有利益相关方的反馈；所有反馈均处理完毕。

第 4 步：提交

如果项目决定接受您的 RFC，工程委员会的成员会对您的 CL 发表评论，声明 RFC 已被接受，并将为 RFC 分配一个数字（通常是系列中的下一个可用编号）。如果存在任何 -1 或 -2 代码审核标志，工程委员会将总结异议，并说明尽管存在异议，RFC 为何继续推进，以明确清除每个标志。工程委员会会指出是否需要在 RFC 中记录任何其他信息，例如其他方法的理由或做出权衡。

如果项目决定拒绝您的 RFC，工程委员会的成员会对您的 CL 发表评论，说明 RFC 被拒，提供拒绝原因并为 RFC 分配一个编号。遭拒的 RFC 是有价值的工程工件。工程委员会将与 RFC 作者合作，提交标记为“已拒绝”并纳入理由的 RFC 版本。

极少数情况下，如果工程委员会识别到一个或多个未解析的开放内容，则 RFC 可能会移回“草稿”阶段。工程委员会会要求作者解决与相关利益相关方确认的待解决内容，然后才会批准其他审核 RFC 的请求。

您应在 RFC 标题和文件名中上传带有指定编号的新 RFC 补丁集。如果您的 RFC 获得批准并需要实现，请确保您已在问题跟踪器中提交问题，并在 RFC 标头中添加指向该问题的链接。

然后，工程委员会会标记您的 CL 代码审核 +2，然后您就可以提交您的 RFC！

恭喜！您已为该项目贡献了一个有价值的工程工件！

退出条件：分配的 RFC 编号；纳入所有适用的理由、权衡因素和工程委员会反馈；合并 RFC。

呼叫等待

如果您目前没有兴趣向前移动 RFC，例如因为您的优先级发生了变化，或者 RFC 想要解决的问题不再那么重要，您可以将 RFC 改为暂停状态。当 RFC 处于“暂停”状态时，利益相关方不需要提供反馈，FEC 也不会主动推动进展。

如果在一个月内，您的 RFC 的 CL 上没有明显的进度，RFC 聊天机器人将向您和教员发送一封电子邮件，提示他们讨论是否将您的 RFC 转为“暂停”状态，或如何将您的 RFC 向前推进。理想情况下，如果您遇到困难或延迟，则可以在此日期之前将这种情况上报给教员，但这次对话也是发现这些问题的好时机。

您可以随时通过联系教员并告知他们您计划恢复 RFC，让 RFC 退出“暂停”状态。如需新教员，请联系 FEC 的任何成员，他们可以为您指派新教员。此时，您的 RFC 将移回草稿阶段。

退出条件：RFC Author 表明他们希望恢复其 RFC 的有效工作的意图；教员在 CL 上发表评论，表明 RFC 不再暂停。

决策方式

工程委员会通过彼此粗略共识来决定是否接受 RFC。如果此决定涉及将工程委员会成员作为作者的 RFC，这些成员必须自行撤回此决定。

如果工程委员会无法达成粗略共识，则不接受 RFC。 在决定是否接受 RFC 时，工程委员会将考虑以下因素：

• RFC 是否提高了项目的目标？
• RFC 是否支持项目的值？
• 所有相关负责人是否都能以适当的方式参与讨论？
• 如果有利益相关方提出异议，工程委员会是否充分了解这些异议？

工程委员会的决定可以上报给项目的管理机构。

修改 RFC 的流程

如果满足以下条件，就可以修改现有 RFC：

• 关于已获批准的内容的说明。
• 机械方面的修订，例如更新链接、文档、用法等
• 之后发现的设计改进或细微更改，例如在实现过程中。

对于设计上的更改，请记录原始设计目标是什么、更改原因及更改方式。

如果您对设计进行任何重大更改，请提交新的 RFC。

• 在新版 RFC 中，请引用原始 RFC，并在标题中明确指明更改类型，例如附录。
• 如果原始 RFC 中的设计将被弃用，请修改原始 RFC 以指明这一点并引用新的 RFC。
• 如果有多个 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 语言的决策。之所以提出该方案，是因为该决策过程的成功。