- # ADR {ADR-NUMBER}: {TITLE}
-
- ## Changelog
-
- - {date}: {changelog}
-
- ## 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?
-
- ## Status
-
- > A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. Once the ADR has been implemented mark the ADR as "implemented". If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
-
- {Deprecated|Proposed|Accepted|Declined}
-
- ## 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}
|
