Fuchsia RFC 流程

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

• RFC-0001：Fuchsia 评论请求流程
• RFC-0006：Zircon 的 RFC 流程附录
• RFC-0067：Fuchsia RFC 流程的新增内容
• RFC-0017：FTP 进程已失效，RFC 进程长期存在！
• RFC-0122：RFC 利益相关方
• RFC-0248：RFC 问题陈述

本页面整理了上述 RFC 并捕获了当前进程。

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

摘要

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

设计初衷

RFC 流程建立了一致且透明的途径，用于制定项目级技术决策并确保适当的利益相关方参与每个决策。

设计

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

何时该使用流程

RFC 流程可用于对 Fuchsia 的任何更改，如果其受益于其结构化的决策方法、工程委员会的上报帮助和/或其持久的决策记录。

绝大多数更改都不需要 RFC。require不过，您可以通过代码审核流程完成这些更改。如果贡献者认为 RFC 流程很有用，可以随意使用它；如果双方一致认为该流程在特定情况下不是必需的，或者不会增加价值，可以随时停止使用。但是，对于在项目中具有广泛影响的技术决策，需要获得更广泛的协议，并且必须通过 RFC 流程与项目进行社交。

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

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

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

• 更改系统架构。系统架构描述了系统作为一个整体如何协同工作。根据定义，更改系统架构会跨越子系统之间的界限，并且需要与许多利益相关方进行仔细咨询。

• 委派决策权。项目通常需要频繁做出各种决策，这些决策会从专业的专业知识中受益。项目可以将这些类别的决策的决策权委托给其他组或进程，而不是通过 RFC 流程做出所有决策。例如，我们经常需要做出有关平台 API 的决策，这会给未来的开发带来限制，但使用 RFC 流程来处理平台 API 的每项更改并不现实。

• 上报。最后，有争议的更改可以受益于 RFC 流程的透明度和清晰度。如果技术方向存在个人技术负责人无法解决的分歧，则存在异议的一方或其他贡献者可以将决定上报给 RFC 流程。

除了上述一般注意事项之外，某些方面还声明了额外的条件。请参阅相关文档：

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

其他可能受益于 RFC 流程的更改包括需要手动或自动对代码库进行大规模更改的更改。例如，如何写入日志或如何处理错误路径。他们致力于找到最佳模式并将其统一应用于整个代码库，而不是采用“一致性岛”模式。

何时启动 RFC 流程

我们建议作者在发现有用时，通过问题陈述启动 RFC 流程。这应相对轻微，如果作者决定没有发布 RFC，可以稍后选择退出 RFC 流程。

有些想法适合通过与利益相关方进行早期讨论来发现要求，而有些想法则适合通过原型来理解权衡取舍。

角色和责任

用户会以多种角色与 RFC 流程进行交互：

• RFC 作者。RFC Author（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 文件，但作者在此阶段应使用他们认为有用的任何媒介。

退出标准：作者清楚了解他们想要解决的问题，或者认为此问题不需要 RFC 流程。

第 2 步：问题陈述

作者应针对待解决的问题撰写简要说明。这可以采用任何有助于讨论的格式，并且应提供足够的信息，以便读者能够确定哪些 Fuchsia 子系统可能会受到影响。此问题说明应具体说明此阶段的所有已知要求，但以后可能会发现更多要求。它还应该明确所有“非目标”，以避免范围蔓延。

退出标准：作者通过电子邮件将问题陈述发送给英国英语委员会 (FEC)。

第 3 步：指定教员

工程委员会指定了一位辅导员。此主持人是 RFC 作者的一项资源，可帮助优化问题陈述和确定相关利益相关方。辅导员还可以向作者说明此问题是否需要或将从正式的 RFC 撰写中受益。在某些情况下，辅导员可能会建议作者在 RFC 流程之外继续进行设计和实现。

退出条件：分配辅导员后，作者会收到电子邮件通知，告知其辅导员。

第 4 步：利益相关方发现

在此阶段，RFC 作者应确定此 RFC 的利益相关方。在此过程中，作者可能会请教员提供建议。应该将利益相关方列表与问题陈述一并写下。这可以在 Google 文档中进行，也可以由作者选择使用大部分为空的 RFC 模板创建 RFC CL 并填写其利益相关方部分。

注意：如果需要，作者或辅导员可能会在稍后的过程中添加或移除利益相关方。

退出条件：作者和辅导员就一组利益相关方达成一致，并将利益相关方记录在 Google 文档或具有 RFC 模板的变更列表中。

第 5 步：社交

在此阶段，确定问题的解决方案以及每个解决方案的优缺点。将这些解决方案与您的利益相关方进行沟通，并采纳他们的反馈。如果您不确定如何传达自己的想法，请考虑向辅导员或技术主管寻求建议。他们通常拥有更丰富的想法社交经验，或许能够为您指明合适的方向。

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

退出标准：当作者认为自己有足够的信息可以继续时。这由作者自行决定。如果他们认为实现了这一目标，可以采取以下几种方案：

• 原型。如果在社交阶段发现不同方法的权衡不明确，作者可能会选择构建原型来更好地评估这些方案。这种原型设计可能会进一步融入社区。
• 退出 RFC 流程。如果作者（可能需要在辅导员的帮助下）确定此问题不需要使用 RFC，也不需要从 RFC 中受益，他们可以继续通过代码审核流程构建解决方案。作者还可以选择以非正式方式发布设计文档。
• 撰写。继续执行第 6 步。

第 6 步：草稿和迭代

作者通过社交功能收集了所有背景和背景信息后，就可以开始 RFC 流程的正式部分了。下一步是撰写 RFC 文档本身的草稿。早期的草稿和反馈可能会在 Markdown 之外（例如在 Google 文档中）发生。但是，如果此过程的后期有正式的 RFC 记录，则强烈建议将相关上下文从更加动态的媒介转移到 Markdown 中的 RFC 写入。例如，来回对话可能会导致添加其他“考虑的替代方案”条目。

作者准备就绪后，应以 RFC 模板的副本开头，创建一个将文件添加到 //docs/contribute/governance/rfcs 目录的 CL。

RFC 中的任何其他文件（例如图表）可添加到 resources 目录下的一个与 RFC 同名的子文件夹中。示例：//docs/contribute/governance/rfcs/resources/<RFC_name>/diagram.png。

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

提示：参阅 RFC 最佳实践文档，获取有关 RFC 起草和迭代的建议。

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

作者应邀请利益相关方针对 RFC 提供反馈，方法是将审核者（针对需要 +1 的利益相关方）或“抄送”字段（针对“已咨询的”利益相关方）添加到 CL 中的“审核者”或“抄送”字段，就像常规的代码审核一样。此外，作者还可以将其 CL 发送至 eng-council-discuss@fuchsia.dev，以收集更多反馈。利益相关方应通过在代码审核工具中的 RFC 上添加注释来提供反馈。

审核人员应在 5 个工作日内回复审核请求，并跟进收到的评论。作者和审核者应使用 Gerrit 的“注意力集”功能来跟踪谁需要回复。如果响应时间超过此值（例如，如果需要构建原型），则应在 CL 注释中指明这一点。

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

如果作者在讨论过程中遇到任何问题或延误，辅导员可以帮助解决。以下是在讨论过程中出现的一些常见问题：

• 讨论变得有争议或没有成效。通常情况下，面对面会议可以比基于文本的沟通更高效地将讨论安排回正轨。
• 利益相关方过于挑剔 (fillibuster)，或者妨碍讨论（无回应）。有时，利益相关方不喜欢该提案，但没有可靠的技术论据，并且可能会无意间采取这些延迟处理方法。
• 您收到了许多人发来的许多评论、建议和回复，并且不确定哪些评论来自利益相关方。通常，此类反馈大部分与核心问题无关，并且不会阻止 RFC 被接受。
• 讨论的收效太慢了。

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

反馈可能包括非利益相关方的评论。作者应回复这些注释（如果相关），但进入 Last Call 阶段不一定需要解决这些注释。如果评论指出谁是利益相关方存在分歧，FEC 可以帮助解决此问题。

如果问题不再相关，或者作者和利益相关方认为该问题不需要 RFC，作者可以在此时撤消 RFC。在这种情况下，作者应将包含 RFC 的 CL 标记为已放弃。如果情况发生变化，作者或其他人可以随时恢复您的 RFC。恢复其他人创建的 RFC 时，您应该从头开始执行 RFC 流程，但您可以使用撤消的 RFC（而不是 TEMPLATE.md）作为起点。请与原作者协商，确定他们是否希望继续将其名称与 RFC 的新版本相关联。

审核人员须知：RFC 流程旨在鼓励各种观点和积极的讨论。通常情况下，在公共论坛中给出负面反馈可能很困难。如果需要，审核者可以联系他们的负责人、同行或工程委员会寻求帮助。

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

退出条件：RFC CL 已送交审核，征集了反馈并将其纳入 RFC CL 中，或者 RFC 被撤回。

第 7 步：上次通话

RFC 的讨论聚集后，作者必须请其辅导员将 RFC 的状态移至“Last Call”。教员会将 RFC 标记为在跟踪器的“最后一次通话”中，这会生成自动发送给 eng-council-discuss@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。

退出条件：所有利益相关方提供的反馈；所有反馈均得到处理。

第 8 步：提交

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

如果项目决定拒绝您的 RFC，工程委员会成员会对您的 CL 添加注释，声明 RFC 已被拒绝，提供拒绝的理由，并为 RFC 指定一个编号。被拒的 RFC 是有价值的工程工件。工程委员会将与 RFC 作者合作，发布标记为“已拒绝”且包含理由的 RFC 版本。

在极少数情况下，如果工程委员会发现一个或多个未解析的待解决项，RFC 可能会移回“草稿”阶段。工程委员会将要求作者解决与相关利益相关方确认的待解决内容问题，然后才会批准另一次 RFC 审核请求。

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

随后，工程委员会会将您的 CL Code-Review +2 标为 +2，然后您就可以提交 RFC！

恭喜！您为项目贡献了宝贵的工程工件！

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

呼叫等待

如果您当前不想让 RFC 继续向前发展（例如，因为您的优先级发生了变化，或者 RFC 旨在解决的问题不再那么突出），您可以将 RFC 更改为“暂时保留”状态。当 RFC 处于暂停状态时，利益相关方不需要提供反馈，FEC 也不会主动推动进度。

如果一个月内您的 RFC 的 CL 没有显示任何进展，RFC 聊天机器人将向您和您的辅导员发送一封电子邮件，提示他们讨论是否要将您的 RFC 移至“待定”状态，或如何将您的 RFC 推进。理想情况下，如果您遇到困难或延迟，最好在此之前将这种情况上报给辅导员，但这次对话也是发现这些问题的好时机。

您可以随时将 RFC 从“待定”状态移出，方法是与辅导员联系，告知他们您计划继续处理 RFC。如果您想更换新的教员，请与 FEC 的任何成员联系，他们可以为您指派新的教员。此时，您的 RFC 将返回到草稿阶段。

退出条件：RFC Author 会说明他们打算继续处理其 RFC；主持人对 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 语言决策。此提案的存在是由于决策流程的成功而存在。