Adding my notes on what (I think) we're trying to achieve, and the specific parts of the process that we'll want to define.

Overall aims:

1. having a more processized way of:
   • engaging maintainers, getting status and understanding workarounds
   • managing communication with users and mitigating the impact on them
2. following up on incidents to:
   • improve future handling / prevention if possible
   • communicate back to users what happened and what we did, so that we:
     • “default to open communication”
     • build user confidence

Areas to develop:

• what constitutes an incident?
  • broadly, it's “non-trivial breakage to a non-trivial number of users”
  • do we actually need to formalise any further, or do we “know it when we see it”?
• who does what during (and after) the incident?
  • actions
    • how do we triage and assess severity?
  • communication during the issue
    • with maintainers (using whatever channel is most effective to reach them)
    • to users - broadly similar to the current “common issues” process (i.e. explain on Discourse what happened, what's being done to remedy, how can users work around the issue?)
  • communication after the issue
    • with maintainers to discuss future practice
    • with users - “the issue is now closed, but here's what happened and why” in a more polished form than we were able to do during the incident
  • how do we track everything - basically a Discourse topic along the lines of the current “common issues”? Do we use the same topic for both the “during” and the “after” stages?
  • what are meaningful metrics that would help us continuously improve?

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/tickets/issues/854

Please continue any further discussion there.