什么是 RFC？

“RFC”（征求意见稿）过程的目的是为了新功能进入框架提供一个一致和受控的途径。

许多变化，包括错误修复和文档改进，都可以通过正常的 GitHub PR 工作流程来实施和 review。

但有些变化是“实质性的”，我们要求这些变化要经过一些设计过程，并在 Vue 核心团队和社区中产生共识。

RFC 的生命周期

一个 RFC 会经历以下阶段：

• Pending：当 RFC 被作为 PR 提交时。
• Active：当 RFC PR 被合并并正在实现时。
• Landed：当 RFC 的建议修改在一个实际的版本中被发布时。
• Rejected：放一个 RFC PR 没有被合并就被关闭。

Pending RFC List

何时遵循这个流程

如果你打算对下列项目之一进行“实质性”修改，你需要遵循这个流程：

• Vue core
• Vue Router
• Vuex
• Vue CLI

我们对这些仓库的 RFC 流程进行了限制，以便用更易于管理的方式测试该流程，并可能在未来将其扩展到 vuejs 组织下的更多项目。目前，如果你想对其他项目提出修改建议，请使用各自的问题列表。

构成“实质性”变化的内容根据社区规范而不断变化，但可能包括以下内容：

• 创造新 API 的新功能
• 改变现有 API 的语义或行为
• 删除已作为发布渠道的一部分提供的功能
• 引入新的惯用用法或约定，即使它们不包括对 Vue 本身的代码更改。

某些更改不需要 RFC：

• 严格改进客观的、数字的质量标准的添加项（加速、更好的浏览器支持）
• 修复客观上不正确的行为
• 重新措辞、重组或重构
• 增加或删除警告
• 只可能被其他 Vue 的实现者注意到的添加项，对 Vue 的用户不可见

如果你提交一个 PR 来实现一个新的功能，而没有经过 RFC 流程，它可能会被关闭，并礼貌的要求你提交一个 RFC。

为什么你需要这样做

你考虑对 Vue 的新功能或变化提出建议，这很好 —— 我们感谢你的贡献意愿！你的建议是对的。然而，随着 Vue 的应用越来越广泛，我们需要认真对待稳定性，因此必须仔细考虑我们所做的每一个可能影响最终用户的变化的影响。另一方面，我们也觉得 Vue 已经到了一个阶段，我们要开始有意识的防治新 API 的进一步复杂性。

这些约束和权衡对于那些只是为了解决他们刚刚遇到的具体问题而提出改变的用户来说，可能并不那么明显。RFC 流程是一种引导你了解我们在对 Vue 进行修改时的思考过程的方式，这样我们在讨论为什么要做这些修改或不做这些修改时就能站在同一起跑线上。

提交前收集反馈

在深入研究 RFC 所需的 API 设计细节之前，获得对你的概念的反馈往往是有帮助的。你可以在这个论坛上开一个问题，开始一个高层次的讨论，目的是最终制定一个带有具体实现设计的 RFC PR。

流程是什么

简而言之，要想在 Vue 中加入一个重要的功能，首先必须将 RFC 以 markdown 文件的形式合并到 RFC repo 中。在这一点上，RFC 是 “active”，可以被实现的，目的是最终被纳入 Vue。

1. 根据本 repo 中的模版（0000-template.md)，在 Markdown 文件中完成你的提案。
   • 在细节上多下功夫：如果 RFC 没有提出令人信服的动机，没有显示出对设计的影响的理解，或者对缺点或替代方案没有诚意，那么它往往会受到冷落。
2. 在讨论区开一个新的主题，并确保将类别设置为 “RFC Discussions”
   • 在讨论线程中建立共识并整合反馈。得到广泛支持的 RFC 比那些没有收到任何评论的 RFC 更有可能取得进展。
3. 如果该提案得到社区成员的很大的兴趣和普遍的积极反馈，你可以准备一个 Pull Request。
   • Fock 这个 repo
   • 以 active-rfcs/0000-my-feature.md 的形式创建你的提案（其中 “my-feature” 是描述性的。先不要制定 RFC 编号）。
   • 提交一个 PR。请确保链接到讨论线程。
4. 最终，核心团队将决定 RFC 是否纳入 Vue 的候选。
   • RFC 可以根据核心团队和社区的反馈进行修改。重大的修改可能会引发新的最终评论期。
   • 在公众讨论结束后，RFC 可能会被拒绝，并对拒绝的理由进行了总结。然后，核心团队的一名成员应该关闭 RFC 的相关 PR。
   • RFC 可以在其最后评论期结束时被接受。一名核心小组成员将合并 RFC 的相关 PR，此时 RFC 将成为 “active”。

Active RFC 的细节

一旦 RFC 变为 active，作者就可以实现它，并将该功能作为一个 PR 提交给 Vue repo。成为 “active” 并不是一个橡皮图章（rubber stamp），尤其是并不意味着该功能最终会被合并；它确实意味着核心团队原则上同意该功能，并愿意将其合并。

此外，给定的 RFC 已经被接受并且是 “active” 的这个事实并不意味着对其实现的优先级是什么，也不意味着目前是否有人在从事这项工作。

对 active RFC 的修改可以在后续的 PR 中进行。我们努力使每一个 RFC 都能反映功能的最终设计；但这个过程的性质意味着我们不能期望每个合并的 RFC 都能真正的反映下一个主要版本时的最终结果；因此我们努力使每个 RFC 文件与计划中的语言功能保持一定程度的同步，通过对文件的后续 pull request 跟踪这些变化。

实现 RFC

RFC 的作者没有义务去实现它。当然，RFC 的作者（像其他开发者一样）在 RFC 被接受之后，欢迎发布实现方案以供 review。

如果有的话，一个 active 的 RFC 应该列出实现 PR 的链接。对其实现的反馈应该在实现 PR 中进行，而不是在原始 RFC PR 中进行。

如果你对 “active” RFC 的实现感兴趣，但不确定是否其他人已经在做了，请随时询问（例如，在相关问题上留言）。

review RFC

核心团队的成员将尝试定期 review 一些开放的 RFC pull request。如果核心团队成员认为一个 RFC PR 已经准备好被接受为 active 状态，他们可以使用 GitHub 的 review 功能批准该 PR，以表示他们对 RFC 的认可。

Vue 的 RFC 流程得益于 React RFC process, Rust RFC process 和 Ember RFC process。