Judging from the griping in my DMs, we don’t have a shared understanding of when to @channel [and the related @here] appropriately (bearing in mind that nothing communication related is ever going to be 100% appropriate under all circumstances but why not try and do better, right?).
Discussion channels
The uncontroversial use of @channel is “This group of people has opted into this channel for a fairly narrow purpose and they all really need a notification interrupt related to that purpose”. So let’s say is a channel for a DM All-Hands meeting. It is appropriate to at-channel to say “Conference Photo has been moved to 4pm to try and beat the rain” because:
- It is time sensitive
- It is something everybody on the channel is reasonably expected to care about
- It is reasonable to assume this is the kind of content people joined the channel for
At the other end is the kind of situation that leads to grousing. A large channel whose membership is “involuntary” or rather de-facto, eg all members of DM. If I at-channel to let people know that tomorrow I will be giving a talk on why all our web pages should support dark-mode, this is bad because it is unlikely that the vast majority of members would be interested in my dark mode evangelism (even it is reasonable to assume that some might enjoy it). Moreover while a seminar is often considered an interrupt in pure academic environments (you don’t want your grad students to miss out on the visiting Nobel prize winner), in project environments it is routine for people to miss talks that they would have been interested in but which conflict with scheduled activities, so even it is of wide interest it is not critical enough to merit a notification. So we have a problem because:
- The channel being atted is not of narrow interest
- The downsides of the announcement being missed are not severe
- There were reasonable alternatives (post the announcement earlier, with a couple of reminders, so it would be on people’s calendars)
Now obviously if we were not talking about all of DM but the #rabid-darkmode-fangirl channel, the calculus is different. That would be a channel of narrow interest, and members might be genuinely crushed to have missed such a talk, and moreover the talk is more likely to convey actionable information of use to its members. Even then I would personally hesitate and think “is the median person on this channel going to be as stoked about this as I am?”
Support channels
Those clear-cut examples aside, I would like to discuss a thornier issue - is it appropriate to at-channel for service outages / status?
This is where specific channel details and norms come into play. For example, #com-square is a channel that my team uses to provide support to summit and commissioning staff. We consider this a high priority support channel and it’s generally very low in extraneous chatter with good threading discipline for discussions. It is a medium sized channel (~40) since there are a lot of stakeholders but at any given time there are only a few “active” customers. There are some circumstances I might at-channel - for example for an upcoming outage that requires people to save their work or else they will lose it. Other times though it is sufficient to just at the active customers, eg. if I am trying to fix a problem that Tiago has reported I would at Tiago to tell him I fixed it even though theoretically it would have affected everyone - because it didn’t. Anybody who has not actively run into it doesn’t need to know that the thing they didn’t know was broken is now fixed.
There is one exception to this however, and it affects a much larger channel. Is it acceptable to ever at-channel #dm-rsp - a big (100+) channel that serves as the support channel for the data facility science platform deployment? On one hand, it is a populous channel and undoubtedly many if not most people are not actively engaged in it at any given time, so it would seem to violate the guidelines in the discussion channel section. However there is an additional consideration in a support channel: when a widely used service is down, the team is often pummeled with notifications on every medium from users reporting a problem - people slack the support channel, they slack the wrong channel, they DM you, they file tickets, they ask on community, in the old days they even walked into your office, imagine that.
In such a situation an aggressive notification serves a wider purpose - stemming the flow. The inconvenience to the people who are notified and didn’t know or care is offset by the benefit to the responding team of reduced channel noise. It’s a hard call to make, and this is a situation where I think it is best to leave it to whoever is coordinating the incident response (typically the team lead) to judge the situation.
I would argue though that in support channel situations @channel is never the right thing to do - even if you want to broadcast you should use @here since anybody who is not actively working is unlikely to be affected by the problem in the first place (that assumes people go inactive when they are not working, which I am not sure how universal that is).
Tangent: we should consider making the support nature of some channels explicit in the naming convention or at the very least the channel topic
Social channels
Surely to god there is never a reason to trigger a notification tsunami on #rubin-observatory-late-night-music-club, right? [plug: actual channel, join us]
Etcetera
It’s worth noting that Slack has a concept of teams [edit: correct term is user groups] that we are underusing. For example @square-team has just the formal members of SQuaRE, and in a channel that is square+friends I would use the team-at to rally people to fill in their timesheets or whatever so if you have a routine need to at a group of people consider making a team.
Also note that at-channel is currently off bounds on Focus Friday per the developer guide.
tl;dr:
- Consider reserving at-channel for time-critical information of high relevance to channels of narrow interest
- Reflect on whether the median member of the channel is as interested in this as you are
- Use
@hereinstead of@channelin support channels - Develop norms in your working/team channels to reduce irritation
DMLT will probably discuss Slack etiquette in the upcoming DMLT meetings so please share your thoughts below and reminder to be excellent to each other.
(PS. Liking this post increases the likelihood of getting my Slack threading screed/installment, but not liking it does not eliminate the possibility…)