RFC 模板
功能名称。(请填写一个独特的身份，
my_awesome_feature)开始日期: (填写今天的日期，YYY-MM-DD)
被提名的负责人：（受RFC影响的技术领域专家代表。这通常是技术负责人，但他们可以委托。在所有被提名的所有者签字之前，RFC不能被接受。）
概述
一段对该功能的解释。
回顾
这一部分对于让我们从正在实施的事情中学习是至关重要的。
什么时候进行回顾？
[] 复盘完成？
(将在哪里/如何举行，人们如何参与，结果在哪里？)
动机
我们为什么要这样做？它支持什么用例？预期的结果是什么？
指南级的介绍
就像在向另一个工程师介绍一个已经存在的提案一样介绍该提案。这通常意味着：
引入新的命名概念。
用示例来解释主要特点。
解释工程师是如何思考这个功能的。应该尽可能具体地解释其带来的影响。
如果适用的话（例如代码/架构建议），提供错误信息样本、弃用警告信息或迁移指导文档。
如果适用的话，描述向现有的工程师和新的工程师传授这些知识的区别。
对于面向实现的RFC来说，这一部分应该关注贡献者应该如何思考这个变化，并举例说明其具体影响。对于政策/流程型RFC，本节应提供一个以实例为导向的政策/流程介绍，并具体解释其影响。
参考实现级别的介绍
这是RFC的技术部分。对设计进行足够详细的介绍，以便
它与其他功能的交互是清晰的。
合理地清楚介绍该功能将如何实现。
通过实例剖析如何处理极端情况。
该部分应该回到上一节给出的例子，并更充分地详细地解释如何实现这些例子的。
缺点
为什么我们不应该这样做？
理由和替代方案
为什么这个设计是可能的设计空间中最好的？
还有哪些设计被考虑过，不选择这些设计的理由是什么？
不这样做的影响是什么？
现有技术
讨论与本提案有关的现有技术，包括好的和坏的。 这可以包括几个例子。
对于语言、库、工具等。这个功能在其他地方是否存在，他们的社区有什么经验？
对于社区建议。这个功能是否由在其他社区已经实现了，他们在这方面有什么经验？
对于其他团队。我们可以从其他社区所做的事情中吸取什么教训？
论文。是否有任何已发表的论文或有相关的帖子来讨论这个问题？如果你有一些相关的论文可以参考，这可以作为一个更详细的理论背景。
这一部分的目的是鼓励你作为作者思考其他地方的经验教训，为你的RFC的读者提供更全面的信息。 如果没有现有技术，那也没关系--你的想法无论是否是全新的，还是从其他地方改编而来，我们都很感兴趣。
未解决的问题
在提案被接受之前，你希望通过RFC过程来解决哪些部分的设计问题？
在提案酝酿成熟之前，你希望通过实现这个功能来解决哪些部分的设计问题？
你认为哪些相关问题超出了本RFC的范围，可以在未来独立于本RFC的解决方案而得到解决？
未来的可能性
思考你的提案的自然延伸和演变是什么，以及它将如何全面地影响团队和项目。 试着把这一节作为一个工具，更全面地考虑你的提案中与项目和团队的所有可能的相互作用。 还要考虑这一切如何与项目和相关子团队的路线图相适应。 这也是一个 "倾倒想法 "的好地方，如果它们超出了你正在写的RFC的范围，但又与之相关。 如果这些想法超出了你正在写的RFC的范围，但又与之相关，那么这里也是 "抛弃想法 "的好地方。 如果你已经试过了，却想不出任何未来的可能性。你可以简单地说，你想不出任何东西。 请注意，在未来可能性部分写下一些东西并不是接受当前或未来RFC的理由；这样的说明应该放在动机或理由部分。 在这个或以后的RFC中的动机或理由部分。该部分只是提供额外的信息。
Last updated