On at-channel Slack etiquette

Tags: #<Tag:0x00007fb380420190> #<Tag:0x00007fb380420050> #<Tag:0x00007fb380d53f28>

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]


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.


  • 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 @here instead of @channel in 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…)


I agree. I would adjust by saying “Reflect on whether the 10th-percentile-in-activity member of the channel is as interested”. I would also adjust by saying “Reflect on whether everyone who might be interested already keeps up on the channel as part of their daily/hourly routine, so no @ is required at all.”

It’s worth noting that there is a massive difference in norms re @channel between DM and DESC (two of the many groups that share our slack world, but perhaps the two most active), probably reflecting a lot of the academic vs. project tendencies that Frossie brought up (and then a lot of amplification by emulation). Those of us who live on the boundary are pretty accustomed to this (and often grumble mostly-good-naturedly about it, and have generally set our per-channel notifications accordingly), but I think this post raises the point that we need some cross-organization communication on these differing norms. I’m not sure how best to accomplish that, but I worry that this thread won’t naturally be seen by a lot of non-DM people (and I have no idea where the norms for groups other than DM and DESC fall on this scale).

Yes that is an excellent point. In high engagement working channels, broadcasts are unnecessary if attention can be assumed.

Yes agreed the DESC situation is definitely a major source of the grumbling I hear. But I think the most useful thing is for DM to discuss and perhaps capture our own norms in the developer guide. Then at least we have something to point to when we discuss these issues with other cultures. I will admit I did not think it necessary initially to write up Focus Friday on the developer guide, but it has been very useful to have an explanation written down that other groups can be pointed to. So perhaps something similar here.

(BTW apologies for failing to remember that this was going to trigger a Slack notification on a Friday even though it was not in the DM Notification category)

1 Like

The concept of teams in Slack was new to me, and it looks like most of time, it’s the team’s attention that is being sought by those who @. To advertise this concept broadly, we may want to at-a-team in a few of the channels where there’s a lot of cross group activities.

1 Like

I think one of the issues with teams is that there is a high bar to make/get them. I think I (e.g.) can’t just do it. I need a slack admin. Is that correct? Could that be changed?

I am sorry, the technical term is a user group, not a team. Yes by default it is admin only though we can open it up.

I am 90+% onboard with this, with the following exceptions:

  • I disagree with no @heres for talks/meetings. I don’t put most talks in my calendar unless they’re for things directly related to my work, but it’s nice to get a ping that something is about to happen so that if I happen to be stuck on something or have a free minute, attending a talk can be a good way to take a break. So removing @here completely would mean that I would miss all of those, instead of most of them.

  • I also prefer @channel to @here for notifications of bugs/outages, because there have been times where I’ve had scripts running on either the RSP or lsst-devl after hours on the east coast, so I wasn’t connected to slack or working at the time, that someone has asked for permission to reset something and my jobs were canceled because I didn’t get the message.

But I agree that there should be absolutely no use of @channel or @here for anything that is not time sensitive.

Fred - would just having a “talk starting in 5 minutes” channel address your first issue?



In fact, that’s even better because I may start getting notified of interesting talks that I don’t even know about now because I’m not in a particular channel. So for my use case that’s a definite improvement.


okay I’m thinking #talk-starting-soon - no reason to shoehorn under a particular top level hierarchy as that defeats the “bulletin board” aspect of it. If nobody yells at me in the next few days I’ll create it next week and post it around.

See Trying out the #talk-starting-soon slack channel