Ensuring accurate ClusterOperator status during upgrades: ClusterOperators should not report Degrade=True or Available=False during normal upgrades.
Operators transitioning to "progressing" state during version changes: Operators must show a "progressing" state when upgrading to new versions.
Preventing unnecessary "progressing" state re-entry: Operators should not re-enter the "progressing" state solely due to node lifecycle events like scaling or reboots.
Addressing slow upgrading ClusterOperators: Filing bugs for ClusterOperators that take too long to upgrade.

In Phase 2: This is continuous effort of Phase 1 (OTA-1644).

• Create OCPBugs that show up in CI as regression. We may reuse this query in Sippy to check (once a week?) if new regressions come up (before the TRT team pings us).
• Monitor the dashboard of OCPBugs (4h/week) and discuss with rh-ee-smodeel (weekly) if any of them requires OTA's attention. We could start with the ones updated recently, or closed back in time. We act on according to the status. E.g.,

• • Closed as NotABug or WontDo
  • Verified recently
  • Fixed in 4.18 or earlier.
  • etc.