You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

83 lines
2.4 KiB

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