From feed6f465185fe9174617b06eec87be4a54bc131 Mon Sep 17 00:00:00 2001 From: Mark Wallace <127216156+markwallace-microsoft@users.noreply.github.com> Date: Tue, 24 Jun 2025 16:57:17 +0100 Subject: [PATCH] Add decisions folder and ADR templates (#101) * Add decisions folder and ADR templates * Update docs/decisions/README.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/decisions/README.md | 24 ++++++++ docs/decisions/adr-short-template.md | 36 ++++++++++++ docs/decisions/adr-template.md | 87 ++++++++++++++++++++++++++++ 3 files changed, 147 insertions(+) create mode 100644 docs/decisions/README.md create mode 100644 docs/decisions/adr-short-template.md create mode 100644 docs/decisions/adr-template.md diff --git a/docs/decisions/README.md b/docs/decisions/README.md new file mode 100644 index 0000000000..55c48a7089 --- /dev/null +++ b/docs/decisions/README.md @@ -0,0 +1,24 @@ +# Architectural Decision Records (ADRs) + +An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architectural Decision Record (ADR) captures a single AD and its rationale. + +For more information [see](https://adr.github.io/) + +## How are we using ADRs to track technical decisions? + +1. Copy docs/decisions/adr-template.md to docs/decisions/NNNN-title-with-dashes.md, where NNNN indicates the next number in sequence. + 1. Check for existing PR's to make sure you use the correct sequence number. + 2. There is also a short form template docs/decisions/adr-short-template.md +2. Edit NNNN-title-with-dashes.md. + 1. Status must initially be `proposed` + 2. List of `deciders` must include the github ids of the people who will sign off on the decision. + 3. The relevant EM and architect must be listed as deciders or informed of all decisions. + 4. You should list the names or github ids of all partners who were consulted as part of the decision. + 5. Keep the list of `deciders` short. You can also list people who were `consulted` or `informed` about the decision. +3. For each option list the good, neutral and bad aspects of each considered alternative. + 1. Detailed investigations can be included in the `More Information` section inline or as links to external documents. +4. Share your PR with the deciders and other interested parties. + 1. Deciders must be listed as required reviewers. + 2. The status must be updated to `accepted` once a decision is agreed and the date must also be updated. + 3. Approval of the decision is captured using PR approval. +5. Decisions can be changed later and superseded by a new ADR. In this case it is useful to record any negative outcomes in the original ADR. diff --git a/docs/decisions/adr-short-template.md b/docs/decisions/adr-short-template.md new file mode 100644 index 0000000000..bd8b10491f --- /dev/null +++ b/docs/decisions/adr-short-template.md @@ -0,0 +1,36 @@ +--- +# These are optional elements. Feel free to remove any of them. +status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0001](0001-madr-architecture-decisions.md)} +contact: {person proposing the ADR} +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} +--- + +# {short title of solved problem and solution} + +## Context and Problem Statement + +{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. +You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.} + + + +## Decision Drivers + +- {decision driver 1, e.g., a force, facing concern, …} +- {decision driver 2, e.g., a force, facing concern, …} +- … + +## Considered Options + +- {title of option 1} +- {title of option 2} +- {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)}. diff --git a/docs/decisions/adr-template.md b/docs/decisions/adr-template.md new file mode 100644 index 0000000000..a96551338a --- /dev/null +++ b/docs/decisions/adr-template.md @@ -0,0 +1,87 @@ +--- +# These are optional elements. Feel free to remove any of them. +status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0001](0001-madr-architecture-decisions.md)} +contact: {person proposing the ADR} +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} +--- + +# {short title of solved problem and solution} + +## Context and Problem Statement + +{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. +You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.} + + + +## Decision Drivers + +- {decision driver 1, e.g., a force, facing concern, …} +- {decision driver 2, e.g., a force, facing concern, …} +- … + +## Considered Options + +- {title of option 1} +- {title of option 2} +- {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 + +### {title of option 1} + + + +{example | description | pointer to more information | …} + +- Good, because {argument a} +- Good, because {argument b} + +- Neutral, because {argument c} +- Bad, because {argument d} +- … + +### {title of other option} + +{example | description | pointer to more information | …} + +- Good, because {argument a} +- Good, because {argument b} +- Neutral, because {argument c} +- Bad, because {argument d} +- … + + + +## More Information + +{You might want to provide additional evidence/confidence for the decision outcome here and/or +document the team agreement on the decision and/or +define when this decision when and how the decision should be realized and if/when it should be re-visited and/or +how the decision is validated. +Links to other decisions and resources might appear here as well.}