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.

[mateusz-wlosek-ppro]

My company is affected as well. Will Github ever do anything about such issues or will they keep ignoring all the issues with user experience in Github?

[RajuKattamanchi]

I second this problem and wish GitHub can do something about it.

Also, The CODEOWNERS file doesn’t have an option to differentiate between draft and ready PRs. I do not want my code owners notified if its just draft PR.

[gdrt94]

I'm currently dealing with this using Gmail filters.

I have noticed that Github adds the following footer to such emails: "You are receiving this because your review was requested". But when someone explicitly mentions you, not just the team, the footer is "You are receiving this because you were mentioned".

So I have created the following filter in gmail to filter out github noise:
Matches: from:([email protected]) "You are receiving this because your review was requested" Do this: Skip Inbox, Apply label "Github Noise"

Everything else from Github ends up in my inbox.
Hope this helps.

[CreepyGnome]

That footer message is a 1 to 1 mapping to just using the email [email protected] being CC'd to, which is more efficient way to filter over a string match in the body of a message. However that doesn't solve the issue it is actually hiding the problem. That is how we should be notified that where were requested, but with codeowers it breaks that if you have 100 code owners all of them will get an email requesting their review.

I think @elias-pap suggestion above where actually is a good hybrid solution to use with codeowners. I was able to get it working and it isn't a perfect solution it does work just not convenient or obvious and requires you to be a maintainer of the group that is the codeowner, etc etc. But still it is a viable option.
https://github.com/orgs/community/discussions/35673#discussioncomment-10340196

[CreepyGnome]

Hmm so it seems like GitHub does not provide a way to limit who is ALLOWED to approve PRs to a specific group of people, without also adding them automatically to the PR for review and then sending spamming all them an email.

It would be nice is there was a way to have two groups of people, the superset that has ALL the people allowed to approve PRs and then a subset of those that are automatically added to the PR for as a group who would then be notified. This way we do not spam 100's of people, when we only need to spam maybe 10-20, as we have a number of people who should be allowed to approve them to pass checks but do not need nor want to get the email notifications.

A quick and simple use case is let say you have staff engineers, principle engineers, architects and they need and should ahve the ability to approve PRs and pass the check that they are approved. While not spamming them with every PR a repo makes. They would like to know when someone has manually added them for their opinion or desire for feedback, so they can know when they see an email from [email protected] it really means something to them and they can prioritize it to be reviewed.

The current implementation in GitHub if we use CODEOWNERS file is that we will be spamming everyone in this file by that email address which will make that email address worthless to those as a tool to filter by.

Not sure if there is another way with existing GitHub settings or CODEOWNERS to achieve this tiered approach for approvers and those notified automatically to review a PR.

[cunisia]

For your specific use case @elias-pap work around might work
https://github.com/orgs/community/discussions/35673#discussioncomment-10340196

[CreepyGnome]

Thanks, I can look into that, but it will require lots of back-and-forth with the org admins, and since this will be a trial-and-error thing, I'm not sure if they will want to do it. I will try to give it at least a shot. lol

[belm0]

I have noticed that Github adds the following footer to such emails: "You are receiving this because your review was requested".

This doesn't distinguish between you being specifically assigned for review vs. team being assigned for review.

[gdrt94]

Since we're not using personal review assignment functionality in our team, this is fine.
All I care is that when someone comments on my PRs, replies to my comments, or mentions me in someone else's PRs, I get a notification and that in all other cases I don't get a notification.

[dvochoa]

This issue has caused me so much frustration, please fix this 😭

[CreepyGnome]

Have you tried @elias-pap suggestion above
https://github.com/orgs/community/discussions/35673#discussioncomment-10340196

[codymoorhouse]

This would be a fantastic feature, would love to prevent automatic PR notifications for the entire team but still assign code ownership

[marcoieni]

GitHub, consider adding this feature to the codeowners file:

• if the file contains @username, they get notified (current behavior)
• if the file contains @_username they don't get notified but they can still approve changes to those files.

[corsonknowles]

Can we ship this already, please?

[waltervillarreal]

I second this, its really annoying

[cgruber]

This is starting to look like Github is abandonware. (I know that's hyperbolic, but this dialogue is so similar to abandoned projects)

[epiqu1n]

Please add this! The amount of email noise has immediately become problematic since we added code ownership rules for our team's files, but the benefit of code ownership rules is too much to give up.

At our org, if a team needs external code review then they just drop a message in the other team's channel. We don't need the entire team getting emails for every PR that goes up where we're code owners, let alone emails for every comment and update that happens on all of those PRs.

It would be a big quality of life improvement to be able to turn that off, and it's a bit frustrating that we are so close to it given there is already the "Only notify requested team members" setting (which only works if you set up auto-assignment).

[tarfeef101]

This is so crucial I can't believe it isn't already a thing, and doesn't have thousands of upvotes.

My team has ownership of tons of things. However, we assign 1 person on any given day to be the supporting engineer who fields questions, reviews PRs, etc. We want to express ownership through CODEOWNERS to ensure someone from our team reviews changes to stuff we own, but we neither need nor want the entire team to get emails about every single one of these changes. We have external mechanisms to figure out who specifically will review something (manually adding someone who worked with you on something, or was the original author, "tagging that person handling support tasks for the day", usually all this is through a messaging tool like slack...). github should be more flexible to allow for teams' workflows.

[Mariuble]

Still waiting. Our workaround is to not use codeowners...

[Cordazar]

GitLab solves it like this: https://docs.gitlab.com/user/project/codeowners/reference/#optional-sections

the [Go] section is optional:

[Documentation]
*.md @root

[Ruby]
*.rb @root

^[Go]
*.go @root

Should be easy enough to implement with the resources of M$ at your disposal, right?