When presenting the three different templates to TPA, I described them
as having an increasing order of complexity, and actually said
something like "you can guess I picked the most complicated one",
which is counter to the spirit of the ADR adoption.

We want to simplify things.

So let's simplify: switch to the Nygard template, more or less, but
keep the "more information" section where we can cram more things,
alongside a "metadata" section that should work even without proper
frontmatter support, which we're actually lacking in the GitLab wiki,
but also in mdbook.

service/documentation.md

@@ -311,38 +311,21 @@ solve, or something that needs funding or some sort of
 justification. So the way to approach that problem will vary, but an
 exhaustive procedure might look something like this:
 
- 1. **describe the problem**; brainstorm on the problem space: what do
-    you actually want to fix?  that's the "Context and Problem
-    Statement" section of the template
-
- 2. **describe drivers**; those are the constraints on the solutions,
-    the concerns you have to fix, external forces you have to
-    consider, those are called "requirements" elsewhere. this is where
-    you might consider Personas or affected users more explicitly, but
-    don't detail those in the proposal. instead, define those in the
-    service documentation or out of the proposal, to keep the proposal
-    short.
-
- 3. **propose an outcome**: at this point, you might not even have
+ 1. **describe the context**; brainstorm on the problem space: what do
+    you actually want to fix? this is where you describe requirements,
+    but don't go into details, keep those for the "More information"
+    section
+
+ 2. **propose an decision**: at this point, you might not even have
     *made* the decision, this could merely be the proposal. still,
     make up your mind here and try one out. the decision-maker will
     either confirm it or overrule, but at least try to propose one.
-    
-    there are various subsections here:
-    
-    - **consequences**: this is optional. use this to document
-      possible positive/negative impacts of the proposals that people
-      should be aware of
-
-    - **confirmation**: this would be an "acceptance test" in software
-      development. how will you make sure this is correctly
-      implemented?
 
- 4. **evaluate pros and cons**: this section is entirely optional, and
-    should be detailed only for complex problems where many solutions
-    were evaluated.
+ 3. **detail consequences**: use this to document possible
+    positive/negative impacts of the proposals that people should be
+    aware of
 
- 5. **more information**: this section holds essentially anything else
+ 4. **more information**: this section holds essentially anything else
     that doesn't fit in the rest of the proposal. if this is a project
     longer than a couple of days work, try to evaluate costs. for
     that, break down the tasks in digestible chunks following the
@@ -350,14 +333,14 @@ exhaustive procedure might look something like this:
     include a timeline for complex proposals, which can be reused in
     communicating with "informed" parties
 
- 6. **summarize and edit**: at this point, you have a pretty complete
+ 5. **summarize and edit**: at this point, you have a pretty complete
     document. think about who will read this, and take time to review
     your work before sending. think about how this will look in an
     email, possible format things so that links are not inline and
     make sure you have a good title that summarizes everything in a
     single line
 
- 7. **send document for approval**: this will vary wildly depending on
+ 6. **send document for approval**: this will vary wildly depending on
     the affected users, but now you should send your document and hope
     for the best. make it clear it's a proposal and that you welcome
     changes, ideas, or dissent. give plenty of time for discussion
@@ -368,14 +351,14 @@ exhaustive procedure might look something like this:
     ("Proposed" status) and mark a date in your calendar for when you
     should mark it as accepted or rejected.
 
- 8. **reject or accept**! this is it! either people liked it or not,
+ 7. **reject or accept**! this is it! either people liked it or not,
     but now you need to either mark the proposal as rejected (and
     likely start thinking about another plan to fix your problem) or
     as "standard" and start doing the actual work, which might require
     creating GitLab issues or, for more complex projects, one or
     multiple milestones and a billion projects.
 
- 9. **communicate**! the new ADR process is *not* designed to be sent
+ 8. **communicate**! the new ADR process is *not* designed to be sent
     as is to affected parties. Make a *separate* announcement,
     typically following the [Five Ws](https://en.wikipedia.org/wiki/Five_Ws) method (Who? What? When?
     Where? Why?) to inform affected parties