Skip to main content作者：@benbrandt
电梯演讲
您提议进行什么更改？可以使用项目符号。
引入”对话请求”(RFD)流程，用结构化的、社区友好的设计文档取代临时设计讨论，追踪功能从概念到完成的整个过程。
今天的事情是如何运作的，这导致了什么问题？我们为什么要改变？
目前所有开发工作主要由 Zed 团队进行，跟踪来自多个团队的请求和提案。目标是创建一个有助于保持文件组织的流程，并且可以扩展以支持新兴社区的参与。
美好的未来
一旦这个功能存在，事情将如何发展？
项目许可
所有代码和 RFD 均在 Apache 2.0 许可下许可。该项目旨在保持开源并永久免费提供。
决策方式
在初始阶段，项目将有一个”设计团队”，由 Zed 团队以”BDFL”身份运作。预期是随着项目发展，将建立更具结构的治理结构。设计团队就 RFD 做出所有决定并设定整体项目方向。
RFD 生命周期
RFD 通过打开 PR 来提出
RFD 从一个 PR 开始，将新文件添加到”草稿”部分。RFD 可以从极简开始 - 只需一个电梯演讲和现状就足以开始对话。拉取请求成为讨论论坛，通过协作迭代完善想法。
随着讨论的进行，RFD 的 FAQ 应被扩展。如果讨论时间足够长，应关闭 PR，汇总反馈，然后重新打开并链接到原始 PR。
一旦核心团队成员决定支持，PR 就会合并到”草稿”
如果核心团队成员决定支持，RFD 提案将合并到”草稿”部分。然后支持者成为该提案的联系人，他们将与提案作者和其他人合作使其成为现实。核心团队成员不需要寻求共识来将提案合并到草稿，但他们应该仔细倾听其他核心团队成员的关切，因为如果这些关切最终得不到解决，将很难推动 RFD 前进。
一旦提案移到草稿，代码和实现可以开始进入 PR。这项工作需要正确地进行功能门控，并用 RFD 的名称标记。
如需要，RFD 的进一步讨论可以在 Zulip 上进行。
移至”预览”部分
当支持者认为 RFD 已准备好让其他人查看时，他们可以打开 PR 将文件移至预览部分。这是向社区（特别是其他核心团队成员）发出的信号，让他们查看提案并发表意见。PR 应保持开放”几天”，以便人们有机会留下反馈。支持者有权决定是否落地 PR。与以往一样，所有新反馈都应记录在 FAQ 部分。
决定接受 RFD
当他们认为 RFD 已准备好完成时，支持者请求团队审查。团队可以在讨论期间提出关切和注意事项。RFD 的最终决定由核心团队负责人做出。
RFD 的实施
一旦被接受，RFD 成为跟踪实施进度的动态文档。设计文档中的状态徽章链接回相关的 RFD，在”我们为什么构建这个”和”它如何工作”之间建立清晰连接。当使用代理构建代码时，代理应在实施过程中阅读 RFD 以了解设计原理，并用实施进度更新它们。
审核和管理 RFD 讨论
在周期中移动 RFD 涉及打开 PR。这些 PR 将成为进行对话和讨论的地方——但不是唯一的地方，我们期望更详细的讨论在 Zulip 或其他沟通渠道上进行。RFD 所有者和支持者应通过收集出现的问题并确保它们在 FAQ 中得到涵盖来积极”策划”讨论。重复的问题可以指向 FAQ。
如果 PR 上的讨论达到了 Github 开始隐藏评论的程度，通常应该关闭 PR，收集反馈，然后重新打开。
实施计划
您的实施计划是什么？
- ✅ 创建 RFD 基础设施（about、TEMPLATE、导航设置）
- ✅ 建立生命周期：草稿 → 预览 → 已接受 → 已完成
- ⏳ 为正在进行的主要功能编写 RFD
常见问题
为什么是”对话请求”而不是”评论请求”？
嗯，部分原因是”对话”强调对话和探索，而不仅仅是收集对预定设计的反馈。我们还从 Niko Matsakis 和 Symposium 项目（经许可）巧妙地借鉴了这个流程，以便我们能够从他们的经验中受益。
修订历史
- 2025-10-28：初始版本，与 RFD 基础设施一起创建
