{% set rfcid = "RFC-0001" %} {% include "docs/contribute/governance/rfcs/_common/_rfc_header.md" %}
Fuchsia RFC 工作流是为项目级别的技术决定提供一个一致且透明的工作流程。比如，RFC 流程可以用来演进项目路线图和系统架构。
现在，Fuchsia 项目在项目级别的技术决定上并没有一个正式的工作流程。以我们目前的规模来说，这样的非正式性导致了不同的人在项目方向和如何组合系统上有着不同的看法。 通过建立这样一个一致且透明的项目标准， 所有的利益相关者都能够在项目的技术方向充满信心。
本节讲述 RFC 流程的设计。
绝大多数的 Fuchsia 更改并不会使用到 RFC。与之对应，这些更改可以使用：代码审阅流程。但是，对整个项目有广泛影响的技术决策需要有更广范围的共识，则必须使用 RFC 流程使决策在项目范围内和大家交流。
下面列举了必须使用 RFC 流程的情况：
- 改变项目路线图。 项目路线图描述了对整个系统有广泛影响的改变，一般会触及到一大部分的系统，或者跨越多个子系统的边界。
- 增加对未来发展的约束。 一些决定一旦做出，就会限制系统的未来发展。我们在做这些决定的时候要慎重，因为之后可能会很难修改。
- 制定项目政策。 项目政策对系统有着广泛的影响，常常影响着项目贡献者。比如，修改支持的（编程）语言集，会影响需要调试和理解系统的人员，即使并不是所有的人都使用新语言。
- 修改系统架构。 系统架构描述了系统这个整体如何协作。 更改系统架构，顾名思义，会跨过子系统的边界，需要仔细向许多相关人员协商。
- 决策委托。 本项目经常会有一些需要特殊领域的专家参与的决定。这时我们把决策权委托给其他组织或者走别的流程，而不是使用 RFC 流程。比如，我们经常需要对平台的 API 接口做决定，这些接口限制着未来的开发工作，但是对所有的平台 API 接口的修改都使用 RFC 流程是不切实际的。
- 上报。 最后，流程的透明性、清晰性有助于解决有争议的更改。如果在一个技术方向上存在单个技术领导者无法解决的分歧，这个决策可以被争议的任意一方或者其他贡献者上报至 RFC 流程。
RFC 流程同样也可以用于其他一些改变，从而受益于它结构化的决策方法和它持久的决策记录。
人们在与 RFC 流程的交互中有多种角色：
- RFC 作者。 RFC 作者是编写 RFC 的人。每个 Fuchsia 项目贡献者都可以是 RFC 的作者。一个 RFC 可以有一个或多个作者。RFC 的作者需要推进该 RFC 的进程。
- 利益相关者。 利益相关者是项目是否接受给定 RFC 有利益关系的人。利益相关者一般来说是 Fuchsia 的贡献者，但是也有一些 RFC 的利益相关者在 Fuchsia 项目之外。例如，利益相关者可能参与在其他使用 Fuchsia 的项目中，或者受到 Fuchsia 更改的影响。利益相关者也不一定都直接参与到 RFC 的讨论中。相反，利益相关者通常被别人“代表”，一般是技术领导或者其他一些代表利益相关群体的人。
- 工程委员会。 工程委员会促进讨论以及对是否接受一个 RFC 做最终的决定。
本节介绍 RFC 流程中涉及的每一个步骤。
RFC 流程的第一步就是把您在项目中的想法和大家交流。比如，您可能发现了一个需要解决的重要问题。其他人注意到这个问题了吗？或许已经有人在着手解决这个问题了，再或者有一些其他的相关资料可以帮到您。总之越早发现这些情况，对项目越好。
相比于接下来的步骤，这一步相对非正式。这份文档不会严格要求您如何和其他人交流您的想法。交流技术想法本身就是一项技能。不过，一个好的起点，是向您准备解决的问题所在领域的技术领导讨论时提出该主题。譬如，您可能会想要跟在您需要修改的相关代码库的 OWNERS 文件中的人咨询，来执行您的想法。
如果您对如何和其他人交流您的想法有疑问，可以考虑向技术领导者寻求建议。通常他们在这方面更有经验，所以也能给您指明一条捷径。
例： 这条 RFC 是经过议员论坛的交流后分发的， 工程论坛是 Google 内部的由多个参与项目的工程领导参加的常规会议。 本条 RFC 也邀请了 FTP 和 CTP 流程的创建者交流，因为他们对这类流程有着丰富的经验。
当您准备好所有材料后，您已经准备好开始 RFC 流程的正式部分了。下一步就是编写 RFC 文档的初稿。
正常情况下，一份 RFC 是一个存放在 /contribute/governance/rfcs 路径下的 markdown 文件。创建一个 RFC，要先创建一个 CL 并放到这个目录下。建议从模版文件 RFC template 复制一份并在此基础上编写。模版并不是硬性要求，但是模版是设计来引导您写出一份高质量的 RFC 的。它帮助您以一种半结构化的方式认真思考您准备要解决的问题。
在这个阶段不必担心您的 RFC 的序号。反之，请使用 NNNN 作为占位符。比如，一个文件的名字应该是 NNNN_my_idea.md 这种形式。RFC 文档会在合并之前不久获得一个序号。
建议： 您可以在准备好接收反馈之前，先把包含 RFC 的 CL 标记为“进行中”。
当您创建好包含您第一份 RFC 草稿的 CL 后，您就可以把您的想法和相关人员进行交流了。您有望发现大多数合适的利益相关者已经参与了您想法的交流，不过通常这一阶段您要发现更多的利益相关者。
通常，您应该邀请利益相关者对您的 RFC 提供反馈，您可以通过在 CL 的“Reviewers“或者“CC“字段加上他们。利益相关者会通过代码审查工具在您的 RFC 中评论以提供反馈。
如果讨论的内容对于代码审查工具来说过于复杂，可以考虑和利益相关者安排会议来进行更有效的讨论。会议结束后，您必须在 CL 中发布一段会议总结的评论，这样可以使没有参与会议的人能理解在会议中讨论的东西。
如果讨论中存在争议，请上报至 RFC 的编辑。工程委员会可以帮您推进讨论，比如，可以提供一些别的视角或者把讨论移动到其他论坛中。不论讨论如何推进，任何不在 CL 上的讨论都要记录在 CL 中，大多数情况下以评论的形式把讨论总结放上去。
如果希望撤回 RFC，那么您可以将包含该 RFC 的 CL 标记为废弃状态。之后如果情况有变化，您或者其他人都可以恢复这个 RFC。如果您要恢复其他人创建的 RFC，那么您应当重头开始 RFC 流程，不过您可以将这个撤回的 RFC 作为起点，而不用从 TEMPLATE.md 开始。请与原作者协商，确认他们是否还想继续将其名称与您的新 RFC 相关联。
建议： 如果您对 RFC 感兴趣，可以配置 Gerrit 代码审查工具，让它在有 CL 修改
/contribute/governance/rfcs目录时给您发送邮件 > 通知。
当 RFC 逐步推进至稳定，您已经准备好进入审批阶段，这个阶段中利益相关者就会给 RFC 代码审查标志为 +1 或者 +2 来表示许可。通常，需要批准 CL 的利益相关者（即 RFC 需要其许可才能向前推进）应以 +2 的形式表示许可，另一些利益相关者的批准不是必需的，则可以以 +1 的形式表示许可。不过，如果希望表达对该 RFC 的热情，那么也欢迎所有利益相关者使用 +2 许可。
利益相关者如果希望表示反对一个 RFC，可以标记代码审查标志为 -1 或者 -2。这取决于他们对于该 RFC 不应推进的感受的强烈程度。当将一个 RFC 的代码审查标志设为 -1 或者 -2 的时候，利益相关者必须阐述说明反对的原因，最好能使人无需阅读完之前的所有讨论，就能清楚地理解反对意见。
利益相关者将代码审查标志设为 -1 或者 -2 并不一定会阻止项目接受该 RFC。要获取关于 RFC 接受决定流程的更多细节，请参阅下面的“决定如何做出”章节 。
在所有利益相关者都给出了他们的代码审阅标志之后，请发送一封邮件到 [email protected]，提醒工程委员会决定是否接受您的 RFC。
如果项目决定接受您的 RFC，工程委员会就会有一个人通过在您的 CL 中评论的形式声明这条 RFC 被接受了，并且会给 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-to-implement）流程。 Chromium 项目在影响到网页的行为上使用了一个决策流程。在本文档中描述的流程是根据我（abarth）帮助设计和运行 Blink 的流程一段时间的经验而成的。
- FIDL 完善建议。 Fuchsia 项目在 FIDL 语言决策流程中直接使用过一个相似的流程。该决策流程很成功，从而使得这个提案依旧存在。