Deciders(s):
Date (YYYY-MM-DD):
Obsoletes ADRs:
Modified By ADRs:
Relevant Issues:
Context goes here.
Describe the forces at play, including technological, political, social, and project local. These forces are likely in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts.
Why this is a valuable problem to solve? What background information is needed to show how this design addresses the problem?
Which users are affected by the problem? Why is it a problem? What data supports this? What related work exists?
How will users (or other contributors) benefit from this work? What would be the headline in the release notes or blog post?
This is the meat of the document, where you explain the decision. If you have multiple alternatives, be sure to use sub-sections for better separation of the idea, and list pros/cons to each approach. If there are alternatives that you have eliminated, you should also list those here, and explain why you believe your chosen approach is superior.
Make sure you’ve thought through and addressed the following sections. If a section is not relevant to your specific proposal, please explain why, e.g. your ADR addresses a convention or process, not an API.
- Make sure to discuss the relative merits of alternatives to your proposal.
Describe the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future.
This section is optional. Elaborate on details if they’re important to understanding the design, but would make it hard to read the proposal section above.