Skip to main content“对话请求” (RFD) 是ACP版本的RFC流程。RFD是提议新功能、收集社区对问题的意见以及记录设计决策的主要机制。
何时编写RFD
如果您打算对ACP或其文档进行”重大”更改，应考虑编写RFD。什么构成”重大”更改正在根据社区规范不断发展，并根据您提议更改的生态系统的部分而有所不同。
某些更改不需要RFD：
- 重新表述、重组或重构
- 添加或删除警告
- 严格改善客观、数值质量标准的添加（加速、更好的浏览器支持）
- 修复客观上不正确的行为
RFD流程
1. 通过打开PR提出
Fork仓库并将 docs/rfds/TEMPLATE.md 复制到 docs/rfds/my-feature.md（使用kebab-case命名）。RFD可以从极简开始 - 只需一个电梯演讲和现状就足以开始对话。拉取请求成为讨论论坛，通过协作迭代完善想法。
2. 当有支持者时合并到”草稿”
如果核心团队成员决定支持，RFD提案将合并到”草稿”部分。支持者成为联系人，并将与作者合作使其成为现实。一旦进入草稿，就可以开始实现（正确使用RFD名称进行功能门控）。实现也可以在特定的SDK或代理/客户端级别开始，以在更广泛采用之前证明设计以获得更好的审查和反馈。
RFD是跟踪实现进度的动态文档。朝着RFC工作的PR通常会更新它以反映设计或方向的变化。
2b. 移动到”待删除”
从未落地的RFD可由核心团队成员自行决定关闭。以草稿形式落地的RFD改为移动到”待删除”，直到有时间将其从代码库中完全删除，然后完全删除。
3. 完全实现时移动到”预览”
当支持者认为RFD已准备好进行更广泛的审查时，他们打开PR将其移动到”预览”。这向社区发出提供反馈的信号。PR在支持者决定是否落地之前保持开放几天。
4. 已完成
一旦进入预览，RFD可以通过最终PR移动到”已完成”。核心团队应发表评论并表达关切，但**最终决定始终由核心团队负责人做出”。根据RFD的内容，“已完成”是唯一可以表示单向门的状态（如果涉及稳定性承诺），因为在此之后更改可能需要对协议进行破坏性更改。
预览RFD不必完成。它们也可能回到草稿以等待进一步更改，甚至移动到”待删除”。
5. 实现和完成
RFD生命周期
- 早期草稿：初始想法、头脑风暴、早期探索
- 成熟草稿：格式良好的提案，准备进行更广泛的审查
- 已接受：已批准实施，可能引用实施工作
- 待删除（尚未？）：目前决定反对，但保留以供将来考虑
- 已完成：实施完成并已合并
项目目前有一个设计团队，Zed团队作为负责人（BDFL）。核心团队的支持者指导RFD完成流程，但最终决定权在团队负责人手中。这种结构在保持速度的同时预期未来的治理扩展。
讨论和审核
详细讨论通常在 Zulip 上进行，PR评论用于流程决策。详细讨论的结果应纳入相关RFD。RFD支持者通过在FAQ部分收集问题来积极策划讨论。如果PR讨论变得太长，应关闭它们，总结反馈，并重新打开并链接到原始内容。
所有RFD均在Apache 2.0下许可。项目保持开源。
