| 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，并使特定触发器请求召开会议；
- 提交步骤由作者自行决定，并提供 7 个工作日的服务等级协议(SLA) 以供 FEC 提供权威答复。
设计初衷
随着 2020 年 2 月推出 RFC 流程，对符合 FTP 标准的 FIDL 更改在技术上还将需要 RFC。事实上，自从执行 RFC 流程后，接受或拒绝的各种 FTP 便不会加倍：这两个流程旨在实现类似的目标，而且正式和审核方面也相似。
但是，我们希望围绕技术变更的单一审核流程将 Fuchsia 统一起来，因此希望终止 FTP 流程，改为使用 RFC 流程。
过去两年半的 FTP 流程中取得了 成功，我们还希望将学到的一些经验教训运用到 RFC 流程中。
设计
我们首先会调查 FTP 流程与 RFC 流程之间的差异，然后对 RFC 流程提出一系列修正建议。
最后，我们将介绍如何将所有 FTP 折叠成 RFC，从而进一步集中 Fuchsia 技术决策的所有工件。
两个进程的区别
中
FTP 流程对媒介不强制要求，作者在遵循所要求的模板的前提下，可以自由选择他们认为最合适的媒介。实际上，所有 FTP 最初都是以 Google 文档的形式开始的，直到其获得批准或遭拒，然后这些文档才会转换为 Markdown 文档，并提交到 Fuchsia 源代码树。最终的修改和编辑润色通常是在转换过程中完成的。
RFC 流程规定，使用 Gerrit 更改（也称为 CL）作为媒介，并要求通过使用相关更改的后续补丁集进行迭代，利益相关方可受邀担任更改的审核者。
作者认为，在 Google 文档上发表评论、提出修改建议或更改的便捷性是促进技术交流的催化剂。实际上，多个 RFC 在其社交阶段就开始于 Google 文档中，因此这些 RFC 的草稿实际上更接近最终定稿。在选择使用 Gerrit 以外的其他媒介进行社会化时，应谨慎操作，避免对目标受众群体造成任意限制。例如，Google 文档应该是“可供所有人访问”。
模板
FTP 流程严格要求使用 FTP 模板，并要求填写所有部分，即使仅明确声明“不适用”也是如此。
FTP 模板本质上是专为 FIDL 设计的，因此会询问一些专门针对 FIDL 的探究问题。为了满足新要求，FTP 模板一直在不断发展。例如，RFC-0024：强制性源代码兼容性中添加了对源代码兼容性影响的特定说明。这种更严格的格式和具体的问题有助于 FTP 作者及其审核者确保其设计是完整的。
查看
FTP 流程最常在一次或多次线下会议期间审核提案。虽然使用异步审核机制（例如对 Gerrit 更改的评论），这也可能是例外情况而非常态。
RFC 流程鼓励采用异步审核机制，如果讨论过于复杂，我们建议作者安排会议。
这里的一个重要区别在于，FTP 审核会议由 Fuchsia FIDL 团队组织和安排，而 RFC 流程要求作者安排会议。作者与驱动流程（FIDL 团队、Fuchsia 工程委员会）之间可能存在重要信息不对称。如果安排与作者（而不是推动流程的人员）共同组织审核会议，则会产生另一个障碍，这可能并不容易克服，尤其是在需要浏览项目组织并知道邀请谁时。
条件
FTP 流程对于何时应使用 FTP 流程设有特定条件。
同样，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 流程应要求使用模板。每个区域都可能包含相关的探测问题或应在其各自区域的提案中添加的部分。
模板：FTP 专用：RFC 模板应进行增强，以包含 FTP 模板的特定内容，以供 RFC 轻触 FIDL 区域使用。
RFC 标准 我们建议每个区域都提交额外的条件，以确定何时应该为相应的区域遵循 RFC。如果存在针对某个领域的标准，FEC 将确保适当的利益相关方参与其中。可以说，这不是对 RFC 流程的更改，因为用户只需提交 RFC 即可修改该流程，例如，对 Zircon 做了什么。不过，我们认为，通过简化所有领域的标准存在，我们相信更多领域会明确说明对他们来说“重要”的内容。除了确保以适当的方式环入这些方面之外，它还具有记录更改的相对重要性的额外好处。
RFC 条件：FTP 专用：RFC 流程应包含 FTP-049 中针对 FIDL 区域确定的标准。
利益相关方：虽然 RFC 作者应尽力确定利益相关方，但 FEC 也应该在确定利益相关方方面发挥积极作用。RFC 作者应要求 FEC 尽早确定所有利益相关方，从而降低提交步骤出乎意料的可能性。
工程审核会议 由 FEC 自行决定，应将更方便社交化处理的 RFC 安排召开工程审核会议。会导致工程审核安排时间的一些触发器包括：
- 难以确定相关的利益相关方。可能会发生这种情况，比如 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。
- 在 Markdown 和代码注释中对所有 FTP 的引用。
- FIDL 治理部分。
- RFC 进程摘要页面。
缺点、替代方案和未知情况
保留同一技术项目中的两个大致相同的正式流程会造成混淆。我们不会考虑将原有设置视为替代方案。
上述针对 RFC 流程的每项修正均可单独评估。我们认为，这些改变都会带来净收益。
早期技术和参考资料
此 RFC 将 RFC 流程与 FTP 流程整合在一起，即 FTP-001：简单的提案和 FTP-049：FIDL 调整流程的演变。