| 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 团队（非官方名称 Luthiers）的成员以及他们认为适合在此流程中包含或委托的任何人进行审核。”
审核 FTP 最常用的论坛是面对面会议。会议首先由 FTP 作者展示自己的设计。然后，会议主持人（今天通常是 FIDL 负责人）将处理设计文档中的评论，还可能首先设置一份简短的议程，即应该讨论的“尚未完结的内容”。
与“eng 审核流程”不同，通常的做法是在会议期间解决尚未解决的项目（记录了会议记录，随后将其纳入 FTP），然后由 FIDL 负责人决定是接受还是拒绝 FTP 来结束会议。
人们期望在会议结束时作出决策，以及 FIDL 主管同时扮演主持人和决策者的双重角色，这带来了摩擦：在 FTP 会议期间突然出现紧张、参与者感觉有压力，难以发言；在最后一刻做出最终的设计决策，以便批准快速修改的 FTP。
为了解决这种糟糕的动态机制，我们修改了“审核”步骤，并添加了明确的“决策”步骤。其中有些措辞是在工程审核流程中借鉴的。 “审核”步骤有以下变化：
目前，我们正在审核 FTP 及所有未解决的评论。
该提案将由 Fuchsia FIDL 团队（由 fuchsia.git 代码库中的 OWNERS 文件定义，非官方称作 Luthiers 团队）以及他们认为适合在流程中纳入或委托的人员进行审核。例如，在决定特定语言的绑定时，他们可能会添加特定语言专家。如有必要，像 Fuchsia 中的其他技术决策一样，有争议的决策也可以上报。
[ADD] 审核通常在一次或多次线下会议“FTP 审核会议”中进行。此外，在适当的情况下，审核也可以使用异步通信进行）。
FTP 审核会议首先由作者展示自己的设计。然后，教员将在 FTP 中处理评论，请曾在文档中发表评论的人提供反馈。
[ADD] 理想情况下，教员和演示者是不同的人。教员的目标是确保设计的所有方面都得到处理，并确保会议顺利进行。理想情况下，为了避免让人产生偏见，教员对结果没有特定的利益，而演示者在演示的设计中也暗含着利益。
[添加] 我们不一定需要在会议期间结束每条反馈，也不一定需要讨论每条最后一条评论（例如，如果有大量评论或多条评论都是针对同一根本问题）。相反，教员应进行优化，以为演示者提供广泛的反馈，而不是推动每个论点得出结论。待定的未解决的问题可能会在后续审核会议中或在决策过程中得到解决。
审核最终会产生三个结果。
首先，为做出决策，您可能需要提出未解决的问题或提供反馈。在这种情况下，FTP 会移回“评论”阶段。
其次，提案可能会被拒绝，审核人员会说明原因。
第三，可能被接受。
在“审核”步骤之后添加了“决策”步骤：
在五 (5) 个工作日内，Fuchsia FIDL 团队（由 Owners 文件定义）的成员（最终决策者是 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 Tuning Process Evolution，即这项变更：
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依靠 acky 类型解析规则来打破僵局。成员的范围规则保持不变，成员的范围限定为其声明，并且fidlc和所有绑定都遵循该规则。想要实现：推迟类型构造在 RAW 转换为平面转换：
在对类型系统的实现进行返工时，没有完成任何可观察的更改。这是一项重构工作。实现意图：更改“消息”的表示法：虽然 JSON IR 会受到此变更的影响，但这种呈现上的变化可让以前需要通过绑定（标头形状）隐式已知的某些概念明确知道。同样，没有可观察的更改，并且对代码结构（在
fidlc和绑定中）之外没有影响。
为 FIDL 贡献力量（FTP 以外的平台）
Fuchsia FIDL 团队的目标是“促进 FIDL 的协作和包容性”，特别是确保“总体的 Fuchsia 团队感受到我们能够听到他们对粗鲁的不懈追求；非 FIDL 团队成员做出的贡献会得到适当的指导和支持，或者有理由尽早拒绝。”
编写 RFC 通常需要完成大量工作，并且了解解决方案空间以适当证明相对于替代方案所做的特定设计选择。FTP 流程也相当繁琐，本身可能会令人不快。因此，FTP 流程本身对协作目标没有帮助。
其他贡献方式包括：
在 Fuchsia FIDL 团队聊天室讨论应用场景和问题。团队的所有成员都密切关注对话，并且此论坛中的会话常常会导致大大小小的变化或优先级发生变化。
参与 Fuchsia API 审核。这个平台对于了解具体用例以及衡量各种 FIDL 功能的组合支持这些用例至关重要。认识到 API 设计模式可以推动 API 设计模式的多重演变，而通过调整功能或集中推出新功能，这种模式可以进一步推动 API 设计。
向 Fuchsia FIDL 团队提交 bug。
描述问题陈述，并与 Fuchsia FIDL 团队和整个 Fuchsia 团队合作，探索可能的解决方案。
描述可能的解决方案，并与 Fuchsia FIDL 团队和整个 Fuchsia 团队合作进行评估。
对替代方法进行原型设计。
作为“20% 的用户”加入 FIDL 团队，并负责 FIDL 团队分配的项目。
所有这些都可能会导致捕获清晰的问题陈述、直接更改 FIDL 或转换为 FTP。
实施策略
更新“FIDL 调整提案”页面。广泛宣传这一变更。在开展审核时，跟进更改。
工效学设计
无影响。
文档和示例
请参阅实现策略。
向后兼容性
无影响。
性能
无影响。
安全性
无影响。
测试
无影响。
缺点、替代方案和未知情况
虽然有很多方法可以修改流程，但我们认为建议的更改只是一次适度迭代，预计会带来净收益。预计未来流程的演变。
早期技术和参考资料
很多。一个是 Fuchsia 采用的“工程审核”流程。