Hi,
We’ve been using the CODEOWNERS file to allow community members to ‘subscribe’ to pull requests based on the file paths that are being modified. This has been working for the most part, but we have uncovered some issues with our system, and I think we should re-consider what we are doing.
The three main issues I see so far are:
-
There is no distinction between a patch subscriber and a patch reviewer. Some people just want to be notified about pull requests and don’t want to or don’t have the authority to approve pull requests. Some sub-projects want to have a definitive list of reviewers who are allowed to approve a patch. Right now there is only one ‘pr-subscriber’ team, so both these groups of people are treated the same.
-
We are limited to using file paths for subscriptions. Using something else, like labels, to drive subscriptions gives us a lot more flexibility to add subscribers. We can subscribe people based on keywords or even just by manually adding a label.
-
We are not using the CODEOWNERS/Reviewers field the way they were intended. This could potentially be risky for us if changes are made to this feature that don’t consider our uncommon workflow. Using something like labels to drive subscriptions is going to be much safer, given that GitHub already natively supports subscribing to issue labels and it’s likely that something like this would be implemented for Pull Requests (especially since according the REST API, Pull Requests are Issues).
Why did we use the CODEOWNERS in the first place?
The main reason for using the CODEOWNERS file is that it allows you to be added as a reviewer right when the pull request is first created. This generates a notification for reviewers that shows the full patch diff of the pull request. Any other notification system, like one based on labels for example, would still notify subscribers almost as quickly but the first notification would not contain the full patch diff, only an html link to the Pull Request on GitHub.
The other reason to use CODEOWNERS is it doesn’t require us to write our own custom GitHub action to manage the subscriptions everything is automatically handled by the GitHub backend.
Proposed Changes
I think we should delete the CODEOWNERS file, start over, and use it only for people who are actually code owners, or who have the authority to approve commits for a specific area of the project. At the same time, we would start using labels to subscribe the existing ‘pr-subscriber’ teams to new pull requests. The main downside of doing this would be, as mentioned above, that members of the pr-subscriber teams will miss out on the full patch diff in the initial notification email. However, I think this change will sufficiently address the three issues mentioned above.