| RFC-0049：FIDL 调整流程演变 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 我们提出了 FTP 流程的各种演变，包括将审核与决策分离、引入作者撤消 FTP 的方法、提供有关需要 FTP 的情况的指南，最后介绍了为 FIDL 做出贡献的其他途径。 |
| 作者 | |
| 提交日期（年-月-日） | 2019-11-20 |
| 审核日期（年-月-日） | 2019-12-19 |
摘要
我们提出了 FTP 流程的各种演变：
- 最重要的是将审核与决策分开；
- 引入作者撤消 FTP 文件的方法；
- 提供有关需要使用 FTP 的资源的指南；最后
- 介绍贡献 FIDL 的其他途径。
设计初衷
FIDL 调整流程已于一年多前推出。从各方面来看，该流程在促使其诞生的三个动机和目标方面都取得了显著进步：仔细考虑设计约束条件；每个决策背后的思考是透明的、记录的和公开的；最后，该流程提供了一个讨论想法（有时会进行详细讨论）的论坛，同时也提供了一个结论。
最终结果是，变化速度持续加快，并形成了迭代手册。截至目前，已提交 48 项提案（称为“FTP”），其中 25 项已被接受，9 项已被拒绝（所有这些拒绝均已记录妥当）。
不过，与所有事物一样，我们仍有改进的空间。具体而言，我们会考虑以下因素：
- 如何最好地审核 FTP？
- 何时可以撤消 FTP？
- 哪些更改需要使用 FTP？
- 还有哪些其他方式可以为 FIDL 的设计和演变做出贡献？
设计
查看 FTP
该流程目前未说明应如何审核 FTP，只指出“该提案由 Fuchsia FIDL 团队成员（非正式称为‘制琴师’）以及他们认为适合参与或委托参与该流程的任何人进行审核”。
审核 FTP 的最常见论坛是面对面会议。会议开始时，FTP 作者会展示其设计。然后，会议主持人（目前通常是 FIDL 主管）将处理设计文档中的评论，可能从设置应讨论的“待处理事项”的快速议程开始。
与“eng 审核流程”不同，通常是在会议期间解决未解决的问题（并记下备注，稍后纳入 FTP），然后由 FIDL 主管在会议结束时做出接受或拒绝 FTP 的决定。
希望在会议结束时做出决定，以及 FIDL 主管同时担任协调员和决策者的双重角色，这两点都造成了摩擦：FTP 会议期间会出现一定程度的匆忙，参与者会感受到表达自己意见的压力，为了批准快速修改的 FTP，需要在最后一刻草拟设计决策。
为了解决这种不良的动态，我们修改了“审核”步骤，并添加了明确的“决策”步骤。部分用语借鉴自英语审核流程。 “审核”步骤已更改如下：
此时，我们会审核 FTP 以及所有未处理的评论。
该提案将由 Fuchsia FIDL 团队成员（由 fuchsia.git 代码库中的 OWNERS 文件定义，并非正式称为 luthiers）以及他们认为适合参与或委托参与该流程的任何人进行审核。例如，在就某种语言的绑定做出决策时，他们可能会征求特定语言专家的意见。如有必要，我们可以将有争议的决策上报，就像 Fuchsia 中的任何其他技术决策一样。
[ADD] 最常见的是，审核是在一次或多次线下会议“FTP 审核会议”期间进行的。审核也可以使用异步通信（如果适用）进行。
FTP 审核会议开始时，作者会展示其设计。然后，主持人会处理 FTP 中的评论，并要求在文档中留下评论的人员提供反馈。
[ADD] 理想情况下，引导者和讲者是不同的人。主持人的目标是确保讨论设计的所有方面，并确保会议顺利进行。理想情况下，引导者对结果没有特别的利益，以免被视为有偏见，而演示者对其所演示的设计有隐含的利益。
[ADD] 我们不一定需要在会议期间对每条反馈做出结论，也不一定需要讨论每条评论（例如，如果有大量评论，或者有多个评论涉及同一基本问题）。相反，主持人应优先向演示者提供广泛的反馈，而不是力求将每个辩论要点都推导出结论。我们可能会在后续的审核会话或决策过程中解决未解决的问题。
审核最终可能有三种结果。
首先，我们可能需要等待一些问题得到解答或收到反馈，才能做出决定。在这种情况下，FTP 会移回“评论”阶段。
其次，提案可能会被拒绝，审核人员会提供拒绝原因。
第三，它可能会被接受。
在“审核”步骤后面添加了“决策”步骤：
Fuchsia FIDL 团队成员（由所有者文件定义）将在五 (5) 个工作日内决定审核结果，最终决策者为 Fuchsia FIDL 团队主管。
最终，此决定可能有三种结果。
首先，我们可能需要等待一些问题得到解答或收到反馈，才能做出决定。在这种情况下，FTP 会移回“评论”阶段。
其次，提案可能会被拒绝，审核人员会提供拒绝原因。
第三，它可能会被接受。
通常，决策场所将采用会议形式。也可以是电子邮件会话，或在审核会议期间进行。
撤消 FTP
有时，FTP 的作者希望撤消其 FTP。
在“评论”步骤后面添加了“已撤消”步骤：
已撤消的 FTP 是工程构想的重要记录。当作者撤消其 FTP 时，必须在 FTP 中添加撤消原因。然后，系统会将 FTP 复制到所有 FTP 的公开记录中，以供后人参考。
移除原因由 FTP 作者撰写，可能还会与 Fuchsia FIDL 团队的成员共同撰写。
理由应以以下两种方式提供可行的建议。
作者在 FTP 流程中学到了什么，促使他们提出了备选设计？
哪些 FTP 替代方案前景看好？
需要使用 FTP 的条件
我们了解到，并非对“FIDL”的所有更改都需要 FTP。没有人会希望在 fidlc 中进行小规模重构时提供设计文档。另一方面，引入新的消息布局或更改线路格式绝对需要使用 FTP。
我们对超过哪个阈值就需要使用 FTP 进行更改有何看法？ 我们遵循的一般规则是：
在以下任一情况下，更改都必须通过 FTP 流程：
解决方案空间很大，即所做的更改是众多可能不错的其他解决方案之一，并且需要做出艰难的设计权衡；
更改具有重大影响，即更改会大幅修改 FIDL 的行为，因此可能会给许多或所有 FIDL 用户带来风险；
更改的范围较大，即更改涉及 FIDL 的足够部分，因此需要仔细注意，以确定其是否可能会产生重大影响。
例如，对以下方面进行更改可能需要使用 FTP：
- FIDL 治理
- 设计原则
- 语言语法
- 类型系统
- 协议语义
- 线格格式
- 绑定规范
以下是一些 FTP 示例及其更改的方面：
RFC-0047：表：
类型系统）引入了一种表示类似记录的数据的新方法，首次使用封套。
线上传输格式）新增了表格和信封的线上传输格式。
绑定规范）一些 API 绑定建议。RFC-0023：协议的组合模型：
语言语法）将接口语法替换为协议语法。
协议语义）明确了协议组合的语义，包括支持缺少“is-a”关系。
绑定规范）禁止绑定利用多态性来
模型组合。RFC-0027：您只需要按照实际用量付费：
设计原则）引入了新设计原则。
FIDL 治理）明确要求将新引入的设计原则纳入 FTP 流程的一部分。RFC-0024：强制性来源兼容性：
FIDL 治理）修改了 FTP 模板，以添加有关来源兼容性的提示。
绑定规范）对
绑定启用了源代码兼容性要求。RFC-0049：FIDL 调整流程演变，即此更改：
FIDL 治理）旨在为 FTP 流程提供更多指导，
并认识到为 FIDL 做出贡献的其他方式。
相比之下，以下更改不属于 FTP：
创建新的 FIDL 绑定（例如 LLCPP 绑定）：
FIDL 旨在支持许多相互交互的实现。
预计会创建新的绑定，并且无需 Fuchsia FIDL 团队的任何批准即可完成。将对枚举成员的引用设为显式1：
在更改之前，系统支持my.library.MY_ENUM_MEMBER，但现在已将其替换为显式语法my.library.MyEnum.MY_ENUM_MEMBER。尽管更改了语言语法，但这项更改是对之前存在的功能的 bug 修复。如果库同时包含枚举成员CLASHING_NAME和常量CLASHING_NAME，则引用这两者中的任一项都是模糊的，因此fidlc会诉诸于不规范的类型解析规则来打破僵局。成员的范围规则保持不变，成员的范围限定为其声明，fidlc和所有绑定都遵循该规则。实现意图：在将原始类型转换为扁平类型后推迟类型构建：
在重做类型系统实现时，没有进行任何可观察到的更改。这项工作属于重构。实现意图：更改“消息”的表示法：虽然 JSON IR 会受到这项变更的影响，但这种呈现方式变更会使之前需要通过绑定（标题形状）隐式了解的某些概念变为显式了解。同样，没有任何可观察到的变化，并且除了代码结构（在
fidlc和绑定中）之外，没有任何影响。
为 FIDL 做出贡献，不仅限于 FTP
Fuchsia FIDL 团队的目标是“围绕 FIDL 促进协作和包容性”，具体而言，就是确保“整个 Fuchsia 团队都能畅所欲言，非 FIDL 团队成员的贡献得到适当的指导和支持，最终能顺利完成或在早期就被拒绝并说明原因”。
撰写 RFC 通常需要做大量工作，并且需要了解解决方案空间，以便正确证明相对于替代方案做出的具体设计选择。FTP 流程也非常繁重，本身可能令人不快。因此，FTP 流程本身对协作目标没有帮助。
其他贡献方式包括：
在 Fuchsia FIDL 团队聊天室中讨论用例和问题。该团队的所有成员都会密切关注对话，此论坛中的会话经常会导致大小不一的更改或优先顺序的变化。
参与 Fuchsia API 审核。在该平台上，您可以查看具体用例，并衡量各种 FIDL 功能组合来支持这些用例的效果。通过识别可通过调整功能或完全新增功能来增强的 API 设计模式，我们推动了多次演变。
向 Fuchsia FIDL 团队提交 bug。
描述问题陈述，并与 Fuchsia FIDL 团队和整个 Fuchsia 团队合作，探索可能的解决方案。
描述可能的解决方案，并与 Fuchsia FIDL 团队和整个 Fuchsia 团队合作对其进行评估。
对替代方法进行原型设计。
以“20% 工时”的形式加入 FIDL 团队，并负责 FIDL 团队分配的项目。
所有这些都可以帮助您获得清晰的问题陈述、直接更改 FIDL 或转换为 FTP。
实施策略
更新了 FIDL Tuning Proposals 页面。广泛宣传这项变更。在进行审核时，跟进所做更改。
工效学设计
无影响。
文档和示例
请参阅实施策略。
向后兼容性
无影响。
性能
无影响。
安全
无影响。
测试
无影响。
缺点、替代方案和未知情况
虽然有许多方法可以修改流程，但我们认为，建议的更改是一次适当的迭代，预计会带来净效益。未来可能会进一步优化此流程。
在先技术和参考文档
很多。其中之一是 Fuchsia 采用的“工程审核”流程。