FY22-Q4 Ops rapid action to support Verify Reliability efforts
Context
In FY22-Q3, the Verify stage had a focus on SaaS reliability and set out with an ambitious OKR to burn down
For FY22-Q4, we have OKRs in Verify to commit to 100% burndown of any remaining infradev issues and sharding-blockers given the phased rollout, and I have asked the EM/PMs in Verify to allow me to borrow people from their teams for the Engineering Allocation. Unfortunately it means nearly 80% of our backend team will be on an EA for another quarter, which further defers key initiatives for Verify.
Why?
I have spoken to a few folks about potential strategies to help with this effort within Ops, including a proposal I wrote about allocation of Verify priorities with a list of issues prioritized for Q4, and the headcount reset / borrow may not be most ideal at this time given some team's capacity.
@dcroft and I collaborated on a few ideas, and one of them was to look into a Rapid Action (in lieu of a multi-group swarm, that was absorbed into a Rapid Action) within the Ops section.
Why: Sharding-blockers?
I feel this could be effective for sharding-blockers in Q4 as they are now
- better known
- not necessarily CI domain specific (unlike infradev issues)
Exit Criteria
For Ops teams not in Verify, who have capacity to take on additional Verify sharding-blocker issues, here would be the exit criteria for this Rapid Action.
Complete the following issues:
Additional Notes:
- There may be other issues still TBD (currently workflowblocked) - potentially in %14.7, as this gets unblocked. The key issue to unblock a number of these is currently in dev: gitlab-org/gitlab#336432 (closed)
- There also may be additional issues being added to the Verify backlog of sharding-blockers.
/cc @nicolewilliams @michelletorres @crystalpoole @nicholasklick @sgoldstein @jreporter @kbychu