Skip to content

Commit 7566f51

Browse files
authored
docs(ADR): add architecture decision template (#1630)
Signed-off-by: Michael Beemer <[email protected]>
1 parent 81c66eb commit 7566f51

File tree

2 files changed

+99
-0
lines changed

2 files changed

+99
-0
lines changed

.markdownlint-cli2.yaml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@ config:
1313
max-one-sentence-per-line: true
1414
code-block-style: false # not compatible with mkdocs "details" panes
1515
no-alt-text: false
16+
descriptive-link-text: false
1617
MD007:
1718
indent: 4
1819

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
---
2+
# Valid statuses: draft | proposed | rejected | accepted | superseded
3+
status: draft
4+
author: Your Name
5+
created: YYYY-MM-DD
6+
updated: YYYY-MM-DD
7+
---
8+
9+
# Title
10+
11+
<!--
12+
This section should be one or two paragraphs that just explains what the goal of this decision is going to be, but without diving too deeply into the "why", "why now", "how", etc.
13+
Ensure anyone opening the document will form a clear understanding of the intent from reading this paragraph(s).
14+
-->
15+
16+
## Background
17+
18+
<!--
19+
The next section is the "Background" section. This section should be at least two paragraphs and can take up to a whole page in some cases.
20+
The guiding goal of the background section is: as a newcomer to this project (new employee, team transfer), can I read the background section and follow any links to get the full context of why this change is necessary?
21+
22+
If you can't show a random engineer the background section and have them acquire nearly full context on the necessity for the RFC, then the background section is not full enough. To help achieve this, link to prior RFCs, discussions, and more here as necessary to provide context so you don't have to simply repeat yourself.
23+
-->
24+
25+
## Requirements
26+
27+
<!--
28+
This section outlines the requirements that the proposal must meet.
29+
These requirements should be derived from the background section and should be clear, concise, and actionable.
30+
This is where you can specify the goals and constraints that the proposal must satisfy.
31+
This could include performance metrics, security considerations, user experience goals, and any other relevant criteria.
32+
-->
33+
* {Requirement 1}
34+
* {Requirement 2}
35+
* {Requirement 3}
36+
*<!-- numbers of requirements can vary -->
37+
38+
## Considered Options
39+
40+
<!--
41+
This section lists all the options that were considered for addressing the need outlined in the background section.
42+
Each option should be clearly defined with a descriptive title.
43+
This provides a comprehensive overview of the solution space that was explored before making a decision.
44+
The options will be evaluated in the proposal section, where the chosen approach is justified.
45+
-->
46+
47+
* {title of option 1}
48+
* {title of option 2}
49+
* {title of option 3}
50+
*<!-- numbers of options can vary -->
51+
52+
## Proposal
53+
54+
<!--
55+
The next required section is "Proposal" or "Goal".
56+
Given the background above, this section proposes a solution.
57+
This should be an overview of the "how" for the solution.
58+
Include content like diagrams, prototypes, and high-level requirements.
59+
-->
60+
61+
<!-- This is an optional element. Feel free to remove. -->
62+
### API changes
63+
64+
<!--
65+
This section should describe any API changes that are part of the proposal.
66+
This includes any new endpoints, changes to existing endpoints, or modifications to the data model.
67+
It should provide enough detail for developers to understand how the API will evolve and what impact it will have on existing clients.
68+
-->
69+
70+
<!-- This is an optional element. Feel free to remove. -->
71+
### Consequences
72+
73+
* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
74+
* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
75+
*<!-- numbers of consequences can vary -->
76+
77+
### Timeline
78+
79+
<!--
80+
This section outlines a high level timeline for implementing the proposal.
81+
It should include key milestones, deadlines, and any dependencies that need to be addressed.
82+
This helps to set expectations for the size of the change and the expected timeline for completion.
83+
-->
84+
85+
<!-- This is an optional element. Feel free to remove. -->
86+
### Open questions
87+
88+
* {Question 1}
89+
*<!-- numbers of question can vary -->
90+
91+
<!-- This is an optional element. Feel free to remove. -->
92+
## More Information
93+
94+
<!--
95+
This section provides additional context, evidence, or documentation to support the decision.
96+
Use this space to provide any supplementary information that would be helpful for future readers
97+
to fully understand the decision and its implications.
98+
-->

0 commit comments

Comments
 (0)