ADR Creation Process

1. 复制 adr-template.md 文件。使用以下文件名模式：adr-next_number-title.md
2. 如果你希望尽早获得反馈，请创建一个草稿 Pull Request，并向负责治理的团队征求意见。
3. 确保问题、上下文以及推荐解决方案清晰且有完整文档记录。务必记录备选解决方案空间，并说明它们被舍弃的原因。
4. 在 README 文件的列表中添加一项：目录。
5. 创建一个 Pull Request 来提议新的 ADR。

​

ADR 生命周期

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

​

ADR 状态

{CONSENSUS STATUS} {IMPLEMENTATION STATUS}

​

共识状态

• DRAFT：[可选] 表示仍在进行中的 ADR，尚未准备好进行广泛评审。用于以 Draft Pull Request 的形式展示早期工作并获取早期反馈。
• PROPOSED：表示已覆盖完整解决方案架构、但仍处于评审中的 ADR，项目相关方尚未达成一致。
• 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.