| RFC-0017：FTP 流程已终止，RFC 流程万岁！ | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 停用 FIDL 调整流程，并将其整合到 RFC 流程中。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2020-12-14 |
| 审核日期（年-月-日） | 2021-02-08 |
摘要
此 RFC 废弃了 FTP 流程，将现有 FTP 整合到 RFC 中，并修订了 RFC 流程，如下所示：
- 鼓励在社会化阶段使用比代码审核更具活力的媒介；
- 要求使用 RFC 模板，并在此 RFC 模板中添加特定区域的部分；
- 正式确定每个区域是否存在相应条件；
- 让 Fuchsia Eng Council (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 模板，并要求填写所有部分，即使只是明确注明“不适用”也是必须的。
与之相反，RFC 流程建议使用 RFC 模板，但并非强制要求。
FTP 模板专为 FIDL 而设计，因此会提出专门针对此领域的探查性问题。FTP 模板随着时间的推移而不断演变，以满足新的要求。例如，RFC-0024：强制性源代码兼容性中添加了关于源代码兼容性影响的具体说明。这种更严格的格式和具体问题帮助了 FTP 作者及其审核人员确保其设计完整无缺。
查看
FTP 流程最常在一次或多次线下会议期间审核提案。虽然使用异步审核机制（例如对 Gerrit 更改的评论）也是可能的，但这属于例外情况，而不是常态。
RFC 流程提倡使用异步审核机制，如果讨论过于复杂，建议作者安排会议。
这里有一个重要的区别，即 FTP 审核会议由 Fuchsia FIDL 团队组织和安排，而 RFC 流程要求作者安排会议。作者和推动相关流程的人员（FIDL 团队、Fuchsia 工程委员会）之间可能存在重要的信息不对称。将组织审核会议的责任交给作者而非负责推动流程的人员，会带来额外的障碍，这可能并不容易克服，尤其是在需要了解项目组织结构并知道要邀请哪些人时。
条件
FTP 流程有特定条件，规定了何时应使用该流程。
同样，RFC 流程针对何时应使用 RFC 制定了具体标准，后来还添加了针对 Zircon 的特殊注意事项。
决策
FTP 流程依赖于 Fuchsia FIDL 团队做出决策，最终决策者为 Fuchsia FIDL 团队主管。
RFC 流程依赖于相关利益相关方表达其批准或拒绝意见，最终由 Fuchsia Eng Council (FEC) 做出决定。
这两种决策方法类似，尤其是考虑到 FIDL 团队将成为修改 FIDL 的所有 RFC 的关键利益相关方。一个重要的区别是，FTP 流程需要采用“推送模型”，其中作者必须将其设计提交给 FIDL 团队。RFC 流程更像是“拉取模型”，FIDL 团队有责任主动参与相关设计，以便让自己的声音被听到。
服务等级协议 (SLA)
FTP 流程有特定的服务等级协议 (SLA)，以便提供权威性解答（“5 个工作日”）。在 FTP-049 的迭代阶段，有人评论说：“从 FTP 作者的角度来看，最好知道 FIDL 团队何时会对 FTP 做出决定。”因此，我们专门在该阶段添加了此信息。
RFC 流程目前没有服务等级协议 (SLA)。
编号
FTP 进程会在启动 FTP 时分配一个序列号。
RFC 流程会在接受或拒绝 RFC 时分配顺序编号。
RFC 流程的修订
媒介：与代码审核相比，RFC 流程在传播阶段应采用更具活力的媒介，例如 Google 文档或其他媒介。可以说，这并不是对 RFC 流程的更改，因为该流程仅要求在正式流程的部分使用 Gerrit 更改，但在 RFC 的社会化阶段承认和鼓励使用其他媒介可能会消除混淆。
RFC 流程还应强烈建议将来自更具动态性的媒体的相关背景信息带入 RFC 编写内容中。例如，来回对话可能会导致添加更多“考虑的替代方案”条目。
模板 RFC 流程应要求使用模板。每个领域可能都有相关的探究性问题或部分，应在相应领域的提案中包含这些问题或部分。
模板：特定于 FTPRFC 模板应进行扩充，以包含 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 流程应允许作者请求 FEC 进行审核，而不是禁止作者针对会话汇聚提交 RFC（在某些情况下，作者可能难以识别会话汇聚）。收到此类要求后，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 调整流程演变）整合在一起。