rfc.md

000-模版

• 功能名称。(请填写一个独特的身份，my_awesome_feature)
• 开始日期: (填写今天的日期，YYY-MM-DD)
• 被提名的负责人：（受RFC影响的技术领域专家代表。这通常是技术负责人，但他们可以委托。在所有被提名的所有者签字之前，RFC不能被接受。）

概述

一段对该功能的解释。

回顾

这一部分对于让我们从正在实施的事情中学习是至关重要的。

什么时候进行回顾？

[] 复盘完成？

(将在哪里/如何举行，人们如何参与，结果在哪里？)

动机

我们为什么要这样做？它支持什么用例？预期的结果是什么？

指南级的介绍

就像在向另一个工程师介绍一个已经存在的提案一样介绍该提案。这通常意味着：

• 引入新的命名概念。
• 用示例来解释主要特点。
• 解释工程师是如何思考这个功能的。应该尽可能具体地解释其带来的影响。
• 如果适用的话（例如代码/架构建议），提供错误信息样本、弃用警告信息或迁移指导文档。
• 如果适用的话，描述向现有的工程师和新的工程师传授这些知识的区别。

对于面向实现的RFC来说，这一部分应该关注贡献者应该如何思考这个变化，并举例说明其具体影响。对于政策/流程型RFC，本节应提供一个以实例为导向的政策/流程介绍，并具体解释其影响。

参考实现级别的介绍

这是RFC的技术部分。对设计进行足够详细的介绍，以便

• 它与其他功能的交互是清晰的。
• 合理地清楚介绍该功能将如何实现。
• 通过实例剖析如何处理极端情况。

该部分应该回到上一节给出的例子，并更充分地详细地解释如何实现这些例子的。

缺点

为什么我们不应该这样做？

理由和替代方案

• 为什么这个设计是可能的设计空间中最好的？
• 还有哪些设计被考虑过，不选择这些设计的理由是什么？
• 不这样做的影响是什么？

现有技术

讨论与本提案有关的现有技术，包括好的和坏的。 这可以包括几个例子。

• 对于语言、库、工具等。这个功能在其他地方是否存在，他们的社区有什么经验？
• 对于社区建议。这个功能是否由在其他社区已经实现了，他们在这方面有什么经验？
• 对于其他团队。我们可以从其他社区所做的事情中吸取什么教训？
• 论文。是否有任何已发表的论文或有相关的帖子来讨论这个问题？如果你有一些相关的论文可以参考，这可以作为一个更详细的理论背景。

这一部分的目的是鼓励你作为作者思考其他地方的经验教训，为你的RFC的读者提供更全面的信息。 如果没有现有技术，那也没关系--你的想法无论是否是全新的，还是从其他地方改编而来，我们都很感兴趣。

未解决的问题

• 在提案被接受之前，你希望通过RFC过程来解决哪些部分的设计问题？
• 在提案酝酿成熟之前，你希望通过实现这个功能来解决哪些部分的设计问题？
• 你认为哪些相关问题超出了本RFC的范围，可以在未来独立于本RFC的解决方案而得到解决？

未来的可能性

思考你的提案的自然延伸和演变是什么，以及它将如何全面地影响团队和项目。 试着把这一节作为一个工具，更全面地考虑你的提案中与项目和团队的所有可能的相互作用。 还要考虑这一切如何与项目和相关子团队的路线图相适应。 这也是一个 "倾倒想法 "的好地方，如果它们超出了你正在写的RFC的范围，但又与之相关。 如果这些想法超出了你正在写的RFC的范围，但又与之相关，那么这里也是 "抛弃想法 "的好地方。 如果你已经试过了，却想不出任何未来的可能性。你可以简单地说，你想不出任何东西。 请注意，在未来可能性部分写下一些东西并不是接受当前或未来RFC的理由；这样的说明应该放在动机或理由部分。 在这个或以后的RFC中的动机或理由部分。该部分只是提供额外的信息。