diff --git a/1.1/404.html b/1.1/404.html new file mode 100644 index 0000000..7e6ed9d --- /dev/null +++ b/1.1/404.html @@ -0,0 +1,735 @@ + + + +
+ + + + + + + + + + + + + + + + + + +We want to record any decisions made in this project independent whether decisions concern the architecture ("architectural decision record"), the code, or other fields. +Which format and structure should these records follow?
+Chosen option: "MADR 2.1.2", because
+We prefer using MADR3
+ + + + + + + + + + + + + +ID | +Date | +Decision | +Status | +
---|---|---|---|
1 | +24-01-2024 | +Use Markdown Any Decision Records | +Superseded by ADR-0002 | +
2 | +24-01-2024 | +Changed my mind about MADR2 | +Accepted | +
Technical Story: [description | ticket/issue URL]
+[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.]
+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)].
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+We want to record any decisions made in this project independent whether decisions concern the architecture ("architectural decision record"), the code, or other fields. +Which format and structure should these records follow?
+Chosen option: "MADR 3.0.0", because
+For some reason we don't like MADR anymore.
+ + + + + + + + + + + + + + + + +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}
+{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.}
+ +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)}.
+ +{describe how the implementation of/compliance with the ADR is validated. E.g., by a review or an ArchUnit test}
+ +{example | description | pointer to more information | …}
+{example | description | pointer to 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 here appear as well.}
+ + + + + + + + + + + + + +ID | +Date | +Decision | +Status | +
---|---|---|---|
2 | +25-01-2024 | +Changed my mind about ADR format | +Accepted | +
1 | +24-01-2024 | +Use Markdown Any Decision Records | +Superseded by ADR-0002 | +
Date: 2024-01-20
+Superceded by 2. Supersedes 1
+Superceded by 3. Supersedes 1-b
+We need to record the architectural decisions made on this project.
+We will use Architecture Decision Records, as described by Michael Nygard.
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's adr-tools.
+ + + + + + + + + + + + + +Date: 2024-01-22
+Accepted
+Supercedes 1. Record architecture decisions
+The issue motivating this decision, and any context that influences or constrains the decision.
+The change that we're proposing or have agreed to implement.
+What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.
+ + + + + + + + + + + + + +Date: 2024-01-22
+Accepted
+Supercedes 1. Record architecture decisions
+The issue motivating this decision, and any context that influences or constrains the decision.
+The change that we're proposing or have agreed to implement.
+What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.
+ + + + + + + + + + + + + +ID | +Date | +Decision | +Status | +
---|---|---|---|
3 | +22-01-2024 | +3. Supercedes 1-b | +Supercedes 1. Record architecture decisions | +
2 | +22-01-2024 | +2. Supercedes 1 | +Supercedes 1. Record architecture decisions | +
1 | +20-01-2024 | +1. Record architecture decisions | +Superceded by 3. Supersedes 1-b | +