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.

[torressam333]

@justin-newman did you find a workaround?

[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.

[torressam333]

Any solution to this?

[dgoldstein0]

Also had this problem.

My workaround was to disable email notifications entirely and configure slack notifications instead. One of the biggest downsides with the slack notifications is that they only notify me when my diffs land, not diffs I review, so still leaves a gap between what I get notified of and what I want to know about.

My company is actually building our own notification service because of these issues. Which is ridiculous because I'm sure we pay a lot for github, and clearly the non configurability of the email notifications is a problem for lots of medium sized and larger companies.

[torressam333]

What a bummer. I had to delete CODEOWNERS and then add a custom workflow that requires a codeowner approval without explicit email notifications.

[dgoldstein0]

We've also built our own ownership reviews check that we require for merging instead of github's. I think that was driven by other concerns though. We're using that and code owners because code owners is the only thing that gives us ui that shows who owns what or let's you filter to changes to your team's files

[IanGrainger]

It seems like if you have a team of more than (say) two people, almost no-one would want ALL of the team automatically subscribed to ALL of the PRs so they get notified of ALL of the comments.

What a bummer. I had to delete CODEOWNERS and then add a custom workflow that requires a codeowner approval without explicit email notifications.

This sounds like a workaround, how did you do this please?

[elias-pap]

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

We use this plus a dummy user that gets auto-assigned all the PRs and notifications by default, so no one else gets them. It looks like this:

1. Add a dummy user to your team.
2. Go to https://github.com/orgs/your-org/teams/your-team/edit/review_assignment
3. In "Never assign certain team members", select all team members other than the dummy user.
4. Configure like this:

[dstorch]

This is an issue for my company as well! We have a large engineering organization, so each of our Github teams may consist of 10 or even 30 engineers. When those larger teams are assigned as CODEOWNERS, the volume of emails gets too large. We would love to see more configuration options around email notifications for PRs.

The workaround we have implemented is similar to what @elias-pap described above:

• We created a dummy account.
• We have a script in our build process that generates the CODEOWNERS file, and this makes the dummy account an explicit owner of everything (in addition to the actual owning team).
• Teams who don't want email notifications on PRs can then add the dummy account to their Github team and can configure the "Only notify requested team members" option. Since the dummy account is always requested for review (it owns everything), and since the dummy account is a member of the team, the team will not be notified.

[Muneeb147]

But that will always require dummy's account approval. The original team members approval would be of no use unless or until the dummy account approves.

I am assuming you are talking to have following entry in CODEOWNERS file:

* @dummy-acount
* @actual-team

[dstorch]

@Muneeb147 our CODEOWNERS file looks like this:

file.cpp @actual-team @dummy-account

My understanding is that this means that either a member of the actual team or the dummy account must approve. Approvals from both are not required.

[Muneeb147]

Yes this structure makes sense.

[gauthierpetetin]

This is my biggest pain point on Github.

• I need to be notified when I'm personally @mentionned.
• I don't want to be notified for all activity on PRs where my team is listed as reviewer, as this happens hundreds of time per day.

Due to the latter, I currently receive hundreds of notifications per day, which constantly disrupts me in my work. I can't blindly delete all these notifications because I first need to check for each notification if it's destined to me personally or if it's destined to my team.

[adamsuskin]

Hi everyone, I've reached out to some folks here already but wanted to share here too:

My team Upshift is now working on a replacement for codeowners (migration tool included) that can prevent PR authors from notifying the owners. This can be used as a replacement workflow so you can keep your inboxes much cleaner!

It's called code-captains, and it's open-source and MIT-licensed. Please feel free to reach out on Github or to me personally if you want to talk about code ownership / request more features.

[MickeyPagaya]

This is indeed really needed, we've reduced our use of code ownership just because of this reason.