github.com/badrootd/nibiru-cometbft@v0.37.5-0.20240307173500-2a75559eee9b/docs/architecture/adr-template.md (about) 1 # ADR {ADR-NUMBER}: {TITLE} 2 3 ## Changelog 4 5 - {date}: {changelog} 6 7 ## Status 8 9 > An architecture decision is considered "proposed" when a PR containing the ADR 10 > is submitted. When merged, an ADR must have a status associated with it, which 11 > must be one of: "Accepted", "Rejected", "Deprecated" or "Superseded". 12 > 13 > An accepted ADR's implementation status must be tracked via a tracking issue, 14 > milestone or project board (only one of these is necessary). For example: 15 > 16 > Accepted 17 > 18 > [Tracking issue](https://github.com/cometbft/cometbft/issues/123) 19 > [Milestone](https://github.com/cometbft/cometbft/milestones/123) 20 > [Project board](https://github.com/orgs/cometbft/projects/123) 21 > 22 > Rejected ADRs are captured as a record of recommendations that we specifically 23 > do not (and possibly never) want to implement. The ADR itself must, for 24 > posterity, include reasoning as to why it was rejected. 25 > 26 > If an ADR is deprecated, simply write "Deprecated" in this section. If an ADR 27 > is superseded by one or more other ADRs, provide local a reference to those 28 > ADRs, e.g.: 29 > 30 > Superseded by [ADR 123](./adr-123.md) 31 32 Accepted | Rejected | Deprecated | Superseded by 33 34 ## Context 35 36 > This section contains all the context one needs to understand the current state, 37 > and why there is a problem. It should be as succinct as possible and introduce 38 > the high level idea behind the solution. 39 40 ## Alternative Approaches 41 42 > This section contains information around alternative options that are considered 43 > before making a decision. It should contain a explanation on why the alternative 44 > approach(es) were not chosen. 45 46 ## Decision 47 48 > This section records the decision that was made. 49 > It is best to record as much info as possible from the discussion that happened. 50 > This aids in not having to go back to the Pull Request to get the needed information. 51 52 ## Detailed Design 53 54 > This section does not need to be filled in at the start of the ADR, but must 55 > be completed prior to the merging of the implementation. 56 > 57 > Here are some common questions that get answered as part of the detailed design: 58 > 59 > - What are the user requirements? 60 > 61 > - What systems will be affected? 62 > 63 > - What new data structures are needed, what data structures will be changed? 64 > 65 > - What new APIs will be needed, what APIs will be changed? 66 > 67 > - What are the efficiency considerations (time/space)? 68 > 69 > - What are the expected access patterns (load/throughput)? 70 > 71 > - Are there any logging, monitoring or observability needs? 72 > 73 > - Are there any security considerations? 74 > 75 > - Are there any privacy considerations? 76 > 77 > - How will the changes be tested? 78 > 79 > - If the change is large, how will the changes be broken up for ease of review? 80 > 81 > - Will these changes require a breaking (major) release? 82 > 83 > - Does this change require coordination with the SDK or other? 84 85 ## Consequences 86 87 > This section describes the consequences, after applying the decision. All 88 > consequences should be summarized here, not just the "positive" ones. 89 90 ### Positive 91 92 ### Negative 93 94 ### Neutral 95 96 ## References 97 98 > Are there any relevant PR comments, issues that led up to this, or articles 99 > referenced for why we made the given design choice? If so link them here! 100 101 - {reference link}