ADR Creation Process

1. 复制 adr-template.md 文件。使用以下文件名模式：adr-next_number-title.md
2. 如果你想尽早获得反馈，请创建一个草稿 Pull Request，并向负责维护的团队征求意见。
3. 确保问题、上下文和推荐方案清晰且文档充分。务必记录可替代的方案空间，并说明它们为何被弃用。
4. 在 README 文件的目录列表中添加一条条目。
5. 创建一个 Pull Request，以提议新的 ADR。

​

ADR 生命周期

1. 每个提案都 SHOULD 从一个新的 GitHub Issue 开始，或作为现有 Issue 的结果。该 Issue 只需包含简要的提案摘要。
2. 一旦动机得到验证，就创建一个 GitHub Pull Request（PR），并基于 adr-template.md 添加一个新文档。
3. ADR 不必在单个 PR 中以 accepted 状态进入 main。如果动机清晰且方案合理，我们 SHOULD 能够将其合并并保持 proposed 状态。相比长时间未合并的 Pull Request，迭代式方法更可取。
4. 如果一个 proposed ADR 被合并，那么它应在 ADR 文档说明或 GitHub Issue 中清楚记录尚未解决的问题。
5. PR SHOULD 始终被合并。对于有缺陷的 ADR，我们仍然更倾向于以 rejected 状态将其合并。唯一一个 ADR SHOULD NOT 被合并的情况，是作者放弃了它。
6. 已合并的 ADR SHOULD NOT 被删除。

​

ADR 状态

{CONSENSUS STATUS} {IMPLEMENTATION STATUS}

​

共识状态

• 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。
• SUPERSEEDED 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 and solicit input from the stewarding team, if you want to get an early feedback.
3. Make sure that the problem, the context and a recommended solution is clear and well documented. Be sure to document alternate solution spaces and give reasons why they have been discarded.
4. Add an entry to a list in the README file Table of Contents.
5. Create a Pull Request to propose a new ADR.

​

ADR life cycle

1. Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary.
2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the adr-template.md.
3. An ADR 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.
4. If a proposed ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue.
5. 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.
6. Merged ADRs SHOULD NOT be deleted.

​

ADR status

{CONSENSUS STATUS} {IMPLEMENTATION STATUS}

​

Consensus Status

• 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 an 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.
• SUPERSEEDED 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.