feat(docs): add a `decisions` folder with ADR
An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle
This commit is contained in:
parent
fae1e99526
commit
7dac323258
|
@ -0,0 +1,22 @@
|
|||
# Decision Log
|
||||
|
||||
We capture important decisions with [architectural decision records](https://adr.github.io/).
|
||||
|
||||
These records provide context, trade-offs, and reasoning taken at our community & technical cross-roads. Our goal is to preserve the understanding of the project growth, and capture enough insight to effectively revisit previous decisions.
|
||||
|
||||
Get started created a new decision record with the template:
|
||||
|
||||
```sh
|
||||
cp template.md NN-title-with-dashes.md
|
||||
```
|
||||
|
||||
For more rational behind this approach, see [Michael Nygard's article](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
|
||||
|
||||
We've inherited MADR [ADR template](https://adr.github.io/madr/), which is a bit more verbose than Nygard's original template. We may simplify it in the future.
|
||||
|
||||
## Evolving Decisions
|
||||
|
||||
Many decisions build on each other, a driver of iterative change and messiness
|
||||
in software. By laying out the "story arc" of a particular system within the
|
||||
application, we hope future maintainers will be able to identify how to rewind
|
||||
decisions when refactoring the application becomes necessary.
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
# status and date are the only required elements. Feel free to remove the rest.
|
||||
status: {[proposed | rejected | approved | deprecated | … | superceded by [2021-01-01 Example](2021-01-01-example.md)]}
|
||||
date: {YYYY-MM-DD when the decision was last updated}
|
||||
based-on: {[Short Title](2021-05-15-short-title.md)}
|
||||
story: {description or link to contextual issue}
|
||||
---
|
||||
|
||||
# {short title of solved problem and solution}
|
||||
|
||||
## Context & Problem Statement
|
||||
|
||||
2-3 sentences explaining the problem, and what are the forces influencing the decision.
|
||||
<!-- The language in this section is value-neutral. It is simply describing facts. -->
|
||||
|
||||
## Priorities & Constraints <!-- optional -->
|
||||
|
||||
* {list of concerns}
|
||||
* {that are influencing the decision}
|
||||
|
||||
## Considered Options
|
||||
|
||||
* Option 1: Thing
|
||||
* Option 2: Another
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen option [Option 1: Thing]
|
||||
|
||||
[justification]
|
||||
|
||||
### Expected Consequences <!-- optional -->
|
||||
|
||||
* List of unrelated outcomes this decision creates.
|
||||
<!-- Positive, negative, and/or neutral consequences, as lll of them affect the team and project in the future. -->
|
||||
|
||||
## More Information <!-- optional -->
|
||||
|
||||
<!-- * Resources reviewed as part of making this decision -->
|
||||
<!-- * Links to any supporting documents or resources -->
|
||||
<!-- * Related PRs -->
|
||||
<!-- * Related User Journeys -->
|
Loading…
Reference in New Issue