Skip to content

Latest commit

 

History

History
101 lines (80 loc) · 3.18 KB

adr-template.md

File metadata and controls

101 lines (80 loc) · 3.18 KB
Raw

ADR {ADR-NUMBER}: {TITLE}

Changelog

  • {date}: {changelog}

Status

An architecture decision is considered "proposed" when a PR containing the ADR is submitted. When merged, an ADR must have a status associated with it, which must be one of: "Accepted", "Rejected", "Deprecated" or "Superseded".

An accepted ADR's implementation status must be tracked via a tracking issue, milestone or project board (only one of these is necessary). For example:

Accepted

[Tracking issue](https://github.com/cometbft/cometbft/issues/123)
[Milestone](https://github.com/cometbft/cometbft/milestones/123)
[Project board](https://github.com/orgs/cometbft/projects/123)

Rejected ADRs are captured as a record of recommendations that we specifically do not (and possibly never) want to implement. The ADR itself must, for posterity, include reasoning as to why it was rejected.

If an ADR is deprecated, simply write "Deprecated" in this section. If an ADR is superseded by one or more other ADRs, provide local a reference to those ADRs, e.g.:

Superseded by [ADR 123](./adr-123.md)

Accepted | Rejected | Deprecated | Superseded by

Context

This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.

Alternative Approaches

This section contains information around alternative options that are considered before making a decision. It should contain a explanation on why the alternative approach(es) were not chosen.

Decision

This section records the decision that was made. It is best to record as much info as possible from the discussion that happened. This aids in not having to go back to the Pull Request to get the needed information.

Detailed Design

This section does not need to be filled in at the start of the ADR, but must be completed prior to the merging of the implementation.

Here are some common questions that get answered as part of the detailed design:

  • What are the user requirements?

  • What systems will be affected?

  • What new data structures are needed, what data structures will be changed?

  • What new APIs will be needed, what APIs will be changed?

  • What are the efficiency considerations (time/space)?

  • What are the expected access patterns (load/throughput)?

  • Are there any logging, monitoring or observability needs?

  • Are there any security considerations?

  • Are there any privacy considerations?

  • How will the changes be tested?

  • If the change is large, how will the changes be broken up for ease of review?

  • Will these changes require a breaking (major) release?

  • Does this change require coordination with the SDK or other?

Consequences

This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.

Positive

Negative

Neutral

References

Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!

  • {reference link}