| 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 后，您就可以与相关利益相关者一起迭代您的想法了。希望您在宣传自己的想法时，已经找到了大部分合适的利益相关者，但您很可能在此阶段发现其他利益相关者。
从机制上讲，您应像进行常规代码审核一样，将利益相关者添加到 CL 的“审核者”或“抄送”字段中，邀请他们就您的 RFC 提供反馈。利益相关者应在代码审核工具中通过在 RFC 上添加注释来向您提供反馈。
如果讨论过于复杂，代码审核工具无法处理，请考虑与相关利益相关方安排会议，以便更高效地进行讨论。 会议结束后，您必须在 CL 上以评论的形式发布会议摘要，以便未参加会议的人员了解会议期间讨论的内容。
如果讨论变得有争议，请升级到 RFC 编辑者。工程委员会可以帮助推动讨论向前发展，例如为讨论提供更多结构或将讨论移至其他论坛。无论讨论如何进行，任何 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 签字，但所有利益相关方都可以使用 +2 签字，以表达他们对 RFC 的热情。
如果利益相关者希望反对某项 RFC，可以将 Code-Review 标志设置为 -1 或 -2，具体取决于他们认为该 RFC 不应继续推进的程度。将代码审核标志设置为 -1 或 -2 时，利益相关者必须说明反对理由，最好能让其他人无需阅读反对意见之前的所有讨论内容就能清楚了解反对意见。
利益相关者将代码审核标志设置为 -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 语言。正是由于该决策过程的成功，才有了这项提案。