pullreminders
As a user, I want channel real-time messages to take take into account ignored labels, etc
Requested by @AntoineLemaire @kschaffter-carecloud
From @eladmoshe:
For the real time notifications is the Slack channel notification when someone opens a new PR and the periodic notifications of open PRs so yes. We need to filter by team, as we have microservice architecture with lots of repos. (by PR Author)
From @rdhariwal:
I am using github teams to filter pr's to just our infra team. But we noticed that if we keep real time messages enabled then pr's from team members outside of github team end up in our slack channel. Turning this setting off seems to help with the problem.
We have separate Slack channels for our teams here at Built In. I expected real time messages to be filtered according to the configured GitHub team, and found it rather confusing to have real time messages from all PRs sent to every team channel.
I will second this request! We have a custom solution at OpenSesame that automatically does backmerges between branches. It does this by opening a PR, checking if there are conflicts and then merging it if there are none. With this use case we get a lot of PR open notifications when an "Automated Merge" PR is created. We would like to be able to filter out real-time notifications like we do for the notifications to avoid seeing these system level PRs.
I also would like this feature. At Sourcegraph we have a mono-repo that multiple teams develop on. Each team has its own slack room, so most PRs via real time notifications are unrelated. Additionally, I found this behaviour surprising.
I would also like this feature. Multiple teams at my company expected it to work this way already based on the UI. Most have since turned it off entirely because of the noise levels.
Plus one on this, it would be great to be able to only get instant notifications based on labels
👍 Our organization has many teams and each team wants to receive real-time PR notifications only for PRs that the team cares about, but that's not currently possible without maintaining a list of repositories, which is not viable for teams which are responsible dozens of repositories.
Looking forward to seeing this feature!
