From f1a7e3882d60d3425d397a099d25dac9b241cda3 Mon Sep 17 00:00:00 2001
From: Nadja Reitzenstein <me@dequbed.space>
Date: Wed, 5 Jan 2022 16:43:58 +0100
Subject: [PATCH] use MADR

---
 .gitignore                                    |  5 ++
 ...markdown-architectural-decision-records.md | 22 ++++++
 docs/decisions/index.md                       | 13 ++++
 docs/decisions/template.md                    | 72 +++++++++++++++++++
 4 files changed, 112 insertions(+)
 create mode 100644 docs/decisions/0000-use-markdown-architectural-decision-records.md
 create mode 100644 docs/decisions/index.md
 create mode 100644 docs/decisions/template.md

diff --git a/.gitignore b/.gitignore
index 5588931..7124615 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,7 @@
 tags
 *.cs
+
+# MADR
+/node_modules/
+/package-lock.json
+/package.json
diff --git a/docs/decisions/0000-use-markdown-architectural-decision-records.md b/docs/decisions/0000-use-markdown-architectural-decision-records.md
new file mode 100644
index 0000000..428218e
--- /dev/null
+++ b/docs/decisions/0000-use-markdown-architectural-decision-records.md
@@ -0,0 +1,22 @@
+# Use Markdown Architectural Decision Records (MADR)
+
+## Context and Problem Statement
+
+We want to record architectural decisions made in this project.
+Which format and structure should these records follow?
+
+## Considered Options
+
+* [Markdown Architectural Decisions Record (MADR)](https://adr.github.io/madr/)
+* Gitlab issues
+* Formless – No conventions for file format and structure
+
+## Decision Outcome
+
+Chosen option: "Markdown Architectural Decisions Record (MADR)", because
+
+* Markdown is an easy to write textual format requiring no tooling to be easily human readable
+* Markdown is widely supported and is auto-rendered by all git hosting platforms considered
+* Can be easily stored alongside the actual code and documentation since plain-text files play well with git
+* Is not bound to a single hosting platform like Gitlab issues would be
+* Gives a very sensible default template and format for us to use
diff --git a/docs/decisions/index.md b/docs/decisions/index.md
new file mode 100644
index 0000000..37ef8b8
--- /dev/null
+++ b/docs/decisions/index.md
@@ -0,0 +1,13 @@
+# Architectural Decision Log
+
+This log lists the architectural decisions for [project name].
+
+<!-- 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 (MADR)
+
+<!-- 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/>.
diff --git a/docs/decisions/template.md b/docs/decisions/template.md
new file mode 100644
index 0000000..25696bb
--- /dev/null
+++ b/docs/decisions/template.md
@@ -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 -->