9 ms·
Reading through this thread, it seems like Slack is really missing more fine-grained control over channel permissions. There are largely four types of communic
by solatic 9y ago
Reading through this thread, it seems like Slack is really missing more fine-grained control over channel permissions.
There are largely four types of communication and they need four different permission designs:
* Important and immediate - stuff like production monitoring and incident resolution. These channels should typically be quiet but they should have the power to notify and interrupt people doing normal work when activity happens. If you have support channels, they should be staffed by dedicated support people whose primary job is to be interrupted by support requests, and not engineers trying to buckle down on their work.
* Important but not immediate - ordinary corporate alignment discussions. These channels should be globally administratively enforced as read-only except for predefined, enforced "meeting hours" which are blocked out organization-wide on everybody's calendar, which is when discussion on issues actually happens. If people have an issue they need to bring up on a particular topic, it can wait until tomorrow, and not interrupt engineers trying to get their work done. People no longer mute these channels because they're not interrupting them during get-work-done hours. If it's too difficult to follow the "meeting" in a dozen different channels then it's probably a sign that your organization has you in charge of too many responsibilities and you should stop looking at the tool as a means of fixing your organizational problems.
* Not important (and either immediate or not immediately): there's a time and place for watercooler channels, and it's not interrupting you in your cubicle. Notifications should be globally administratively disabled entirely for these channels, for everyone, including the people who care about following along in those channels, because nobody should be standing around the watercooler all day long.
Slack's product teams should be looking at mute as a sign of failure that says "either this tool or this tool's configuration is preventing me from doing my job" and the product team should respond accordingly (remember: tool misconfigurations are an admin UX failure that harms your product by damaging its reputation, and you should fix the UX failure that lead to the misconfiguration so as to protect your product's reputation). The only mute button in Slack should be a Slack-wide mute button for vacation etc.