forked from theupdateframework/python-tuf
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs/adr: start to keep ADRs in MADR format
In order to make decisions about the code and the design explicit and easier to reference in future we want to record significant architectural decisions. This commit introduces docs/adr with a template Architectural Decision Record and index using the [MADR](https://adr.github.io/madr/) format. It also adds ADR 0000 to document the decisions to use MADR. Fixes theupdateframework#1141 Signed-off-by: Joshua Lock <jlock@vmware.com>
- Loading branch information
Showing
3 changed files
with
110 additions
and
0 deletions.
There are no files selected for viewing
25 changes: 25 additions & 0 deletions
25
docs/adr/0000-use-markdown-architectural-decision-records.md
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,25 @@ | ||
# Use Markdown Architectural Decision Records | ||
|
||
* Status: accepted | ||
* Date: 2020-10-20 | ||
|
||
Technical Story: https://github.com/theupdateframework/tuf/issues/1141 | ||
|
||
## Context and Problem Statement | ||
|
||
We want to record architectural decisions made in this project. | ||
Which format and structure should these records follow? | ||
|
||
## Considered Options | ||
|
||
* [MADR](https://adr.github.io/madr/) 2.1.2 – The Markdown Architectural Decision Records | ||
* Formless – No conventions for file format and structure | ||
|
||
## Decision Outcome | ||
|
||
Chosen option: "MADR 2.1.2", because | ||
|
||
* Implicit assumptions should be made explicit. | ||
Design documentation is important to enable people understanding the decisions | ||
later on. | ||
* The MADR structure is comprehensible and facilitates usage & maintenance. |
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,13 @@ | ||
# Architectural Decision Log | ||
|
||
This log lists the architectural decisions for tuf. | ||
|
||
<!-- adrlog -- Regenerate the content by using "adr-log -i". You can install it via "npm install -g adr-log" --> | ||
|
||
- [ADR-0000](0000-use-markdown-architectural-decision-records.md) - Use Markdown Architectural Decision Records | ||
|
||
<!-- adrlogstop --> | ||
|
||
For new ADRs, please use [template.md](template.md) as basis. | ||
More information on MADR is available at <https://adr.github.io/madr/>. | ||
General information about architectural decision records is available at <https://adr.github.io/>. |
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,72 @@ | ||
# [short title of solved problem and solution] | ||
|
||
* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional --> | ||
* Deciders: [list everyone involved in the decision] <!-- optional --> | ||
* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional --> | ||
|
||
Technical Story: [description | ticket/issue URL] <!-- optional --> | ||
|
||
## Context and Problem Statement | ||
|
||
[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.] | ||
|
||
## Decision Drivers <!-- optional --> | ||
|
||
* [driver 1, e.g., a force, facing concern, …] | ||
* [driver 2, e.g., a force, facing concern, …] | ||
* … <!-- numbers of drivers can vary --> | ||
|
||
## Considered Options | ||
|
||
* [option 1] | ||
* [option 2] | ||
* [option 3] | ||
* … <!-- numbers of options can vary --> | ||
|
||
## Decision Outcome | ||
|
||
Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. | ||
|
||
### Positive Consequences <!-- optional --> | ||
|
||
* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] | ||
* … | ||
|
||
### Negative Consequences <!-- optional --> | ||
|
||
* [e.g., compromising quality attribute, follow-up decisions required, …] | ||
* … | ||
|
||
## Pros and Cons of the Options <!-- optional --> | ||
|
||
### [option 1] | ||
|
||
[example | description | pointer to more information | …] <!-- optional --> | ||
|
||
* Good, because [argument a] | ||
* Good, because [argument b] | ||
* Bad, because [argument c] | ||
* … <!-- numbers of pros and cons can vary --> | ||
|
||
### [option 2] | ||
|
||
[example | description | pointer to more information | …] <!-- optional --> | ||
|
||
* Good, because [argument a] | ||
* Good, because [argument b] | ||
* Bad, because [argument c] | ||
* … <!-- numbers of pros and cons can vary --> | ||
|
||
### [option 3] | ||
|
||
[example | description | pointer to more information | …] <!-- optional --> | ||
|
||
* Good, because [argument a] | ||
* Good, because [argument b] | ||
* Bad, because [argument c] | ||
* … <!-- numbers of pros and cons can vary --> | ||
|
||
## Links <!-- optional --> | ||
|
||
* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) --> | ||
* … <!-- numbers of links can vary --> |