Feature Request: Add a flag to allow unowned files without disabling file annotations

[euglena1215]

Summary

We propose adding a new configuration flag (e.g., allow_unowned_files: true) to config/code_ownership.yml.

This flag would allow the gem to run successfully even if some files do not have an owner, without interfering with other ownership mechanisms like File-Annotation Based Ownership (# @team MyTeam).

Problem: Current Workaround Conflicts with Annotations

Our team does not enforce 100% code ownership coverage. We only assign owners to critical files, and most of our files are intentionally left unowned.

To prevent code_ownership from failing, we tried setting unowned_globs to cover all files:

# config/code_ownership.yml
unowned_globs:
  - '**/*'

This successfully prevents errors about unowned files.

However, we discovered that setting unowned_globs: ['**/*'] appears to disable File-Annotation Based Ownership. Files that have a # @team MyTeam annotation are no longer recognized as being owned by that team (presumably because unowned_globs takes precedence and stops further processing).

Desired Behavior

We want to achieve two goals at the same time:

1. Allow unowned files: The build should not fail if many files have no owner assigned.
2. Respect file annotations: Files that do have a # @team MyTeam annotation should still be correctly recognized and owned by that team.

Proposed Solution

We suggest adding a new boolean flag to config/code_ownership.yml, such as allow_unowned_files:

# config/code_ownership.yml
allow_unowned_files: true

# We would remove the unowned_globs: ['**/*']

How this flag would work:

• When allow_unowned_files: true, code_ownership would not raise an error if it finds files that have no owner (from any source: owned_globs, package_owners, or annotations).
• However, it would still process all files to identify owners for files that do have annotations or match other rules.

This would allow teams like ours to use code_ownership to manage owners for the files we care about, without being forced to achieve 100% coverage.

Thank you for considering this feature!

[martinemde]

Hi @euglena1215,

Right now our team works around this by having a team called unowned that owns the unowned files. In fact, we have a team that is responsible for the unowned files and they can make choices about when files should be unowned (so the actual team name is team-name-unowned).

The advantage of this is that you must intentionally mark a file unowned which avoids the problem of having files that should be owned that get missed.

However, it seems like this might be a lot more work for you. What do you think of this workaround as the recommended solution?

[euglena1215]

Hi @martinemde,

Thank you for your comment and for sharing that very helpful workaround.
The approach of intentionally setting an unowned team to prevent files from being accidentally overlooked is very rational. We definitely understand the benefits of that method.

However, our requirement is slightly different. We are looking for a way to avoid enforcing 100% ownership coverage. Our ideal state is to allow files without annotations to be "unowned" by default, without the build failing.

As we understand it, your suggested method still aims to assign an owner (even if it's a dummy one) to every single file.

What we hope to achieve with the proposed allow_unowned_files flag is a more permissive operation: one that respects file annotations (# @team) but doesn't error on any other file that lacks an owner.

We believe this approach would be valuable for teams like ours who aren't aiming for 100% coverage and want to use code_ownership while explicitly allowing some files to remain unowned.

We hope you'll continue to consider adding this feature (the allow_unowned_files flag).