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

​
什么是 ADR？

ADR 是一种用于记录实现与设计的文档，这些内容可能已经在 RFC 中讨论过，也可能没有讨论过。RFC 的目标是在分布式环境中替代同步沟通，而 ADR 的目标是记录已经做出的决策。ADR 通常不会带来太多沟通成本，因为相关讨论已经记录在 RFC 或同步讨论中。如果共识来自同步讨论，则应在 ADR 中加入一段简短摘录来说明目标。

​
ADR 生命周期

创建 ADR 是一个迭代式过程。与其引入大量沟通成本，不如在决策已经做出、只需要补充实现细节时使用 ADR。ADR 应记录针对特定问题形成的集体共识，以及应如何解决该问题。
  1. 每个 ADR 都应始于 RFC，或始于已经达成共识的讨论。
  2. 一旦达成共识，就基于 adr-template.md 创建一个包含新文档的 GitHub Pull Request（PR）。
  3. 如果一个 proposed 状态的 ADR 被合并，则应在 ADR 文档备注或 GitHub Issue 中清楚记录尚未解决的问题。
  4. PR 应当始终被合并。即使 ADR 存在问题，我们仍然更倾向于以 rejected 状态将其合并。唯一不应合并 ADR 的情况是作者放弃了它。
  5. 已合并的 ADR 不应被清理掉。

​
ADR 状态

状态由两个部分组成： 
{CONSENSUS STATUS} {IMPLEMENTATION STATUS}
IMPLEMENTATION STATUS 只能是 Implemented 或 Not Implemented。

​
共识状态

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。

​
ADR 中使用的语言

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

​
What is an ADR?

An ADR is a document to document an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchronous communication in a distributed environment, an ADR is meant to document an already made decision. An ADR won’t come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchronous discussion, then a short excerpt should be added to the ADR to explain the goals.

​
ADR life cycle

ADR creation is an iterative process. Instead of having a high amount of communication overhead, an ADR is used when there is already a decision made and implementation details need to be added. The ADR should document what the collective consensus for the specific issue is and how to solve it.
  1. Every ADR should start with either an RFC or a discussion where consensus has been met.
  2. Once consensus is met, a GitHub Pull Request (PR) is created with a new document based on the adr-template.md.
  3. If a proposed ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue.
  4. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a rejected status. The only time the ADR SHOULD NOT be merged is if the author abandons it.
  5. Merged ADRs SHOULD NOT be pruned.

​
ADR status

Status has two components: 
{CONSENSUS STATUS} {IMPLEMENTATION STATUS}
IMPLEMENTATION STATUS is either Implemented or Not Implemented.

​
Consensus Status

DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx
                  \        |
                   \       |
                    v      v
                     ABANDONED
  • DRAFT: [optional] an ADR which is a work in progress, not being ready for a general review. This is to present an early work and get 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 an agreement yet.
  • LAST CALL <date for the last call>: [optional] Notifies that we are close to accepting 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 ADR

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