Should we use CODEOWNERS?
CODEOWNERS will probably create more problems than it solves. But, like all great questions, the answer is “it depends.”
I would classify the CODEOWNERS file itself (more about workflows later) as fairly lawful neutral. It’s meant to be a centralized place to give credit and ownership for chunks of the codebase. Having this paper trail can be helpful in onboarding, and even streamline the resolution of questions that come up during the course of development since you know who to ask.
Where CODEOWNERS dips into the unproductive is when the owners listed for each feature or file can block the PR. GitHub and GitLab both allow branch protection rules that require review from CODEOWNERS before a PR can be merged. Most teams that start using CODEOWNERS do so with the intention of using these features.
On a small team, this PR gatekeeping will mostly hurt the team. Minimally, it slows the team down, especially when the team is small enough to work out disagreements in architecture earlier in the development process. At its worst, it prevents the author of the code change from feeling real agency and ownership over the changes, which leads to lower quality. If your team works on a set of features with a lot of iteration, there will come a time when the new changes proposed are materially more important than the original design. Who owns it then? CODEOWNERS gets outdated quickly and turns into unnecessary overhead.
On bigger teams, a complex PR might touch files with multiple sets of CODEOWNERS. Now you’re stuck with a PR that needs half a dozen reviews before it can be shipped. And for people who are CODEOWNERS, it can be hard to determine where their reviews are needed or helpful, because they’re being automatically generated. In some ways, CODEOWNERS can punish highly productive engineers or the ones with the most tenure by flooding them with PR review requests.
What to do instead:
Get clear on big changes before the work gets to a PR stage. Waiting to surface these until all the code is written is just too late.
Get clear on what quality looks like. It’s not fair to only CODEOWNERS to be enforcing best practices or patterns.
Find other ways for teams to stay notified about recent changes. PR review is often used as a knowledge sharing tool, but in reality, it’s not often very effective. Instead, find something that is more useful for your team, like live demos, sharing design docs, or an internal presentation.
If regressions are a concern, look at your automated testing and CI processes. If it’s possible for a large regression to make it to prod without a perfectly careful review of a PR, you have some work to do when it comes to testing and monitoring.
Want to a place to keep track of who worked on what? You probably already use Notion or another team wiki. That’s a great place to store info about release teams along with other documentation (user interviews, discovery docs, arch diagrams) that went into the feature.
Since the answer here is “it depends,” CODEOWNERS might be a good choice if you’re working on components that commonly receive PRs outside of the core team. This might be in OSS, where specific maintainers have been appointed, or in a large organization.
I really understand the human need for ownership. CODEOWNERS is an enticing way to both give recognition and assuage fears of something big changing without enough warning. Just make sure it’s not covering up other smells on your team, or creating unnecessary gatekeeping that robs people of agency.
