Your CODEOWNERS file is wrong. It was accurate when someone wrote it 8 months ago. Since then, Sarah moved teams, Mike started working on a different service, and the new hire has been the primary contributor to the billing module for the last 3 months — but CODEOWNERS still lists the original author who left the company.
The Problem with Static Ownership
CODEOWNERS files, team wikis, and Slack-based "who owns this?" questions all share the same flaw: they're point-in-time snapshots that decay immediately.
Code ownership is dynamic. It shifts as people change teams, take on new projects, go on leave, or quietly become the expert in an area nobody formally assigned them.
Ownership from Git History
Git knows who actually owns code:
- Authorship: Who wrote the code in the last 6 months (not who wrote it originally)
- Review frequency: Who reviews PRs in this area most often
- Change velocity: Who is actively modifying this code vs. who touched it once a year ago
- Breadth vs. depth: Who works across the whole feature vs. who specializes in one file
This data is already in your repository. It just needs to be extracted and made queryable.
The Metrics That Matter
Bus Factor by Feature
How many people have committed to this feature in the last quarter? If the answer is 1, you have a knowledge concentration risk.
Knowledge Distribution Score
For each feature: what percentage of commits come from the top contributor? 90% from one person = high risk. 40% from each of two people = healthy distribution.
Review Coverage
Are PRs in this area reviewed by someone other than the author? Self-merged PRs in critical code paths are a red flag.
Ownership Decay
Is the recognized owner still actively contributing? An "owner" who hasn't committed in 3 months is an owner in name only.
Making Ownership Actionable
Knowledge of ownership is only useful if it drives behavior:
- When assigning tickets, check who actually knows the code — not who CODEOWNERS says
- When someone is about to leave, identify their knowledge-concentrated areas and plan transfers
- When planning a complex feature, check whether the affected areas have sufficient reviewer coverage
- When doing post-incident reviews, verify whether the change was reviewed by someone with genuine expertise in that area
This is what Glue's team insights provide: real-time code ownership derived from actual contribution patterns, not from a file someone updated last year.
Originally published on glue.tools. Glue is the pre-code intelligence platform — paste a ticket, get a battle plan.
Top comments (0)