github.com/number571/tendermint@v0.34.11-gost/docs/architecture/adr-template.md (about)

     1  # ADR {ADR-NUMBER}: {TITLE}
     2  
     3  ## Changelog
     4  
     5  - {date}: {changelog}
     6  
     7  ## Status
     8  
     9  > A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted"
    10  > once it is agreed upon. Once the ADR has been implemented mark the ADR as
    11  > "implemented". If a later ADR changes or reverses a decision, it may be marked
    12  > as "deprecated" or "superseded" with a reference to its replacement.
    13  
    14  {Deprecated|Declined|Accepted|Implemented}
    15  
    16  ## Context
    17  
    18  > This section contains all the context one needs to understand the current state,
    19  > and why there is a problem. It should be as succinct as possible and introduce
    20  > the high level idea behind the solution.
    21  
    22  ## Alternative Approaches
    23  
    24  > This section contains information around alternative options that are considered
    25  > before making a decision. It should contain a explanation on why the alternative
    26  > approach(es) were not chosen.
    27  
    28  ## Decision
    29  
    30  > This section records the decision that was made.
    31  > It is best to record as much info as possible from the discussion that happened.
    32  > This aids in not having to go back to the Pull Request to get the needed information.
    33  
    34  ## Detailed Design
    35  
    36  > This section does not need to be filled in at the start of the ADR, but must
    37  > be completed prior to the merging of the implementation.
    38  >
    39  > Here are some common questions that get answered as part of the detailed design:
    40  >
    41  > - What are the user requirements?
    42  >
    43  > - What systems will be affected?
    44  >
    45  > - What new data structures are needed, what data structures will be changed?
    46  >
    47  > - What new APIs will be needed, what APIs will be changed?
    48  >
    49  > - What are the efficiency considerations (time/space)?
    50  >
    51  > - What are the expected access patterns (load/throughput)?
    52  >
    53  > - Are there any logging, monitoring or observability needs?
    54  >
    55  > - Are there any security considerations?
    56  >
    57  > - Are there any privacy considerations?
    58  >
    59  > - How will the changes be tested?
    60  >
    61  > - If the change is large, how will the changes be broken up for ease of review?
    62  >
    63  > - Will these changes require a breaking (major) release?
    64  >
    65  > - Does this change require coordination with the SDK or other?
    66  
    67  ## Consequences
    68  
    69  > This section describes the consequences, after applying the decision. All
    70  > consequences should be summarized here, not just the "positive" ones.
    71  
    72  ### Positive
    73  
    74  ### Negative
    75  
    76  ### Neutral
    77  
    78  ## References
    79  
    80  > Are there any relevant PR comments, issues that led up to this, or articles
    81  > referenced for why we made the given design choice? If so link them here!
    82  
    83  - {reference link}