slack
slack copied to clipboard
integrations
Disable `send send to channel` after PR is merged
Hello,
Is it possible to disable sending to channel PR merged message when threading is enabled?
Hi @mishastir-fulcrum the reason for posting the pr merged and issue closed notifications to channel is because these are state changes i.e. important enough notifications that channel members might be interested to look into.
We will gather more feedback and then decide on the next set of improvements.
Also reported at https://github.com/integrations/slack/issues/1566
Agree with notification on state change - but the threading is causing additional noise. With the earlier behaviour of posting to a dedicated channel/s - folks can choose the frequency at which they would like to know of changes that were merged. However - the current behavior adds all of this data to the threads view where it is not as simple to filter out messages.
If the maintainers feel that this is a must have - would it be possible to allow users to opt out of this behavior?
This comment here https://github.com/integrations/slack/issues/1500#issuecomment-1281990344 says that threading was done to reduce noise in the channel. Not sure how is that true if these notifications get sent to the channel anyway.
I would love if I could disable this being sent to the channel as well. I'm fine with threading since it keeps these notifications under a certain context, but getting a notification for the thread message and sending that message to the channel as well just creates a large amount of noise in our Slack channels. We don't have a dedicated channel for all notifications, but rather notifications per project we work on since we work on multiple projects. There are multiple people included in those channels (not just devs) and this approach is spamming in multiple ways.
Not saying previous workflow before threading was ideal as well since it did mostly the same, but at least it didn't post multiple messages for one action.
Btw, thank you for your work. I really like this integration and wouldn't want other colleagues to ask me to disable it because it creates too much spam for them since I do benefit a lot from using it.
I also ended up here trying to figure out why "Enable threading for Pull Requests and Issue notifications" wasn't working as I expected, it seems weird that it's pushing to both places. I would have expected one or the other.
I think ideally this setting is at least 4 options: A: Post updates nowhere B: Post updates to thread, C: Post updates to the channel (old functionality), D: Post updates to both thread and channel (new functionality)
I'd want B personally, but I'd actually even prefer A over C or D.
Thanks for the feedback. We will look into this request.
Thank you!
And if it can be done, would it be possible to set custom preferences as a global setting that would get applied to any new channel that gets subscribed to a repo? I don't mind updating settings for existing channels, but would love if I could set up global preferences that would be applied to any new channel subscription 😄
If that's not possible, it would be great if these settings could be set immediately when invoking subscription command /github subscribe organization/repository --some-flag or something like that.
Hah, I'd love that too but that should probably be it's own ticket even! One thing at a time
Hah, I'd love that too but that should probably be it's own ticket even! One thing at a time
Yeah true. As long as this is addressed first, I can live with manual settings update. I don't actually connect a new Slack to GitHub that often so doing it from time to time doesn't seem like such a chore.
It's way more important for me to get actual options when enabling/disabling different behavior 😄
Hello guys,
I would love to have this feature as we are using the bot to handle reviews on my squad and I find that it create a lot of noise making me scroll to find new PR. I prefer having all github bot message related to one PR inside the initial thread.
Agreed! Send the message to the channel, or the thread, but not both! It (almost) completely invalidates the usefulness of threads if you spam everything to the channel too.
+1 here too. Threading is such a great feature, the whole team here would love to fully thread everything! 🪡
I can understand this option in a small based project, however if you have many devs linked to one channel, gosh. I can have sometime 5 PRs in a row spam this open, closed, merged. Keep it in the message thread and not in the channel broadcast.
I can understand this option in a small based project, however if you have many devs linked to one channel, gosh. I can have sometime 5 PRs in a row spam this open, closed, merged. Keep it in the message thread and not in the channel broadcast.
Yeah totally. I work in an agency and we have this enabled for multiple projects. We actually started turning off the integration because it just spams everyone too much, especially people that are involved in multiple projects.
We kinda agreed internally that if someone wants these notifications, they should create their own private channel and enable them for themselves for any project they want to. That way they don't spam other people unnecessarily.
+1 for being able to turn off "Also sent to the channel" for updates on a PR. It's super annoying to have to clear/check both the thread and the channel.
+1 on this. Notification of an update to a thread in the main channel completely negates the benefit of updating the thread itself in the first place
I think our team would prefer the opposite to most suggestions here which is to just post to a channel with no threading. Putting a merge notification into a thread for example would negate part of the point of this integration for us as we like to be notified once something has been merged. We’re a smaller team though so the frequency of PRs is much lower so I can completely see how having more PRs would change that viewpoint.
Seems like a flexible option for either threads or no threads is needed imo.
I think our team would prefer the opposite to most suggestions here which is to just post to a channel with no threading. Putting a merge notification into a thread for example would negate part of the point of this integration for us as we like to be notified once something has been merged. We’re a smaller team though so the frequency of PRs is much lower so I can completely see how having more PRs would change that viewpoint.
Seems like a flexible option for either threads or no threads is needed imo.
@vaunus Admittedly I haven't tried it, but I'd have expected the option mentioned by shivananda-sahu to do what you're wanting already?
I see
+1 to be able to disable the 'send to channel' behaviour. It creates a lot of noise having duplicated notifications.
It would appear there are three options
- Everything to be threaded - not supported at the moment
- Mostly threaded but some key updates posted to the channel - existing behaviour by enabling threading
- Do not thread anything - existing behaviour by disabling threading
It would be amazing to get Option 1 as it is quite desirable. If not maybe update the wording as the setting text implies it's Option 1 when it is actually Option 2
I would really appreciate this functionality as well. This would allow a Slack channel to just be a nice organized collection of GitHub PRs as threads which can be important for very large projects and teams and make it much much easier to find the information you need when you need it.
Would be a useful feature for our team. Especially if we can customize it per channel.
+1 to this feature. Came here looking how to do this. Please make it an option.
With threads available, an option to remove posting in the main channel is a must-have.
ashokirla commented [on Dec 11, 2022] Thanks for the feedback. We will look into this request.
Is there any update on this? When do we expect this request might be worked on?
+1 This feature would really help us cut down on noise.
Large team with several repos, the point of this channel is so that we can keep track of all of these in once place - but the noise added by all threaded replies also being sent to the channel, defeats the purpose of said channel.
