Disable Notifications For Team Mentions

[mpiggott]

I've been added to a couple teams for permission for occasional contribution though I don't participate in the daily development on their repositories. This automatically subscribes you to mentions of the team, and as far as I can tell there seems to be no method to unwatch the team.

To me it would make sense to have allow users to unwatch a team, rather than needing to maintain parallel permission structures, i.e. team-x and friends-of-team-x where the permissions are identical but the latter wouldn't be tagged.

[alex-steinberg]

🎉 +1 ^^! What's more is that a review can be requested from a team and that subscribes the team to that PR. So a team of 10 could have one or two members actually pick up the code review, but all 10 are sent notifications for every.single.comment because the request was aimed at the team. There must be a better, less noisy way to do this.

[dominicfraser]

👍 This is also similar to what is described in https://github.com/orgs/community/discussions/35673 too, "Enable code ownership without automatic PR notifications for entire teams", and https://stackoverflow.com/questions/72534373/how-to-enforce-review-from-codeowners-without-automatically-requesting-a-review

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)

[VcSaJen]

GitHub user sends notification to 400000 users
Github needs to implement it ASAP

[ajkerzner]

There should be optional limits when mentioning a target team or whatever that has, say, 500+ members. This is very much like when someone emails a Microsoft Teams email chain and ends up emailing up to 25,000 people. When the number of potential recipients goes up, the risk of misuse goes up. Find a solution.

[AntonioND]

Please, this would be very helpful. Right now my notifications are always so noisy that they are useless.

[roulettedares]

please stop the noise

[jdevfullstack]

I'm not very sure whether this is a solution, in watching the repo, there are now choices and custom ones

and at your personal settings

you can uncheck automatically watch repo when you were given access and simply customize it

[AntonioND]

@jdevstatic this is not a fix. I'm added as reviewer to every single PR in my team because my team is added as required reviewer. This bypasses per-repository settings, they are direct notifications to all team members.

[fendent]

This is essentially non-optional. I work with hundreds of repositories in our org where teams are used as a permission system. I get notifications for every single PR that comes in for these repos, despite whatever notification settings has been made.

[juanswan13]

The same issue for me, at the end I created a rule in my email to send to a different folder all the emails coming from GitHub, and also created a rule that empties the folder after a week. Because of the noise, I'm not checking GitHub emails anymore which is an issue when I actually need to review something !!

[willacai]

@mpiggott do you have the "Automatically watch teams" setting turned on? This will remove notifications when the team is mentioned in comments, but not for when the team is requested for code review as others have mentioned.

For anyone struggling with being bombarded by your team's code review notifications, the Maintainer(s) of a team can set certain team members as Code Owners, and set certain team members to never be notified. See the docs on Managing code review settings for your team:

Direct link to Configuring Team Notifications how-to: https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#configuring-team-notifications

[rcomer]

The description of the above "automatically watch teams" setting suggests that this only applies to teams you join in future. Is there another setting I'm missing that affects notifications for teams I'm already in?

[AntonioND]

While that is good to know, we need a setting that the user can set without requiring the owner of the team doing it.

[willacai]

Yup; on top of that, the "Never assign" setting is only an option when the Auto Assignment is turned on. This definitely requires a lot of active decisions and discussion within a team, which may be what Github is trying to encourage, but doesn't suit a lot of team use cases.

[Ganitzsh]

Running into the same issue, that'd be great to have a setting to only get notified when directly mentioned, and not anytime the team is added as a reviewer for every PR.

[rachellejensen]

Still facing the same issue. Different teams have different processes, and in a mono repo this doesn't make sense at the repo/maintainer level. It's a team setting based on how the team works!

[Rydez]

I'd also like to up vote this. In the case of a mono repo this is pretty unacceptable. My emails/notifications have more than a 5:1 noise to signal ratio.

[MrTemple]

How in great git's ghost is it STILL not possible to silence email alerts sent to an entire team?!

[mefryar]

Notifications for Team @mentions can now be disabled... but not notifications related to PR review requests 😞

Team Maintainers may now disable notifications resulting from a team @mention in GitHub issue and pull request comments through an optional configuration in the team settings page. Notifications resulting from PR review requests are unaffected by this setting.

[dgoldstein0]

I also have this exact same problem and am feeling huge pain now. My company

• uses a monorepo
• has lots of code ownership, with required reviews. so we're using CODEOWNERS & Teams.
• has people with different opinions on notification settings (e.g. slack vs email, whether to be notified only when you are mentioned vs when your team's code is touched etc)
• we also have our own bot for autoassigning reviewers, which kicks in asynchronously. the main difference between it and our built-in options are that it uses pagerduty schedules to assign to the current oncall for the team.

I flipped off the "automatically watch teams" option and it didn't do anything as far as I could tell - it certainly did not stop the notifications I am trying to get rid of.

I am shocked it is not possible for me to navigate to each of my teams and disable email notifications for when our review is requested. I am tempted to start marking these emails as spam.

[Ray-Eldath]

It's already halfway to 2024, can't believe GitHub still still still doesn't support mute team motifications and organizational name

Two seminal features for GitHub to be used as central code host for companies. Organization name stays on the most requested feature in the entire Profile category and notification system is one of the most important components in GitHub. Not even a single answer or comment from GitHub staffs, no, nothing.

[holograph]

Preach!

[NitzanSirota]

Coming from a relatively big company that has a huge number of monorepos and CODEOWNERS files, this is just terrible.
We either choose to dismiss all github notifications or getting bombarded with tons of PR threads that are not remotely related to us.

[holograph]

This is also a problem for medium-sized organizations with many repositories (and no monorepos). You always end up with a "superteam" for admins or principal-types, who tend to focus on one or two repositories at a time; disabling the "automatically watch teams" doesn't do much and the deluge of irrelevant PR notifications buries everything else.

GitHub, this is a real problem. Please address it!

[fusion2004]

Dittoing a lot of the above... recently added to a team whose approval is required for changing certain files via CODEOWNERS, and I do not want notifications for those PRs. We have manual processes for getting those reviews and it makes notifications very noisy and harder to find the ones from my immediate team that I need to address.

Maybe a priority system, either in addition to or instead of a disabling system, would be ideal here. I wouldn't mind getting those notifications if I could filter them out and only check them every day or two.

[ianks]

Yeah this is definitely a pain point...

[satejbidvai]

Has this been solved?

[msdsk-quinyx]

In our org the team is added as a reviewer to every PR as a code owner. On top of that, we have a PR review lottery that requests reviews from an individual and only that individual is actually expected to review the code. Now, I need a way to sort through what is the useless team notifications from personal assignments - but they're both just "review requested". So, yeah, ditto.

[alexkatja]

This is a pain point for us as well. Please offer the ability to have the permissions and abilities of a team, but not receive notifications of all team mentions.

[andrewrjones]

A potential solution would be to have team mentions CC an address like team_mention@noreply.github.com, so we can filter out the emails at least.

Where we have monorepos that use code owners heavily the notifications are useless for me.

[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 on the other linked discussion but wanted to share here too:

My team Upshift (YC F24) is now working on a replacement for codeowners (migration tool included) that can prevent PR authors from notifying the owners (including team notifications!). This can be used as a replacement workflow so you can keep your inboxes much cleaner! As an equally frustrated Github user, I know it's not fully getting at the notification controls for general team mentions and other workflows, but maybe this can help you if the main way it happens is through automatic codeowner review assignment.

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.

[samus-aran]

Hi @adamsuskin , we’re glad you’re here 😀

Thanks for sharing your project with the community. Unfortunately, we currently do not allow self-promotion or advertising on the Community Discussions. We want to make sure there is space for users to ask questions without overwhelming them with other conversations and prevent soliciting from getting out of hand. Thank you for helping us maintain a productive and tidy community for all our members.

[fendent]

@samus-aran while I agree with and understand the spirit of the rules regarding self-promotion, it does feel a bit disappointing to have this issue ignored for several years and the only response received from GH in all that time has been to ask someone sharing a possible solution to the problem to not do so

[MrTemple]

Hi @adamsuskin , we’re glad you’re here 😀

Thanks for sharing your project with the community. Unfortunately, we currently do not allow self-promotion or advertising on the Community Discussions. We want to make sure there is space for users to ask questions without overwhelming them with other conversations and prevent soliciting from getting out of hand. Thank you for helping us maintain a productive and tidy community for all our members.

Overwhelming us? Get real.

What's "out of hand" is that this thread still has to exist due to the complete lack of consideration for users shown by not fixing this.

[dserodio]

While I agree that, in general, it’s poor form to promote your project within a "competitor's" platform, and I’d much prefer if native GitHub notifications worked well, I might have to consider an alternative solution like Code-Captains because the native notifications are barely usable at the moment.

[adamsuskin]

@samus-aran thanks for letting me know! FWIW, we want Github to fix notifications too.

We don't see ourselves as a competitor as we are not a notifications solution. We are trying to help teams who may have complex review routing procedures because of compliance or other requirements. We also want to help teams who want to use code ownership as an input to other workflows like support ticket routing or other use cases.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[emmaviolet]

Folks - thanks so much for your input here. I'm the PM Director overseeing Notifications, and I'm sorry about the lack of response here - that's on me.

This is definitely a workflow we'd like to support, along with several other improvements we want to make to give you much more control over the kinds of notifications you receive. Candidly, though, we're a while away from getting there; we need to make some improvements to the current Notifications platform in order to be able to support this work, and that's (best guess) about a year off.

[shervinrad100]

Hey @emmaviolet
What's Github's process on prioritising feature requests? We are having this issue across our company as well and was wondering if there's a voting system where we can gauge interest in a certain feature. Do we just upvote this thread or are there other channels to follow?

[emmaviolet]

Thanks for the feedback! Upvoting is the best way to signal interest - the Notifications team itself is at capacity for the foreseeable, but we do review community threads in general to see where there are smaller wins other teams should pick up.