可以通过正常的 GitHub Pull 请求工作流程来实现和检查许多更改，包括错误修复和文档改进。
但是，有些更改是“实质性的”，我们要求对这些更改进行一些设计过程。
“RFC”（征求意见）过程旨在为新功能进入项目提供一致且受控的路径。
如果您打算对 Supeset 项目或其文档的任何部分进行“实质性”更改，则需要遵循此过程。构成“实质性”变化的是基于社区规范的演变，但可能包括以下内容。
- 一个新的
Supeset命令行选项。 Supeset核心的新功能。- 重构现有的
Supeset核心功能。 - 任何重大变化。
除这些之外，TSC 还可根据请求的大小或范围，为它认为“实质性”的任何其他更改请求 RFC。
如果您提交拉取请求以实现新功能而未通过 RFC 流程，则可能会由于礼貌的请求而关闭，以先提交 RFC。
在提交 RFC 之前，请在要进行更改的存储库中打开一个问题（例如，要对 Supeset 进行更改，请在 Supeset/supeset 存储库中打开一个问题）。公开问题的目的是收集社区和 Supeset 团队的反馈，以确保有足够的兴趣来组建 RFC。
一旦 Supeset 团队表明有足够的兴趣，您就会被要求创建 RFC，以更详细地描述您要进行的更改。
注意： 请不要与您的原型或概念证明一起提交拉取请求。相反，在提交 RFC 时，请包括指向您的 fork 或 branch 的链接（请参阅下一节）。
要提交新的 RFC，请按照下列步骤操作：
1.Fork RFC 仓库。
2.在 designs 目录中创建一个目录。目录名称应以年份开头，并包含有意义的描述，例如 designs/2018-typescript-support。
3.将适当的模板文件从模板目录复制到适当的 designs 子目录（例如 designs/2018-typescript-support/README.md）。确保将文件命名为 README.md，以便在 GitHub 界面中轻松查看。
4.如果要在 RFC 中包图片，请将其与 README.md 放在同一目录中。
5.填写 RFC。请尽可能详细地填写模板的每个部分。
6.向您的仓库提交所有文件的拉取请求。这将开始批准过程（详细信息如下）。
7.接受的 RFC 将直接合并到此存储库中；不接受的 RFC 将关闭其合并请求，而不合并它们。
提交 RFC 后，将通过以下过程：
1.初始评论期（21-90 天）： 邀请社区和 Supeset 团队提供有关建议的反馈。在此期间，您应该期望根据提供的反馈来更新 RFC。很少有 RFC 未经批准就可以准备批准，因此这段时间对于微调想法和建立共识很重要。（初始评论期中的 PR 会应用“初始评论”标签）初始评论期必须至少持续 21 天且不超过 90 天，以便团队和社区有足够的时间发表评论。TSC 可能决定拒绝 RFC，而无需将其提升到最终意见征询期。
2.最终意见征询期（7 天）： 解决所有反馈后，拉取请求作者将请求一个最终意见征询期，在此期间，Supeset TSC 成员将提供他们的最终反馈，并同意拉取请求或声明其不同意。（最后评论期中的 PR 会应用“最终评论”标签。）当 RFC 进入最后评论期时，Supeset TSC 成员会通过 GitHub 通知。
- 批准和合并： 如果 TSC 在批准 RFC 上达成共识，则合并请求。如果在拉取请求上未达成共识，则将在下一次 TSC 会议上讨论 RFC，以确定是否继续前进。批准并合并 RFC 表示 TSC 认为该更改在方向上是正确的，并且希望看到它在 Supeset 中实现。RFC 不必是最终规范，因为我们可以在实现阶段进行调整并考虑边缘情况。
注意： 如果两个或多个 RFC 试图解决相同的问题或需求，则 TSC 将考虑所有竞争的 RFC 一起确定要批准的 RFC。或者，TSC 可以请求合并竞争的 RFC，以创建混合解决方案。
一旦将 RFC 合并到此存储库中，作者就可以实现它并向适当的 Supeset 存储库提交拉取请求，而不会引起任何问题。请注意，仍然需要与 RFC 分开审查实现，因此您应该期待更多的反馈和迭代。
如果 RFC 作者选择不实施 RFC，则任何人都可以实施 RFC。不能保证 Supeset 团队将实现其作者未实现的 RFC。
实施期间对设计的更改应通过更新相关的 RFC 来体现。目的是让 RFC 重新回顾一下以了解所提供的 Supeset 功能的动机和设计。
RFC 的作者没有义务实施它。当然，欢迎 RFC 作者（像其他开发人员一样）在 RFC 被接受后发布实现以供审核。
当拉取请求已实现 RFC 时，应使用实现该 PR 的链接来更新 RFC。
感谢 ESLint RFC 流程 为 Supeset 的 RFC 流程带来的启发。