-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
75 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,75 @@ | ||
| # ADR {ADR-NUMBER}: {TITLE} | ||
|
|
||
| ## Changelog | ||
|
|
||
| - {date}: {changelog} | ||
|
|
||
| ## 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. | ||
|
|
||
| {Proposed|Accepted|Implemented|Deprecated|Superseded} | ||
|
|
||
| ## 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. | ||
| ## 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, and what data structures will be changed? | ||
| > | ||
| > - What new APIs will be needed, and 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 others? | ||
| ## Alternative Approaches | ||
|
|
||
| > This section contains information about alternative options that are considered before making a decision. It should contain an explanation of why the alternative approach(es) were not chosen. | ||
| ## 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} |