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 流程建立了一条一致且透明的路径，以便做出项目范围的技术决策，并确保相关的利益相关方参与到每项决策中。

设计

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

何时使用此流程

RFC 流程可用于对 Fuchsia 所做的任何更改，以受益于其结构化决策方法、来自 Eng Council 的上报帮助和/或其持久的决策记录。

绝大多数更改都不需要 RFC。require而是可以使用代码审核流程进行这些更改。如果贡献者认为 RFC 流程有用，则应随意使用 RFC 流程，并在双方同意该流程并非必需流程或在特定情况下无价值时，随时停止。但是，对整个项目具有广泛影响的技术决策需要更广泛的认同，并且必须通过 RFC 流程与项目进行社交。

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

• 针对未来开发添加限制条件。一些决策一旦做出，就会限制系统未来的开发。我们在做出此类决定时需要小心，因为一旦做出决定，后续很难再做出修改。

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

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

• 委派决策权。项目经常需要做出几类决策，这些决策会受益于专业的专业知识。项目可以将这些类别的决策的决策权委派给其他组或流程，而不是通过 RFC 流程做出所有这些决策。例如，我们经常需要做出关于平台 API 的决策，这会给未来的开发增加限制，但在对平台 API 的每项更改中使用 RFC 流程并不切合实际。

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

除了上面列出的一般注意事项之外，一些方面还声明了其他标准。请参阅以下文档（如适用）：

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

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

何时开始 RFC 流程

我们建议作者在发现有用的问题后立即启动 RFC 流程，并提供问题说明。此操作应该是相对轻量的，如果作者认为没有必要发布 RFC，稍后可以选择退出 RFC 流程。

一些想法可能适合与利益相关方进行早期讨论，以发现要求，而另一些想法可能会受益于通过原型设计了解利弊。

角色和职责

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

• RFC 作者。RFC Author 是撰写 RFC 的人。为 Fuchsia 贡献内容的每个人都可以成为 RFC Author。一个给定 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 步：问题陈述

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

退出条件：作者通过电子邮件将问题陈述发送给 Eng Council (FEC)。

第 3 步：分配教员

工程委员会会指派一位辅导员。此教员是 RFC 作者的资源，有助于优化问题陈述并确定相关利益相关方。辅导员还可以告知作者，此问题是需要还是将从正式的 RFC 撰写中受益。在某些情况下，辅导员可能会建议作者在 RFC 流程之外继续设计和实现。

退出条件：指定教员，作者会收到告知他们教员的电子邮件。

第 4 步：发现利益相关方

在此阶段，RFC 作者应确定该 RFC 的利益相关方。作者可以请辅导员在此过程中提供建议。利益相关方列表应写在问题陈述旁边。这可能发生在 Google 文档中，或者作者可以选择使用大部分内容为空的 RFC 模板创建 RFC CL，并填写其利益相关方部分。

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

退出条件：作者和教员同意一组利益相关方，并使用 RFC 模板将利益相关方记录在 Google 文档或变更列表中。

第 5 步：社交

在此阶段，您需要确定问题的解决方案以及每种解决方案的优缺点。将这些解决方案与利益相关方互动交流，并听取他们的反馈。如果您不确定如何将您的想法进行社交推广，请考虑向您的辅导员或技术负责人寻求建议。他们通常更具备社交方面的经验，或许能为您指点迷津。

示例：该 RFC 通过在工程师论坛中进行讨论而得到社会推广，该论坛是 Google 内部关于参与该项目的各种工程负责人的定期会议。RFC 也向 FTP 和 CTP 流程的创建者社交，他们拥有这些流程的良好背景和背景信息。

退出条件：当作者认为自己掌握了足够的信息，可以继续操作时。 这由作者自行决定。如果他们觉得这是达成的，他们有几个选择：

• 原型设计。如果社交化阶段出现了取舍不明确的不同方法，作者可能会选择构建原型以更好地评估这些选项。这种原型可促进社会化的进一步发展。
• 退出 RFC 流程。如果作者（可能在教员的帮助下）认为此问题不需要使用 RFC，也不需要使用 RFC，则可以按照代码审核流程继续构建解决方案。作者还可以选择以非正式方式发布设计文档。
• 撰写。继续执行第 6 步。

第 6 步：草稿和迭代

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

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

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

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

提示：如需获得在 RFC 上起草和迭代的建议，请参阅 RFC 最佳实践文档。

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

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

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

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

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

• 讨论变得有争议或没有效果。通常，与文字交流相比，面对面会议可以更高效地将讨论恢复到正常状态。
• 利益相关方过于挑剔（即兴发言）或使讨论停滞不前（无回应）。有时，利益相关方不喜欢某个提案，但没有可靠的技术论据，或许在不知不觉间，对这些延误的论据采取了措施。
• 您收到了许多人的大量意见、建议和反驳，但不确定哪些评论来自相关利益相关方。此类反馈中很多通常都与核心问题无关，不会阻止 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 状态更改为“上次通话”。教员会在跟踪器中将 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。

在所有利益相关方均权衡各自的 Code-Review 标志后，发送电子邮件至 eng-council@fuchsia.dev，提示工程委员会决定是否接受您的 RFC。

退出标准：所有利益相关方的反馈；所有反馈一一处理。

第 8 步：提交

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

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

在极少数情况下，如果工程委员会确定了一个或多个未解析的未决项目，则 RFC 可能会移回到“草稿”阶段。工程委员会将要求作者解决与相关利益相关方一起确定的未解决的问题，然后再决定是否批准 RFC 审核。

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

然后，工程委员会会标记您的 CL Code-Review +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 语言。该方案的存在是因为该决策过程的成功。