Technical Story: adr#2
ADRs have a status. Should this be tracked? And if it should, how should we track it?
- Use badge
- Use text line
- Use separate heading
- Use table
- Do not add status
Chosen option: "Use text line", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | ... | comes out best (see below)].
- Good, because plain markdown
- Good, because looks good
- Bad, because hard to read in markdown source
- Bad, because relies on the online service https://shields.io or local badges have to be generated
- Bad, because at local usages, many badges have to be generated (superseeded-by-ADR-0006, for each ADR number)
- Bad, because not easy to write
Example: Status: Accepted
- Good, because plain markdown
- Good, because easy to read
- Good, because easy to write
- Good, because looks OK in both markdown-source (MD) and in rendered versions (HTML, PDF)
- Good, because no dependencies on external tools
- Good, because single line indicates the current state
- Bad, because "Status" line needs to be maintained
- Bad, because uses space at the beginning. When users read MADR, they should directly dive into the context and problem and not into the status
Example: 
- Good, because plain markdown
- Good, because easy to write
- Bad, because it uses much space: At least three lines: heading, status, separating empty line
Example: 
- Good, because history can be included
- Good, because multiple entries can be made
- Good, because already implemented in adr-tools fork
- Bad, because not covered by the CommonMark specification 0.28 (2017-08-01)
- Bad, because hard to read
- Bad, because outdated entries cannot be easily identified
- Bad, because needs more markdown training
- Good, because MADR is kept lean
- Bad, because users demand state field
- Bad, because not in line with other ADR templates