1. 复制 rfc-template.md 文件。使用以下文件名模式：rfc-next_number-title.md
  2. 如果你希望尽早获得反馈，请创建一个草稿 Pull Request。
  3. 确保背景上下文和解决方案都清晰且有完善文档说明。
  4. 在 README 文件中的列表里新增一项条目。
  5. 创建一个 Pull Request 来提议新的 ADR。

​
什么是 RFC？

RFC 可以看作一种异步白板讨论方式。它旨在替代分布式团队必须集中在一起才能做决策的需求。当前，Cosmos SDK 团队和贡献者分布在世界各地。团队会通过工作组开展同步讨论，而 RFC 可用于记录这些讨论，使更广泛的受众能够更好地理解即将进入软件的变更。 Cosmos SDK 当前对 RFC 与 ADR 的主要区分在于：前者用于就潜在变更或特性达成共识并传播相关信息；如果某项特性或变更已经达成共识，且无需再专门阐述将进入软件的变更，则使用 ADR。ADR 会说明这些变更，但所需的沟通量更少。

​
RFC 生命周期

RFC 的创建是一个迭代式过程。RFC 旨在作为一种分布式协作讨论形式，可能会包含大量评论，通常也是在没有工作组或同步沟通情况下产出的结果。
  1. 提案可以从新的 GitHub Issue 开始，也可以源自现有 Issue 或某次讨论。
  2. RFC 不必在单个 PR 中以 accepted 状态进入 main。如果动机清晰且解决方案合理，我们应当能够将其合并并保持为 proposed 状态。相比长时间未合并的 Pull Request，采用迭代式方法更可取。
  3. 如果一个 proposed RFC 被合并，那么它应当在 RFC 文档备注或 GitHub Issue 中清楚记录尚未解决的问题。
  4. PR 应当始终被合并。即使 RFC 存在缺陷，我们仍然更倾向于以 rejected 状态将其合并。RFC 不应被合并的唯一情况是作者放弃了它。
  5. 已合并的 RFC 不应被清理删除。
  6. 如果已经达成共识并获得了足够反馈，那么该 RFC 就可以被接受。
注意：RFC 是在没有围绕该问题开展工作组或团队会议时编写的。RFC 旨在作为一种分布式白板讨论方式。如果某个提案已经有工作组在推进，就没有必要再编写 RFC，因为同步白板讨论已经在进行中。

​
RFC 状态

状态由两个部分组成： 
{CONSENSUS STATUS}

​
共识状态

DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx
                  \        |
                   \       |
                    v      v
                     ABANDONED
  • DRAFT：[可选] 处于进行中的 ADR，尚未准备好进行全面评审。该状态用于以 Draft Pull Request 的形式展示早期工作并获取早期反馈。
  • PROPOSED：覆盖完整解决方案架构、但仍在评审中的 ADR，项目相关方尚未达成一致。
  • LAST CALL <date for the last call>：[可选] 明确通知我们已接近接受更新。将状态改为 LAST CALL 意味着已经达成社会性共识（由 Cosmos SDK 维护者形成），但我们仍希望留出时间让社区作出反应或进行分析。
  • ACCEPTED：代表当前已实现或即将实现架构设计的 ADR。
  • REJECTED：如果项目相关方之间的共识如此决定，ADR 可以从 PROPOSED 或 ACCEPTED 转为 rejected。
  • SUPERSEDED by ADR-xxx：已被新的 ADR 取代的 ADR。
  • ABANDONED：原作者不再继续推进该 ADR。

​
RFC 中使用的语言

  • 背景/目标应使用现在时书写。
  • 避免使用第一人称的个人化表述。
  1. Copy the rfc-template.md file. Use the following filename pattern: rfc-next_number-title.md
  2. Create a draft Pull Request if you want to get an early feedback.
  3. Make sure the context and a solution is clear and well documented.
  4. Add an entry to a list in the README file.
  5. Create a Pull Request to propose a new ADR.

​
What is an RFC?

An RFC is a sort of async whiteboarding session. It is meant to replace the need for a distributed team to come together to make a decision. Currently, the Cosmos SDK team and contributors are distributed around the world. The team conducts working groups to have a synchronous discussion and an RFC can be used to capture the discussion for a wider audience to better understand the changes that are coming to the software. The main difference the Cosmos SDK is defining as a differentiation between RFC and ADRs is that one is to come to consensus and circulate information about a potential change or feature. An ADR is used if there is already consensus on a feature or change and there is not a need to articulate the change coming to the software. An ADR will articulate the changes and have a lower amount of communication .

​
RFC life cycle

RFC creation is an iterative process. An RFC is meant as a distributed collaboration session, it may have many comments and is usually the byproduct of no working group or synchronous communication
  1. Proposals could start with a new GitHub Issue, be a result of existing Issues or a discussion.
  2. An RFC doesn’t have to arrive to main with an accepted status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a proposed status. It’s preferable to have an iterative approach rather than long, not merged Pull Requests.
  3. If a proposed RFC is merged, then it should clearly document outstanding issues either in the RFC document notes or in a GitHub Issue.
  4. The PR SHOULD always be merged. In the case of a faulty RFC, we still prefer to merge it with a rejected status. The only time the RFC SHOULD NOT be merged is if the author abandons it.
  5. Merged RFCs SHOULD NOT be pruned.
  6. If there is consensus and enough feedback then the RFC can be accepted.
Note: An RFC is written when there is no working group or team session on the problem. RFC’s are meant as a distributed whiteboarding session. If there is a working group on the proposal there is no need to have an RFC as there is synchronous whiteboarding going on.

​
RFC status

Status has two components: 
{CONSENSUS STATUS}

​
Consensus Status

DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx
                  \        |
                   \       |
                    v      v
                     ABANDONED
  • DRAFT: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
  • PROPOSED: an ADR covering a full solution architecture and still in the review - project stakeholders haven’t reached agreement yet.
  • LAST CALL <date for the last call>: [optional] clear notify that we are close to accept updates. Changing a status to LAST CALL means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
  • ACCEPTED: ADR which will represent a currently implemented or to be implemented architecture design.
  • REJECTED: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
  • SUPERSEDED by ADR-xxx: ADR which has been superseded by a new ADR.
  • ABANDONED: the ADR is no longer pursued by the original authors.

​
Language used in RFC

  • The background/goal should be written in the present tense.
  • Avoid using a first, personal form.