Investigation: define & validate release-process KPIs

[yulianedyalkova]

Motivation

We don't currently have a way to tell whether the release process is getting faster or slower over time. We have data gathered here for previous releases but that has been done manually. Before building any dashboard, we need to know which of these numbers we can already compute from what we have, and which require us to change how we work first.

Candidate KPIs

1. Lead time for release: open -> merge, compared to planned date
2. Bug count per release
3. Mean time to green: first /run releases-test-suites -> first fully-passing run
4. Failure rate by suite: which suite (capa/china, capvcd/upgrade-major, etc.) fails most often, across releases
5. Retrigger rate: how many times we reran tests on a single release PR
6. External-block time %: of total release duration, how much was waiting on something outside our control (Flatcar, another team's controller fix) vs. internal test/review time
7. Blocker resolution time: for roadmap issues tied to a release (e.g. the 15 tracked under CAPI: Release v35.0.0 #4219), median time from flagged to closed

Questions to answer

For each KPI above:

• Can we extract it today from existing GitHub/PR/issue data?
• Does it need a process/labeling change first?