| 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 流程在运行的两年半时间里取得了 a 成功，我们 还希望将一些经验教训带到 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 流程的更改，因为 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 请求确定所有利益相关方，从而降低在提交步骤中出现意外的可能性。
工程审核会议 ：FEC 可自行决定是否安排工程审核会议，以审核那些从更多 社交中受益的 RFC。导致安排工程审核的一些触发条件包括：
- 难以确定相关利益相关方。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 调整流程 演变）整合在一起。