search

integrations / slack

Bring your code to the conversations you care about with GitHub's integration for Slack
https://slack.github.com/
MIT License
3.12k stars 490 forks source link

Option for disabling threading feature #1500

Closed gecko655 closed 2 years ago

gecko655 commented 2 years ago

Describe the solution you'd like Recently (within last 2 hours?), Issue comments are posted as thread posts of their issue creation post. This feature is described here: https://github.com/integrations/slack#threading

This behavior is too annoying because I missed important comments that are commented to issues and are important for all staffs. I want to disable any threading feature, so that all issue comments are posted in main slack timeline.

Describe alternatives you've considered Just reverting threading feature also solves this problem.

Additional context Screenshot of current threading feature, rolled out in last 2 hours.

スクリーンショット 2022-10-18 16 26 37
ashokirla commented 2 years ago

Hi @gecko655 👋 Yes, we have recently enabled threading feature for issues. The same will be applied to PRs as well. The main reason for moving the notifications of issue into thread is to reduce the noise in the channel. We heard from multiple customers that the channel has become pretty much unusable for other communications. After careful evaluation we have upgraded our notifications to thread so that all the context is in one place for users to track.

Regarding your concern, you will not be missing any comments that happen on Slack. Any participant of the thread will be automatically notified in slack. This is the native behaviour of slack and most of the apps take advantage of this functionality to ensure only relevant folks are notified. We have another feature called 'mentions' that ensures any person mentioned in the issue parent card or subsequent card is already considered as participant in the thread. And you will get notified.

Thanks 🙏

Ovis commented 2 years ago

With this feature enabled, the person who created the Issue will also be notified when the comment is posted. However, for my purposes, just having it posted in Slack is sufficient. Also, I think it is unnecessary for Slack to send a notification to the person who made the post on GitHub. It would be very inconvenient for me to be notified by replies unnecessarily.

tamakiii commented 2 years ago

I don't think it's noise, but valuable information. This change of behavior is making me and our team being actually confused. Information design shoud not be forced by tool.

gecko655 commented 2 years ago

Actually my colleagues and I are failing to follow the conversions conversations, which I am not assigned, mentioned or I have not commented to. I need such "noise"s to get "what's going on in my whole team".

These "noise"s can:

Could you reconsider the situation and implement the option (or revert the threading feature), please?

edit: fixed typo(conversation)

ashokirla commented 2 years ago

Thanks everyone for your feedback. Threading is the just one part of the bigger story where we want to bring in collaborative aspect by providing ability to act upon the issues and also participate in the discussion in the place where you have all the context and history.

Moreover, as part of issue notifications, create issue, close issue and reopen issue notifications are also shared to the main channel. Only the comments are limited to the thread and not broadcasted. We are being opinionated here and only want to get the attention of participants, mentioned and assignees.

If others who are not involved and want to track comments in a specific issue (which is not a core scenario), they can click on the card and select 'Get notified about the new replies'. With more notifications types being added, we are trying to standardise a pattern that can scale and also address customer scenarios.

Having said that, we don't want to leave you at a place where your requirements are not met. One option, I can think of right now is to give an option to broadcast the comment messages as well to the channel, which basically means, the noise is not reduced. We will evaluate this feedback and take a decision.

Thanks 🙏

gecko655 commented 2 years ago

The broadcast feature is what I wanted. I hope it will be available soon.

Thanks!

MH4GF commented 2 years ago

Any participant of the thread will be automatically notified in slack.

I want to disable any threading feature too, I will describe my use case for reference. I used the posts as valuable information to keep abreast of discussions that did not directly involve me.

shige commented 2 years ago

This feature is described here: https://github.com/integrations/slack#threading

I'm very confused with this release. I lost my productivity by not being able to read the comments I needed and getting more notifications I didn't need. :(

I want to manage the settings so that I can enable/disable both of the following features.

Thanks!

ChrisAshworth commented 2 years ago

Hello GitHub integration team, thanks for your work. Adding a few thoughts here.

I'm confused by this description:

Yes, we have recently enabled threading feature for issues. The same will be applied to PRs as well. The main reason for moving the notifications of issue into thread is to reduce the noise in the channel.

The noise in our channels has shot up since these changes were made; it is much more noisy now and hard to follow actual human conversations. Adding a thread that then posts back to the channel itself seems doubly noisy for no reason.

Every channel we have that has a github integration is now harder to use, and we are starting to consider turning off the integration.

A related issue that came with this change is the addition of the (Comment) (Edit) (Reopen) buttons that show up in the threads, which particularly on mobile devices makes it feel like we can mess up an issue with an accidental touch. Several people on our team have reported feeling that this new addition is stressful.

Thanks for your consideration and your work.

codeknitter commented 2 years ago

The noise in our channels has shot up since these changes were made; it is much more noisy now and hard to follow actual human conversations.

Yes! I'm experiencing this same issue that @ChrisAshworth mentions.

Here is more info about our use case and set up. I hope it helps you find ways to adjust this feature to make it work better for more of us.

I really appreciate all the hard work that goes into making GitHub work seamlessly with other products such as Slack. Most of the time these improvements help us be more efficient for which I am grateful!

And I totally understand how tricky it can be to balance various use cases and business needs when building and improving features.

I hope that I've explained our situation well enough that you'll be able to provide some way for us to adjust the GitHub-Slack integration to better fit our needs. Thank you for your time and consideration.

Edit: It may be that we have our GitHub-Slack integration set up in this specific way to address some of the very issues that this current threading feature release is meant to address. We're open to change, but please understand that organization change isn't always easy and usually not quick. Changing a company's workflow can be done but we need some time in advance to prepare everyone for the change.

tchamblee commented 2 years ago

The noise in our channels has shot up since these changes were made; it is much more noisy now and hard to follow actual human conversations.

🖐️ Our Slack channels too. I've been getting hammered with Slack @mentions. Half the time the mentions are as a result of my own comments in Github. 🤦

sakimyto commented 2 years ago

I would like this feature very much. There are many similar opinions in the Japanese engineer community...

nielsiano commented 2 years ago

This is an absolutely horrible change. Please at least make it an option to have all comments in the channel as before.

EdwardSalkeld commented 2 years ago

This really doesn't seem to be very well thought through. I don't hate the threading element, but there are a couple of absolute dealbreakers here. @codeknitter above highlighted them pretty well so I'll just stress the ones that I think are particularly mad/bad.

Every GitHub comment made triggers a notification saying a NEW issue was created.

This is just silly. I can see the problem you're trying to solve but... they're not new issues.

When there were new GitHub comments, only the GitHub comments Slack channel showed new messages. I could easily ignore this one channel until I was ready to scan through all the recent comments.

And this goes double for muting the notifications. I've got the GIthub App channel muted and can just check it at my leisure. Now it's shouting at me all the time.

mgreystone commented 2 years ago

I can't describe this frustration any better than @codeknitter either.

However, i'm afraid i also need to double-down on how disruptive these thread notifications are. I am now being constantly pinged after business hours & had to change my DND schedule to compensate. I'm now worried i am going to miss actual messages from coworkers.

ashokirla commented 2 years ago

Hi all 👋 ,

As mentioned previously, we will provide an option to enable broadcasting of the comment notifications to the channel. We will rollout this support in about 2-3 weeks. With this feature, you can choose any subscription in the channel where comment notifications is enabled and decide if you also want to see the comment notifications from the thread in the direct channel stream as well.

Thanks 🙏

sullman commented 2 years ago

I'm just adding noise by saying "us too!", but I feel strongly enough that maybe more noise will help convey the magnitude of the feedback here. The commitment to an option to enable broadcasting is better than the status quo, but not as helpful as an option to turn off threading completely.

@MH4GF described it very succinctly:

I used the posts as valuable information to keep abreast of discussions that did not directly involve me.

For GHIs that I opened, am assigned, mentioned in, or otherwise subscribed to, I already have the first class notifications view in GitHub. Our slack integration was noisy on purpose because it allowed an easy way to keep abreast of the things that I wasn't already subscribed to. I might see a comment on a GHI and realize that I need to be involved and want to either reply or at least subscribe to the issue. The option to broadcast all threaded replies at least helps with this (even if clumsily).

@codeknitter described the problems with threads well, so I'll just highlight the key comment to me:

The unread "Threads" channel just showed people-conversations, no bots or GitHub comments. This made it super easy to follow up on product discussions with coworkers. And the conversations were easy to find in Slack.

This change has made my slack Threads noisier and less useful. If someone replied to a GHI I opened, I was going to see it anyway. But now it's polluting my slack Threads. And since Slack threads don't collapse the first message in a thread and new GHI messages tend to be long, the messages filling my threads are huge. These are the issues that won't be helped by simply allowing an option to broadcast all threaded replies.

ashokirla commented 2 years ago

@sullman We have also made a change to stop you from mentioned when you create or comment an issue. Please refer to my comment here.

gecko655 commented 2 years ago

@ashokirla

I'm glad hearing options will be available in a couple of weeks. But I just want to make sure one thing. Are you planning to revert the threading feature until the broadcasting option to be available?

After I worked an entire day, I don't think we can stand the situation for weeks. We are finally posting their GitHub comments to the Slack main timeline MANUALLY, to share their comments to the team. Our productivity has been ruined widely by this manual sharing. I am looking for another automatic posting Slack bot to endure this painful weeks. (@.everyone Let me know if you have suggestions)

archon810 commented 2 years ago

We subscribe to the organization, not individual repos (not sure many people are aware that this is even possible).

I hope it will be possible to change the upcoming threading settings just for the organization and have it apply to all the repos.

mario-steinhoff-gcx commented 2 years ago

First: Much thanks for putting some long-overdue work into this integration!

So far, the integration only allowed to enable/disable notifications for issues, pull requests and comments. This is a design decision I always found a bit weird, given that comments are not top-level objects in a github repo but always related to either an issue, or a pull request.

Then there are discussions which also have comments but for which there are no comment notifications sent at all, so for discussions I always have to look at my emails but then I only get notified for discussions I have participated in. Yes I know that for discussion its called answer and reply, but from a user perspective I dont care about this - its a notification related to an existing discussion.

My team works with a single repository and uses issues, pull requests and discussions to manage all of our work. We created a slack channel per notification type, so now we have a channel for issues, pull requests, discussions and comments. But only as a workaround because its was not possible to route issue comments to the issue channel and pull request comments to the pull request channel.

This change here now broke our notifications: our comment channel doesnt contain the original "issue created by" messages, which leads to a lot of duplicate "Issue created by" messages in the comment channel just so the integration has a slack message where it can add a thread reply with the actual comment message.

At this point we could maybe unsubscribe from comments in the comment channel and subscribe for comments in the issue channel, but right now threading only works for issues and not for PRs, so this would cause PR comments to go to the issue channel which would be even more confusing.

If you want to do incremental releases and gather early feedback thats totally fine but why on earth didnt you include at least some option to disable the new threading behavior? Looking at the readme it seems that now we have to wait three weeks so we can disable the new, somehow broken behavior?

No idea what to do here, this situation is really disappointing and frustrating.

AshleyPinner commented 2 years ago

There's a side effect of this that still is happening: If an issue that is assigned to someone in slack is closed, the GitHub slack integration then @'s them. For an issue that is closed. This never used to happen with the previous behaviour and is now causing excessive notifications.

Granted, development can't turn on a dime, but asking for us to put up with this for 2-3 weeks is going to get old very very very quickly.

trevor-scheer commented 2 years ago

We're in the process of closing out a bunch of old PRs and issues (like multiple years old). Every time one is closed, I get a message that an issue was created (presumably because GH app needs a place to thread the closed message). This is really confusing and I now have a swath of "new issues" that I need to go and check that are actually very stale and recently closed.

eloquence commented 2 years ago

I don't think this feature is sufficiently "baked" to be the default. I would kindly request a revert rather than a preference down the road.

As others have noted, this is especially confusing during work such as backlog grooming sessions, where the whole point of the exercise is often to close out old issues. Slack will now suddenly display a bunch of old issues - sometimes created by folks no longer involved with a project - as "newly created". This is very confusing and disorienting, and that's not just a matter of "who moved my cheese / getting used to it" -- it's a fundamental UX problem with the way this feature is designed right now.

For this to be the default, the creation of new threads needs to IMO be more carefully thought through.

We've had folks on our team switch from Slack integration to email to get usable notifications again, and this is after days of everyone giving the feature the benefit of the doubt.

psifertex commented 2 years ago

Unfortunately other than the proposed fix of highlighting (which is good!) I haven't seen any indications from GH that their future plans will actually address the majority of the issues raised so I'm chiming in as well to request a different solution (preferably a quick revert and re-evaluation and better testing with other teams).

I can live with the stressful, space-wasting buttons. They're not great but sure.

The absolute confusion being caused by messages showing up that have nothing to do with what actually just happened is an absolute deal breaker. It's enough to want to turn off the integration and subscribe to RSS or some other work-around. It's actively harming our ability to get work done and causing misunderstandings about even little items such as which of our team members are active (a teammate on vacation popped up due to this and multiple people thought he was back and active when of course it was just this new, broken behavior).

koic commented 2 years ago

First of all, I would like to thank the people involved in Slack for their efforts.

There's been some discussion about it already,I expect issue comment notifications to flow from the Slack-GitHub integration. Not stock to thread of Slack. After this change, I often miss notifications for GitHub issue comments. I think the most important thing in Slack is news flows and I can find non-news issue comments on GitHub. In other words, the roles expected of both tools are different.

Currently, a low-hanging fruit notification tool from GitHub is email. I would be happy to at least opt out of the new integration behavior. Thank you.

dylanparry commented 2 years ago

This is a horrible change that has more or less made the bot useless for my organisation. If I've subscribed to comments, then I expect comments to be posted directly to the channel and not to a thread that is hidden away never to be seen again. I shouldn't have to set up separate channels for new issues and comments just to be able to see them both.

Edit: Looks like having separate channels for new issues and new comments doesn't even work. The channel for new comments threads them there too, thus hiding them away so our team don't see them.

pombredanne commented 2 years ago

The new use of threads for issue comments makes the whole Slack integration utterly useless forcing context switches and providing context- and content- free channel notifications when there is a new issue comment. Using threads should be an opt-in not something you should be forced to use as Slack threads have their share (a big share) of issues out of the box.

klovskim commented 2 years ago

I am assigned on over 2000 issues within my organization, my slack notifications have become absolutely overwhelming. The only solution I have found is to remove myself from all issues as an assignee, which is less than ideal. Before I did this I was being pinged by the github integration roughly every 15 minutes. Not to pile on, but this is absolutely productivity-tanking.

ashokirla commented 2 years ago

Hi 👋 ,

We apologise for the inconvenience. We are working at a brisk pace to provide the support to publish the comment notifications to channel. Hoping to extend this feature by the end of this week.

Thanks 🙏

ChrisAshworth commented 2 years ago

Hi @ashokirla,

Since there has been much discussion on this issue I wanted to highlight a detail that may have been lost, which is that at least in our case, posting comments to the channel is not a resolution to what is causing our problems.

One of the (big) sources of noise we are encountering is the fact that the integration must generate a new thread to post to, which in the case of closing old issues means that closing any old issue results in:

This is why, for our organization, we would prefer to fully turn off the threading feature entirely; it worked well for us before, and it does not work well for us now, in a way that is unrelated to whether comments are posted to the channel. (We have not been using the feature to post comments to the channel, so bringing that ability back does not affect the usability of the new integration for us.)

P.S.: Also, these (comment)(edit)(close) buttons, ack! The only thing they do for us is give us big bright noise we need to ignore and hopefully not press!

pombredanne commented 2 years ago

@ChrisAshworth you wrote:

we would prefer to fully turn off the threading feature entirely;

I second that.

and re:

Also, these (comment)(edit)(close) buttons, ack! The only thing they do for us is give us big bright noise we need to ignore and hopefully not press!

Ditto. This is also more than annoying. This also using a lot of vertical space that further pollutes a channel. This should be optional.

@ashokirla Can I suggest that you outline and document exactly what is the direction you are taking? It feels like you will not resolve much of the concerns expressed so far. It would be good to know ASAP.

One alternative would be to go back to using webhooks instead for a quick return to sanity? At the moment the combo of Slack + this Github app is a net negative and a serious productivity drag.

pombredanne commented 2 years ago

I can confirm that dropping using this app entirely and using a webhook instead is a workaround that brings back proper control. If you have many repos and channels that's going to be quite a bit of work to setup of course.

dylanparry commented 2 years ago

I can confirm that dropping using this app entirely and using a webhook instead is a workaround that brings back proper control. If you have many repos and channels that's going to be quite a bit of work to setup of course.

@pombredanne A bit off-topic, but do you have a link to somewhere that explains how to do this?

pombredanne commented 2 years ago

@dylanparry a workaround to a regression would not be off topic in my book:

  1. on the slack side, go to "manage apps"
  2. select custom integration. Ignore this mumbo jumbo: "We recommend replacing your custom integrations with Slack apps, which have more features and use the latest APIs. Learn more about switching to Slack apps.". duh.
  3. select "Incoming WebHooks", then "add to slack"
  4. In "choose a channel" enter the channel you want to have notifications posted, then "Add Incoming WebHooks integration"
  5. Copy the webook URL ... e.g., "https://hooks.slack.com/services/T03Hxxxxxxxxxxxxxxxxxxx"
  6. On the Github side, go to a project "Settings"
  7. Select "Webhooks" then "Add webhook"
  8. In the "Payload URL" field paste the webhook URL from 5.
  9. Select "Content Type" as application/json
  10. Select which GH events you want to broadcast (defaults is just push)
  11. Click "Add webhook"

Done, now you can get back to work!

pombredanne commented 2 years ago

@dylanparry FWIW, it used to be the way before this app existed. This app was a nice improvement over this for a while before it started to regress.

dylanparry commented 2 years ago

@pombredanne cheers. Yes, I totally agree, it's become useless for productivity now.

marcpalmer commented 2 years ago

I too am unhappy with this change.

This is because it totally breaks the usefulness of Slacks "Threads" pseudo-channel where I regularly return to see what others have said on threads that I am involved with.

This is now constantly spammed by Github issues and it has become impossible to find conversations that actually involve me / that I want to return to.

dylanparry commented 2 years ago

@pombredanne

I can't get the instructions you posted to work. I just get an error 400 (missing text) in GitHub's list of recent deliveries for the webhook I've set up :confused:

joepestro commented 2 years ago

@pombredanne @dylanparry looks like slack's incoming webhook is looking for text in the JSON payload, which isn't something that's sent by this github webhook.

ashokirla commented 2 years ago

Hi all 👋 ,

We have now added support to also broadcast the comment notifications for issues to channel if you choose to. This support is now live.

If you have subscribed for comment notifications, and you also want the channel members to see the comments instead of just those who are participants of the issue, you can opt-in for the same by running /github subscribe org/repo comments:"channel"

This will give you the exact experience you previously had and in addition you will get more context if you look into the thread.

Note: By default comment will only flow into the thread. And you need to explicitly run the above command to ensure the comments also start flowing into channel as well.

We apologise for any inconvenience caused with this change. We are trying to improve the customer experience by constantly innovating ourselves. All these years GitHub app is just a post master which brings you information to Slack. We believe threading and inplace create/comment/close functionality is going to enhance our GitHub app to be a multiplayer and a true bidirectional app. We understand that it is difficult for you to adopt to the new way for collaboration. This comments:channel feature is going to help you choose to stay where you are and or tryout the new way.

Thanks :pray:

psifertex commented 2 years ago

"Exact same experience". So this means we won't be spammed by older messages being recreated? That doesn't sound like it's the case based on the description but maybe I misunderstand.

To be clear: if a new comment happens and I am subscribed with this new setting, will I also see an extra message making it look like the issue was created when it wasn't in fact just created?

ashokirla commented 2 years ago

To be clear: if a new comment happens and I am subscribed with this new setting, will I also see an extra message making it look like the issue was created when it wasn't in fact just created?

This happens only for initial cases because we put most of meta-data only in the parent card so that your other notifications remain simple. And any notification comment/close needs a parent card. In your case, since we dont have a parent card, we are constructing that for you. Unfortunately, slack also considers as a new notification. However, if you see the title, it doesn't say 'new issue created', instead it says 'issue created'. Please bear with us on this. This only happens once for issue that is already created. Later on for that issue and for newly created issues, you will not face this problem.

dylanparry commented 2 years ago

It's better, but it's still not great. We need a way to disable threads altogether. I don't want to be pinged by Slack every time someone comments on an issue that I've been involved in.

ashokirla commented 2 years ago

Regarding mentions, this is not a new feature. We are @ mentioning you in the same places where you were previously mentioned.

If you are a participant in an issue, by going to threads section, you will get the full picture and you can directly take action from there. This is a very powerful feature which ensures, you dont miss out on any issues that need your attention. If you have issues where you are mentioned but you dont want to participate and think it is a noise, I question the scenario in the first place.

Having said that, if you absolutely believe that you dont need to see issues/PR updates in threads and think it is a noise, I can suggest a quick workaround that will ensure you get an experience exactly what you had previously (i.e. no more pings).

Our GitHub app only mentions you in the Slack workspace where you logged into GitHub the latest. You can go to a least used slack workspace or personal slack workspace and log into GitHub with our GitHub app from there. Then you will not be pinged or see updates in threads in the other main workspace.

Meanwhile we will monitor the feedback and see if we should give an option to turn off mentions.

Thanks 🙏

Takazudo commented 2 years ago

Thank you for the great jobs! Let me tell you how I feel. I hope you can take this as an opinion.

As for me, I don't use slack threading. I use threading only when the two topics of talks are occured at once. Because it's too complicated. I understand that threading is a nice feature. But not for me.

I just want to handle slack channels as a single thread feed. I switch the channels to check people's comment, issue updates. Threading brings one layer deeper architecture to the world.

I know many people use the threading of course. And I know this is not the place about discussion about slack's threading feature.

I feel I need a option that we can turn off the threading feature. I think there are many people like me.

kannokanno commented 2 years ago

Thanks for this update. It's gotten a lot better, but I still don't feel like I'm good enough. It would be nice to be able to turn threads off completely

I will present one use case. Before this thread support, we sometimes created our own threads against notifications.

It's noisy if you commenting on issues, but if you want to communicate a little. For example: "I'd like to have a web conference about this matter, is this the right time?"

This new feature makes it difficult to convey such trifles. This is because it pollutes the thread, and after commenting on the thread it is pinged.

As an aside, the size of your team will determine whether or not threads work well in the first place. I don't think threads are always effective.

Thanks.

pombredanne commented 2 years ago

I can't get the instructions you posted to work. I just get an error 400 (missing text) in GitHub's list of recent deliveries for the webhook I've set up confused

@dylanparry these are working for me alright. I am getting all notifications delivered correctly with webhook :|

combinatorial commented 2 years ago

While the latest changes surface comments it continues to break the threads feature of Slack for how I use it. I used to use Threads to track important ongoing conversations with co-workers. Github now dominates Threads and I can no longer find the conversations that matter. To find github issues that matter I use the github website and filter issues by milestone/project label etc. We feed comments to slack to enable quick scanning and getting an overview of what's going on. The threading of an issue in Slack has no value to our team.

pombredanne commented 2 years ago

In https://github.com/integrations/slack/issues/1500#issuecomment-1293622938 @ashokirla scripsit:

Regarding mentions, this is not a new feature. We are @ mentioning you in the same places where you were previously mentioned.

If you are a participant in an issue, by going to threads section, you will get the full picture and you can directly take action from there. This is a very powerful feature which ensures, you dont miss out on any issues that need your attention. If you have issues where you are mentioned but you dont want to participate and think it is a noise, I question the scenario in the first place.

This is making assumptions about a certain behaviour and workflow and that organization of this integration are looking for more than a notification of events. This does not seem to match well the reality of the users reporting their problems here. Hijacking slack threads happens to be intrusive and spam-like noise in most cases.

Having said that, if you absolutely believe that you dont need to see issues/PR updates in threads and think it is a noise, I can suggest a quick workaround that will ensure you get an experience exactly what you had previously (i.e. no more pings).

Our GitHub app only mentions you in the Slack workspace where you logged into GitHub the latest. You can go to a least used slack workspace or personal slack workspace and log into GitHub with our GitHub app from there. Then you will not be pinged or see updates in threads in the other main workspace.

The workaround suggested looks an extremely complicated thing. This is making assumptions about the availability of multiple slack workspaces and various level of login which may or may not exist in practice. I cannot fathom how I could even start to suggest seriously to every user in a company to attempt doing such a thing in practice.

The point is that the introduced threading feature generates spam-like noise and destroys the usability of this tool, wasting a lot of time for many people. And we are several here that care enough to spend some of our time to help here and provide feedback.

Could it be possible to publish the source code of this integration? We could help fix the issues.