Allow multiple teams to own a directory/file

[Michael-M-Judd]

I have a scenario where multiple teams own a specific directory and either of them can approve changes. I know a single owner would be ideal, but I think a lot of times this ends up happening.

Have we thought to make multiple owners configurable? Things that come to mind:

• when 2 globs are the same, allow it
• support multiple teams in the .codeowner file (1 per line)
• support multiple teams in packwerk config

[professor]

In our context, we have downstream tooling that requires only one team owner per file or per pack. Further, we've found that when two teams own something, no one owns it and would prefer to have 1 owner.

If you want to pursue this in a way that is opt-in, I am open to review it

[huguesbr]

We would love to see this too..

[Michael-M-Judd]

In our context, we have downstream tooling that requires only one team owner per file or per pack. Further, we've found that when two teams own something, no one owns it and would prefer to have 1 owner.

If you want to pursue this in a way that is opt-in, I am open to review it

I totally agree in theory as well. Unfortunately our organization does have some overlap on folders.

I'm happy to take this on, @professor just to confirm, when we say allow opt-in you're thinking a cmd-line config option like --allow-multi-team?

[alexevanczuk]

Hey @Michael-M-Judd , if the overlap is on a folder level, why not use file annotations to specify the owner for each file within that folder? That's the equivalent of specifying multiple owners for one folder.

Or are you saying that there are certain files that are owned by multiple teams? Typically I've dealt with that by finding ways to improve the boundaries/responsibility of the file. The tool as originally designed was meant to be opinionated such that mega-files with too much responsibility go against the grain a bit.

The benefit of this is the tool becomes a lot easier to maintain and use in a lot of ways, although might be interesting to support it as an isolated experiment to better understand how it affects the structure and usage of the tool!