Well things are hotting up around here, and so are our internal Slack support channels. This post is motivated by some issues we have seen in SQuaRE’s support channels (dm-square, dm-rsp, com-square, dm-squash and dm-docs) but I hope it spark some good discussion, especially since various topics of Slack etiquette are a discussion item at the DMLT quarterly meeting later this week. Like all communication issues, there is no totally right answer and your own channel cultures apply.
Channels that are primarily oriented towards user support are special in a number of ways:
- Hard to follow information and distractions can impede devs trying to help users in an effective and timely manner
- High volume on concurrent issues make it hard for the ad-hoc incident response coordinator to assess status
- (At least in SQuaRE) We try to keep an eye on these channels on a best efforts basis out of office hours, so ongoing conversations on no longer urgent issues can have a disruptive effect.
Of course it is totally reasonable for conversation to start in the main timeline, so to speak, and in support channels this is typically the “is it broken or is it me” phase. This is the lifecycle stage of a problem where having a discussion under many eyes so people can go “me too” or offer peer-to-peer support for common problems, like “is your VPN on?”.
At some point, it becomes obvious that there is an actual problem and one or more devs and/or an incident coordinator need to work it. This is an excellent time to move the conversation to a thread for a number of reasons:
- It clears the main timeline for other problems or important updates
- It creates a huddle among people actively involved in the problem (devs and users) and so it reduces the “peanut gallery” effect.
- It keeps log dumps, sceenshots and other artifacts with a poor column-inches-to-general-interest ratio off the main timeline.
- It reduces the impact of devs who favour “stream of consciousness” troubleshooting on everyone else
- It vastly reduces potential misinformation during the troubleshooting phase (“ALL THE DATA IS GONE” followed by “never mind, I was logged onto the test server”)
Here is the kind of example of things working great:
Did anyone really want that 40 reply exchange (https://app.slack.com/client/T06D204F2/CAS7Y9ADS/details/) in the main channel in which (1) we talked the user through a bunch of things that did not actually fix the problem (2) we eventually figured out that this was not just the user’s problem (3) we speculated erroneously about what could actually be the problem? (4) sprinkled “thinking out loud” between all those steps in the mix?
Instead the timeline stayed clean, making the broadcast announcement (50 minutes later!) easy to spot.
And in fact there was a second level of “threading” where once it because apparent what the issue is, the devs retreated to their team channel to further discuss the issue, to avoid pummeling the user and especially since authentication was involved:
Bottom line: please try and thread screendumps etc, always follow the lead of the incident coordinator if they ask you to thread, keep the main timeline clear for important information and new problem threads.
Other good ideas involve using commonly understood emoticons (
= me too, 
= this is correct, 
“ok”) instead of messages when semantically equivalent to your response.
It’s worth noting that there are now some channels (like auxtel observing) where it is understood that if you are not active summit personnel you are meant to be a quiet observer. Please respect that - we all want to share in the excitement of early images and we don’t want to drive those activities to closed channels by interfering with the “working” staff.
With my SQuaRE hat off, I am personally going to say that even in general channels, once I find people are “talking over” each other or volume has spiked, I personally like to take things to a thread anyway, but that may be the general introvert horror of everyone talking at me at once.
Feel free to discuss threading in general in the comments and share your own team channel cultures on the issue.