mirror of
https://github.com/tendermint/tendermint.git
synced 2026-01-08 22:23:11 +00:00
102 lines
3.2 KiB
Markdown
102 lines
3.2 KiB
Markdown
# 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/tendermint/tendermint/issues/123)
|
|
> [Milestone](https://github.com/tendermint/tendermint/milestones/123)
|
|
> [Project board](https://github.com/orgs/tendermint/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}
|