Add CODEOWNER for each module

[bazelbuild]

Add CODEOWNER for each module

[Wyverald]

IMO CODEOWNERS isn't the way to go here, precisely because it only works for people with write access. That's simply not scalable. I've been meaning to write some sort of bespoke review automation, but still haven't gotten around to it.

[alexeagle]

yup, I think we can adapt rules_codeowners to keep a central CODEOWNERS file up-to-date, I can send a PR as I've wired that up before for Angular.

[alexeagle]

I'd like to land #86 first so that we have a Bazel workspace in this repo, then I can add rules_codeowners to that.

[aignas]

What is the status of this? Is it still desirable? Would it be OK if we added a manually maintained CODEOWNERS as a stopgap solution?

[meteorcloudy]

Would it be OK if we added a manually maintained CODEOWNERS as a stopgap solution?

That sounds good to me!

[aignas]

I am thinking that something like below would be nice:

# Default owners is a list of people that will get assigned as reviewers
* @bazelbuild/bcr_reviewers

modules/rules_python/ @bazelbuild/rules_python_reviewers
modules/rules_python_gazelle_plugin/ @bazelbuild/rules_python_reviewers

However, the @bazelbuild/bcr_reviewers and @bazelbuild/ruiles_python_reviewers GH groups would need to be created. Right now I see that there are a lot of people from Aspect and Google that are stamping the PRs but I have no way to see who is part of the group, so a GH team within bazelbuild could make sense here. What do you think?

cc: @rickeylev

[meteorcloudy]

I think this pattern is nice for rules under bazelbuild, we already have a @bazelbuild/python-team team. We could probably just use that. However Github teams are not publicly visible, while I can @bazelbuild/python-team, it probably shows as a plain string for you? Are you sure this would work as expected in the CODEOWNER file (e.g. send out notifications to the team)?

[aignas]

At day job we use teams for this, but it is not visible for the outsiders, making it much less viable.

[alexeagle]

I can pick this up again, now that we have the Bazel workspace setup here. I don't think manual review is going to work well since we already have over 150 modules

[alexeagle]

Note that about 40 modules have no maintainers listed

for m in $(find modules -name metadata.json); do jq -r 'if .maintainers | length
 == 0 then .homepage else "" end' $m; done | sort | uniq | wc -l
      41

so we'll have incomplete coverage.

[alexeagle]

As a start, agreed with @meteorcloudy this morning that we should have non-empty list of maintainers in every module. For those which are currently empty, we'll add a sentinel value that [email protected] are the de-facto maintainers.

[meteorcloudy]

Thanks for fixing this! I'll follow up to set up some automation with GitHub Actions.