OTA-761 ported our Bugzilla workflow to Jira without structural changes. But the label-based workfllow isn't very familiar to many developers, and it's easy to land a fix and forget about the parallel work of mitigating an issue for the existing fleet (who maybe cannot update to pick up the fix yet) or brainstorming for ways to avoid similar regressions going forward.

This ticket is about spiking for alternative approaches which might be more understandable and easier to manage. For example, OCPBUGS could allow for sub-tasks tracking "disccuss update recommendation changes like declaring conditional update risks" or "analyze root casuses and create tickets for follow-up improvements". Or we could decide to spin out tickets in the relevant component project, instead of using sub-tasks under OCP. Or we could create new projects just for RCAs and conditional update risks. Or whatever. Lots of options.

Definition of done:

• Consensus or executive decision reached on target workflows for discussing update-risk mitigations and root cause analysis for OCPBUGS.
• Initial set of tickets created tracking the work that would need to be done to implement those target workflows.

Mutable process docs

Collecting these so they don't get lost in the comments, and we have a central place to evolve:

1. Someone puts an UpgradeBlocker label on an OCPBUGS-# ticket.
2. We create a Spike in the relevant component's Jira project (e.g. MCO-#). Let's use TEAM-# as a placeholder.
   1. Subject is: Impact ${BUG_SUBJECT}
   2. Assignee is the bug assignee.
   3. Body is our request template, but with subsitutions (if/when we formally adopt this process, we can update the enhancement template) like:
      1. "OCPBUGS-#" instead of "this bug".
      2. Use "When responding, please move this ticket to Code Review" for the "When responding" sentence (Jira native ).
   4. Priority is Critical, because it's hard to assess customer risk in the absence of an impact statement. If new information flows in that suggests further impact-statement work should be lower-priority for that bug, folks can reduce the priority later and explain their motivation.
   5. TEAM-# blocks OCPBUGS-#, because we should be able to get an initial draft at impact without waiting for the bug fix to merge, be verified, or ship.
   6. Label TEAM-# with UpgradeBlocker for tracking.
   7. Label OCPBUGS-# with ImpactStatementRequested for

While we're trialing this workflow, also link TEAM-# with this OTA-787 ticket, so it's easy for folks to poke around and see how the process is going.