github.com/KYVENetwork/cometbft/v38@v38.0.3/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/KYVENetwork/cometbft/v38/issues/123)
    19  >     [Milestone](https://github.com/KYVENetwork/cometbft/v38/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}