We seem to be converging over something that covers both flow and
architecture, but even including other mail hosts. It's pretty neat!

See team#41009

Now we have two models: one of email delivery flow, the other of the
redundancy architecture.

Turns out the latter might be clear enough on its own; the main
difference is it omits other mail host snowflakes like lists and the
other mail hosts (gitlab, rt, etc).

See team#41009

This is better, but still hard to read, I'm starting to think I just
need to split this in two diagrams: one to display redundancy and
location, the other for message flow.

This really tells me our naming convention sucks and we should have
picked example0 instead of example-01... But anyway.

This is clunky and overcrowded, but a necessary step to realize we
just can't draw all the lines.

this clarifies the diagram a little bit and starts working on the
clustering design.

This struck me while doing star training with @lelutin: we *do* run
the NRPE checks by hand quite often, and especially
dsa-check-packages. We need to port this to something else eventually.

See: team#40755

This is part of a quote and the square brackets indicate a
reinterpretation of words so it's not meant to be a link to something.

Those are just typos or missing words and shouldn't affect any of the
meaning of the sentences that get changed.

This makes it more immediately visible to users reading the proposal
by email or just browsing the website. Things like "affected users",
"approval" and "deadline" are particularly things that rarely require
a whole paragraph to describe.

This also makes the contents greppable, which is particularly relevant
for the Status field, which could now be used for automatic
generation.

That front matter is not currently very well displayed by GitLab
wikis, but it's relatively readable.

I have *tried* to move the "Summary" in there as well, but the
formatting gets ugly quickly, as we need to use line continuation
hacks. Besides, it looks better in the wiki that way.

I have tried to do this automatically macros, but alas the format was
too irregular so I had to actually do this manually, which means I
also tweaked other things as I went along.

Hopefully the format will make future work like this much easier.

It seems to me those warrant better view and could be part of the YAML
front-matter, which GitLab doesn't support so we're making with what
we have...

While working on the mail proposal (TPA-RFC-45, team#41009), I
realized some servers still relay mail through eugeni even though they
shouldn't, and the Prometheus servers clearly are one of those.

@geko pointed out that they (network-health) currently use a mostly
email-based workflow and that the proposal changes this a little too
radically. So open the door to sending warning notifications by email
as well, as a team-based approach. This seems reasonable: policy is
highly team-specific and there's no reason why we should forcibly
impose this policy, however reasonable it seems to me.

The Alertmanager router seems flexible enough to allow for this: it
will simply need a team-specific route that sends all notifications by
email, and we already *have* team-specific routes, so that doesn't
seem to be a big deal.

The proposal therefore restrict the hard "no warning email"
requirement to TPA and lets other teams shoot themselves in the foot
with that firehose.

Thinking about next steps here, I realized I'm going to run out of
time before the holidays yet i would still very much like to have some
alerting before I go, if only that dashboard, to handle issues like
team#41597 where i had no view on the outage at all.

The new timeline makes it possible to do some TPA-internal things
without having to affecting service admins or other services.

Mostly cosmetic and retrofitting the template.