How to Find Bus-Factor Risk in a Repository

Bus-factor risk exists when a critical part of the codebase depends on knowledge held by too few people. Find it by measuring recent authorship and review concentration at the path level, then pair the signal with system criticality and a concrete knowledge-sharing action.

The goal is resilience, not ranking. A highly knowledgeable maintainer is an asset. The risk comes from a system that has not spread enough context around them.

Define a useful evidence window

Lifetime contribution totals hide the current team. Start with merged pull requests from a recent period that matches your delivery pace (often the last six to twelve months). Keep older history available for context, but weight recent work more heavily.

Remove obvious noise such as generated files, dependency lockfiles, bot-authored updates, and one-time mass formatting. Then group activity by directory or subsystem, not only by repository.

Measure three kinds of concentration

Authorship concentration

What share of recent changes to a path came from its top contributor? A dominant share is a signal, especially when the area is critical or frequently changed.

Review concentration

Who validates changes in that area? A path may have several authors but still depend on one reviewer who knows the operational or architectural constraints.

Recency gap

How long has it been since a second person changed or reviewed the area? Two names in lifetime history do not create redundancy if only one has current context.

Combine concentration with consequence

Not every silo deserves the same response. Prioritize paths that combine concentrated knowledge with one or more of these conditions:

• customer-facing or revenue-critical behavior
• authentication, permissions, billing, or data migrations
• high churn or frequent incidents
• strong coupling to several other files
• no clear test, runbook, or rollback path

Helix Pulse surfaces silo and expertise patterns from the same graph used by Ask Helix and Review. That makes the signal explorable: open the path, inspect the people and pull requests behind it, and decide whether the concentration is expected or urgent.

Turn a warning into a transfer plan

Do not respond with “write more documentation” as a blanket task. Match the intervention to the missing evidence:

1. Rotate reviews. Add a developing reviewer to the next few real changes.
2. Pair on a bounded change. Use active work to transfer operational context.
3. Capture the decision. Document why the subsystem has its non-obvious constraints.
4. Exercise recovery. Have someone else run the test, migration, release, or rollback path.
5. Recheck the graph. Confirm that authorship and review coverage broaden over time.

For a repository-wide view, first build an ownership map. For the human side of continuity, see how to preserve tribal knowledge.

Questions to ask in Helix

After indexing a repository in Helix, ask questions that lead to action:

• Which critical directories have only one recent author?
• Who could review the payments module besides its primary maintainer?
• Which high-churn files have concentrated ownership?
• What pull requests best explain how this subsystem is maintained?

A bus-factor report is only useful when the evidence can be inspected and the team can see whether the remediation is working. Measure continuity at the code path where knowledge is needed, not as a single score attached to a person or department.