Enable code ownership without automatic PR notifications for entire teams

[raphaelleu]

I'm not sure there's another place for feature requests, so here it goes. The problem is that we would like to use code ownership to enforce reviews by certain teams on certain PRs before merging but not have the entire team get notifications for all the updates on a PR. This happens because the owning team/s get auto-assigned as reviewers once the PR gets created and are therefore subscribed to the PR. This creates lots of spam.

It would be great if we had the option to use code owners for indicating that certain PRs must be reviewed by specific team members, depending on their contents, but not automatically assign the teams as reviewers or at least not automatically subscribe them to updates on that PR.

I'm aware that we can all manage our notifications, use draft PRs and I'm also aware of the auto assign functionality, but unfortunately these don't quite fit our workflows. What do you think?

Thanks!

Edit: after posting this, I noticed there's a similar discussion going on here: https://github.com/orgs/community/discussions/15747. The main post is not exactly the same, but the top comment essentially states the same issue as this.

[simondelphia]

You can currently disable the option to require review from code owners. Is that not what you're asking for?

You can also specify code owners for specific folders / subfolders of the repo as opposed to just global.

[raphaelleu]

No @simondelphia, see this part: "...we would like to use code ownership to enforce reviews by certain teams on certain PRs before merging...."

[simondelphia]

What would that look like?

[mircea-baja-sophos]

What would that look like?

On a branch protection rule you would have a checkbox "Don't notify email owners". This would support a number of scenarios e.g.:

• On a codebase there is large number of code owners. For the target branch the rule has "Require review from code owners" ticked and "Don't notify email owners" ticked. The developer that raises a PR to merge into that branch has to request a review from a few of the code owners involved, the rest are not spammed with email notifications.
• A small team uses PRs on some test automation branches. For the test automation branches the rule has "Require a number of reviewers" set to 2, "Require review from code owners" unticked and "Don't notify email owners" ticked. A developer that raises a PR for the test automation branch has to request a review from 2 team members, but the code owners don't get notified about changes that are relevant to just the test automation team branches.

[billyjbryant]

I second this request. There are times when we would like to force a required review by a member of the Security team on certain PRs but the Security Team shouldn't be Code Owners or get notifications for all PRs to the Repo, just when they are added as a required reviewer.

[dominicfraser]

It would be great to see this be configurable.

I would be great to have it enforced that a CODEOWNER review is required, and can be manually requested, but that the owner is not auto emailed and auto subscribed to the PR. When multiple PRs are being raised a day to a codeowner the amount of emails due to being assigned, new commits being pushed to each PR, discussions on multiple PRs, and the default reaction is to turn off all notifications at a repo level. This means people move to tagging people in Slack to review, or to respond to comments, which is not a desired workflow.

I came here from https://stackoverflow.com/questions/72534373/how-to-enforce-review-from-codeowners-without-automatically-requesting-a-review

which describes:

the desired flow for a contributer is something like this:
open a pull request -> mess around, make changes -> manually request a review when ready (can't merge without codeowner approval)

[matthew-kaye]

Would also love to see this. I'm getting bombarded with notifications at the moment, but the only solution is to disable email notifications and risk missing notifications that are actually relevant when I'm assigned!

[luxaritas]

Just ran across this issue - there is an individual in our "maintainers" group who should have the ability to sign off PRs, but shouldn't necessarily always be notified as new PRs go up.

[JustinGol]

Another vote to have this functionality. I want to protect a certain branch and require codeowners to approve but I dont want them assigned to the PR's on other branches.

[cmkoller]

Also want to put in a request for this functionality! To be more specific about the need we've encountered at my organization, we want to use codeowners for branch protection, but don't want the automatic assignment of codeowners to review, and also (especially!) don't want the PR notifications for the whole codeowner team.

Our workflow would look like this: a member of a non-codeowner team makes a PR, discusses during stand-up with codeowners, a codeowner self-selects to review the PR.

[adamsuskin]

^ The root cause of my GitHub notification volume issue isn't watching a bunch of no star, inactive repos. It's the problem outlined in this thread.

[jcook-uptycs]

You can use this to auto-assign for the team. https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team so not everyone get the notice.

In the same place there is also Only notify requested team members

[parhamfh]

While auto-assign works I would appreciate more granular control when creating a PR as well.
If the team is auto-requested through CODEOWNER:

• Setting for sending only initial or no notification for PR being created. This would decrease the constant barrage of emails.
• If the PR author adds members from the CODEOWNERs to the PR at creation time, do not also add the team since CODEOWNERs are represented. This is in line with the team being removed as requested once a member of CODEOWNERs leaves a review. This enables dialogue between PR authors and select CODEOWNERs for reviews, without bothering remaining CODEOWNERs.

[justin-newman]

I also agree with this. Right now if CODEOWNERS exists and a developer creates a PR into another developers working branch a code review is requested by the entire dev team (assuming the team owns the code that is being changed), but you would really only want that one dev to be requested. Then once those changes need to be merged into main or some other gitflow branch it would make sense to make the request to the whole team.

[vbabenkoru]

I'm getting spammed with dozens of notifications every day for various PRs, even for repositories explicitly added to the ignore list – I still keep getting notifications from those with no way to disable. The only way currently is to get removed from the group listed in CODEOWNERS.

[thiagobdp]

We have the same issue. We are automatically subscribed to every PR and receive infinite spam from GitHub.
Result: I had to filter GitHub emails to trash. It's totally useless...

[JacobCoffee]

We've had members leave because their team is assigned to PRs but the individuals didn't want 875 messages in their email or GH notification page. +1

[benb111]

Also have the same issue here. We are using CODEOWNERS to implement branch protection on a subset of the files in the repo, but I don't want everyone getting an email for every PR in the repository.