Use the ?? (MADR) technique to capture decisions
status: {proposed | rejected | accepted | deprecated | … | superseded by ADR-0005}
date: {YYYY-MM-DD when the decision was last updated}
deciders: {list everyone involved in the decision}
consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication}
informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication}
Use the GitHub ADR and MADR for architecture decisions
Context and Problem Statement
The Architecture Working Group must capture decisions.
We need a simple and agreeable way to capture and track these decisions.
Decision to make:
- what template
- where to keep them - github or wiki
- maybe in the future we'll have a documentation repo to keep them in
- governance
- status checking
- approvals
Decision Drivers
- simple
- mature
- agreed upon
- works for opensource
Considered Options
- github adr / madr
- ad hoc
- {title of option 3}
- …
Decision Outcome
Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
Consequences
- Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
- Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
- …
Validation
{describe how the implementation of/compliance with the ADR is validated. E.g., by a review or an ArchUnit test}
Pros and Cons of the Options
GitHub ADR / MADR
simple and mature way to capture architecture decisions
- Good, because it is widely used
- Good, because works in code and in confluence
- Bad, because {argument d}
- …
Ad-Hoc
We come up with our own way to capture
- Bad, because only used for openIDL