| RFC-0017：FTP 流程已死，RFC 流程万岁！ | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 停止 FIDL 调优流程，并将其整合到 RFC 流程中。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2020-12-14 |
| 审核日期（年-月-日） | 2021-02-08 |
摘要
此 RFC 停止了 FTP 流程，将现有 FTP 合并到 RFC 中，并按如下方式修订了 RFC 流程：
- 在社交化阶段，鼓励使用比代码审核更具动态性的媒介；
- 要求使用 RFC 模板，并在该 RFC 模板中包含特定于区域的部分；
- 正式确定了每个领域的标准；
- 让 Fuchsia 工程委员会 (FEC) 在确定利益相关者方面发挥更积极的作用；
- 添加了由 FEC 主持的会议，用于讨论 RFC，并添加了调用会议的特定触发器；
- 提交步骤由作者自行决定，FEC 会在 7 个工作日内给出权威解答。
设计初衷
随着 2020 年 2 月 RFC 流程的推出，符合 FTP 标准的 FIDL 变更在技术上也需要 RFC。实际上，自那时以来接受或拒绝的各种 FTP 并未通过 RFC 流程进行重复处理：这两个流程的目标相似，正式程度和审核程度也相似。
不过，我们希望统一 Fuchsia 的技术变更审核流程，因此打算停用 FTP 流程，转而采用 RFC 流程。
在运行的两年半时间里，FTP 流程一直成功，此外，我们还希望将学到的一些经验教训应用到 RFC 流程中。
设计
我们首先调查 FTP 流程与 RFC 流程之间的差异，然后针对 RFC 流程提出一组修正。
最后，我们介绍了如何将所有 FTP 折叠到 RFC 中，以进一步集中化 Fuchsia 技术决策的所有制品。
这两个流程之间的区别
中
FTP 流程并未强制规定媒介，作者可以自由选择他们认为最合适的媒介，同时遵守规定的模板。实际上，所有 FTP 在获得批准或被拒绝之前，都是以 Google 文档的形式开始的，之后这些文档会被转换为 Markdown 文档，并提交到 Fuchsia 源代码树。最终的修改和润色通常在转换期间完成。
RFC 流程要求使用 Gerrit 更改（也称为 CL）作为媒介，并要求通过使用更改的后续补丁集来完成迭代，同时邀请利益相关者担任更改的审核者。
作者认为，在 Google 文档中轻松发表评论、建议修改或进行更改是促进健康技术对话的催化剂。实际上，许多 RFC 在社会化阶段都是从 Google 文档开始的，因此它们的草稿实际上更接近最终文档。 如果选择 Gerrit 以外的其他媒介进行社交，应注意避免随意限制目标受众群体。例如，Google 文档应为“全球可访问”。
模板
FTP 流程严格要求使用 FTP 模板，并要求填写所有部分，即使只是明确声明“不适用”也是如此。
由于 FTP 模板是专门为 FIDL 设计的，因此会提出专门针对此领域的试探性问题。随着时间的推移，FTP 模板不断发展，以满足新的要求。例如，RFC-0024：强制性源代码兼容性中添加了有关源代码兼容性影响的具体号召性用语。这种更严格的格式和具体问题有助于 FTP 作者及其审核者确保设计完整。
查看
FTP 流程通常会在一次或多次面对面会议期间审核提案。虽然也可以使用异步审核机制（例如在 Gerrit 更改上添加注释），但这种情况是例外而非常态。
RFC 流程鼓励采用异步审核机制，如果讨论过于复杂，建议作者安排会议。
这里的一个重要区别是，FTP 审核会议由 Fuchsia FIDL 团队组织和安排，而 RFC 流程要求作者安排会议。作者与流程推动者（FIDL 团队、Fuchsia 工程委员会）之间可能存在重要的信息不对称。如果将组织审核会议的责任交给作者，而不是流程的推动者，就会增加额外的障碍，尤其是在需要了解项目组织结构并知道要邀请谁时，这些障碍可能难以克服。
条件
FTP 流程有具体的使用条件。
同样，RFC 流程也规定了具体的使用条件，后来还添加了针对 Zircon 的特殊注意事项。
决策
FTP 流程依赖于 Fuchsia FIDL 团队做出决策，最终决策者是 Fuchsia FIDL 团队负责人。
RFC 流程依赖于相关利益相关方表达赞成或拒绝意见，最终决定由 Fuchsia 工程委员会 (FEC) 做出。
这两种决策制定方法类似，尤其是考虑到 FIDL 团队将是所有修改 FIDL 的 RFC 的关键利益相关者。一个重要的区别是，FTP 流程需要“推送模型”，即作者必须向 FIDL 团队提交其设计。RFC 流程更偏向于“拉取模型”，FIDL 团队有责任主动参与相关设计，以便自己的意见被听到。
服务等级协议 (SLA)
FTP 流程具有特定的 SLA，可提供权威的答案（“五个工作日”）。这是在 FTP-049 的迭代阶段专门添加的，当时有人评论说“从 FTP 作者的角度来看，最好知道 FIDL 团队何时会就 FTP 做出决定”。
目前，RFC 流程没有 SLA。
编号
FTP 进程会在启动 FTP 时分配一个序列号。
RFC 流程会在 RFC 获得接受或拒绝时分配一个序列号。
对 RFC 流程的修订
中等：RFC 流程应在社会化阶段提供比代码审核更具动态性的媒介，例如 Google 文档或其他媒介。可以说，这不会改变 RFC 流程，该流程仅要求在流程的正式部分使用 Gerrit 更改，但在 RFC 的社交阶段承认并鼓励使用其他媒介可能会消除混淆。
RFC 流程还应强烈鼓励将更具动态性的媒体中的相关背景信息转移到 RFC 撰写中。例如，来回对话可能会导致添加额外的“考虑的替代方案”条目。
模板：RFC 流程应要求使用模板。每个领域可能都有相关的问题或部分，应将其纳入相应领域的提案中。
模板：特定于 FTP 应扩充 RFC 模板，以包含 FTP 模板的特定内容，供触及 FIDL 区域的 RFC 使用。
RFC 标准：鼓励每个领域提交有关何时应遵循其各自领域 RFC 的其他标准。如果某个领域存在相关标准，FEC 将确保相关利益相关者参与其中。可以说，这并未改变 RFC 流程，因为人们可以简单地提交 RFC 来修改流程，例如 Zircon 所做的那样。不过，通过简化所有领域的标准，我们相信会有更多领域明确说明对它们而言“重要”的是什么。除了确保这些领域得到适当的参与之外，它还将带来记录变更相对重要性的额外好处。
RFC 标准：特定于 FTP RFC 流程应包含 FTP-049 中针对 FIDL 区域确定的标准。
利益相关方：虽然 RFC 作者应尽最大努力确定利益相关方，但 FEC 也应在确定利益相关方方面发挥积极作用。RFC 作者应尽早向 FEC 提出请求，以确定所有利益相关方，从而降低在提交步骤中出现意外情况的可能性。
工程审核会议如果 RFC 需要进行更多社交化，FEC 应自行决定是否安排工程审核会议。以下是一些会导致安排工程审核的触发因素：
- 难以确定相关利益相关方。RFC 可能会收到许多评论、建议和反对意见，而作者不清楚如何根据这些反馈采取行动，也不清楚哪些是核心反馈（可能会阻碍 RFC 被接受），哪些是辅助反馈（可能只是好奇、未来的计划等）。
- RFC 作者和相关方难以就未解决的问题达成一致。
提交：RFC 流程不应以对话是否趋于一致来限制 RFC 的提交，因为在某些情况下，作者可能难以确定对话是否趋于一致，而应允许作者请求 FEC 进行审核。如果提出此类要求，FEC 必须在七 (7) 个工作日内向作者提供权威的解答。答案是以下任一选项：
- 审批，或
- 拒绝，或
- 未解决的未完成事项：FEC 发现一个或多个未解决的未完成事项，并要求作者在再次请求审核 RFC 之前与相关利益相关者解决这些事项。
将 FTP 纳入 RFC
从机制上讲，为了将 FTP 纳入 RFC，我们将：
根据现有的 RFC，将所有 FTP 重新编号为连续编号。例如，在撰写本文时，FTP-001 将变为 RFC-0017。
更新每个 FTP 撰写内容，以将其 RFC 编号显示为主要标题，同时保留其之前的 FTP 编号。记录旧编号非常重要，因为许多 Git 提交或 bug 都会按编号引用 FTP。
出于参考原因，我们希望保留 FTP 进程存在的相关记录（例如，此 RFC 中的许多链接）。
今后，已转换为 RFC 的 FTP 应通过 RFC 编号（而非其历史 FTP 编号）进行引用。
实现
保持冷静，并按照流程操作。
性能、安全性、隐私权和测试注意事项
预计此提案会对性能、安全性、隐私权和测试注意事项产生积极影响。
文档
我们需要更新以下内容：
- 所有 FTP。
- 所有对 FTP 的引用，包括 Markdown 和代码注释中的引用。
- FIDL 治理部分。
- RFC 流程摘要页面。
缺点、替代方案和未知因素
在同一技术项目中保留两个大致等效的正式流程会造成混淆。我们不认为保持原样是一种替代方案。
上述针对 RFC 流程的每项修订建议都可以单独进行评估。我们认为，这些变化总体上是有益的。
在先技术和参考资料
此 RFC 将 RFC 流程与 FTP 流程（即 FTP-001：一个适度的提案和 FTP-049：FIDL 调整流程演变）整合在一起。