Ownership risk analysis

[OmerGronich]

Fallow already surfaces structural risk well: complexity, hotspots, duplication, boundaries, dead code. It also already has ownership-adjacent concepts like CODEOWNERS grouping, but I could not find ownership analysis called out in the roadmap. (GitHub Docs / Gitlab Docs)

I think there is a strong opportunity here: add an ownership risk layer on top of the existing health model.

The interesting part is not ownership alone. It is composite risk, for example:

• high complexity + high churn + weak ownership
• hotspot files with no clear owner
• mismatch between CODEOWNERS and actual contributors/reviewers
• low bus factor in already risky areas

That feels much more actionable than a raw ownership number.

One important boundary: I am not suggesting that Fallow itself should ingest GitHub metrics, Jira metrics, incident metrics, or delivery metrics.

Instead, I see the split like this:

Fallow computes

• code / structural risk
• ownership risk from CODEOWNERS and Git
• composite risk from those internal signals

External systems provide

• bug counts
• bug resolution velocity
• PR review / merge latency
• lead time
• change failure rate
• incident metrics

Then Fallow’s output can be correlated with those external outcome metrics in dashboards or reporting pipelines.

That is where this gets really compelling. Research supports the idea that ownership and review expertise matter for software quality, bus factor captures knowledge concentration risk, and frameworks like DORA and SPACE support combining multiple dimensions instead of relying on one metric. (sailresearch.github.io)

Potential outputs:

• unowned hotspots
• ownership drift
• owner mismatch
• bus factor by package/team
• composite risk ranking over time

Curious whether this should live as:

1. a separate ownership analysis
2. an extension of health/hotspots
3. a broader composite risk engine

[BartWaardenburg]

Love it @OmerGronich I will look into this! Thanks for bringing this up!

[BartWaardenburg]

Shipped in v2.38.0 — thanks for the thoughtful issue, @OmerGronich! 🎉

https://github.com/fallow-rs/fallow/releases/tag/v2.38.0

fallow health --hotspots --ownership now surfaces per-file ownership signals from git author history and CODEOWNERS:

• bus_factor — Avelino truck factor: minimum contributors covering ≥50% of recency-weighted commits
• top_contributor / recent_contributors with stale-days, commits, and share
• suggested_reviewers — first-class JSON field filtered to contributors active in the last 90 days (paste-ready for AI agents doing PR review routing)
• declared_owner from CODEOWNERS + tristate unowned (true/false/null)
• drift with human-readable drift_reason (fires only when the original author has 0 recent share and the file is >30 days old)

Human output leads with a project-level summary (9/10 hotspots depend on a single recent contributor · top authors: @alice (6), @bob (4)) so the organizational pattern is visible before the per-file rows. JSON adds three new action types (low-bus-factor, unowned-hotspot with a synthesized CODEOWNERS pattern, ownership-drift) for AI agents to act on.

Privacy is handled via --ownership-emails={raw|handle|hash} — default is handle (local-part only with GitHub noreply unwrap) so author identities don't leak raw into CI artifacts.

Try it:

npx fallow health --hotspots --ownership

Two follow-ups are on the roadmap for future releases:

• Rename-mid-window disclosure — when a hotspot file was recently renamed, git log without --follow undercounts history; surface this as a footer hint
• fallow ownership suggest-codeowners — one-shot command that emits a reviewable CODEOWNERS diff from all unowned-hotspot action sites

Closing this discussion as shipped. Let me know how it works on your project!