Repo Intelligence

A metric that does not name a cause is decoration. Every number comes with the PRs, jobs, or files behind it.

DORA four keys

Metric	Computation from repository data
Deployment frequency	Releases, or merges to the branch the repo actually deploys from
Lead time for changes	First commit on the branch → merge, per PR
Change failure rate	Merges followed within the failure window by a revert, hotfix branch, or incident-labeled issue referencing them
Time to restore	Incident issue opened → the PR closing it merged

Report p50 and p90, never means. A mean lead time is dominated by a few PRs that sat for a month, and it hides everyone else's experience. p90 is what the team actually feels.

Decompose lead time

"Lead time is up" is not actionable. Split it so the regression has an address:

first commit → PR opened
PR opened    → first review      ← usually the regression
first review → approved
approved     → merged

Then attribute the moving stage. Time-to-first-review regressions are almost always one of: reviewers unassigned, one reviewer holding a queue while away, PRs got bigger, or a team boundary changed. Check each before naming a cause.

Change failure attribution

A rate alone is not usable. List the failing changes and what they share:

Change failure rate: 14% (7 of 51)
  5 of 7 touched src/billing/**       ← concentrated
  6 of 7 merged with exactly one approval
  4 of 7 were > 800 lines

Concentrated failure is a fixable problem. Diffuse failure is a process problem. Say which you are looking at.

Hotspots

risk = normalized_churn × normalized_defect_density × complexity_factor

Churn alone is not risk — a config file changes constantly and breaks nothing. Exclude generated files, lockfiles, and vendored paths, or they drown the signal.

Diagnose the mechanism, do not just rank: god file · central registry · missing abstraction · implicit coupling · under-tested · ownership drift.

Ownership

Drift — CODEOWNERS names one person, recent commits are someone else's. Predicts slow reviews.

Bus factor — authors holding ≥ 20% of a module's recent commits.

The pairing that matters most: a file that is both a hotspot and bus-factor-1. Fragile code only one person understands is the highest-risk object in a repository. Always surface that combination explicitly.

CODEOWNERS is last-match-wins — the opposite of .gitignore. A broad * placed after a specific rule silently overrides it. Check order before concluding a path is covered.

Flake cost

Report flake cost in wasted CI minutes, not just a percentage. Minutes get flakes fixed; percentages get them tolerated.

Honesty about data quality

State limits explicitly. No release tags → deployment frequency is a proxy. Unlabeled incidents → time-to-restore is unmeasurable; say so rather than computing from a bad proxy. Under ~50 commits in a window, a hotspot ranking is noise — widen the window instead of reporting a confident order.

A confidently wrong metric is worse than a missing one, because someone will plan with it.

repo-intelligence