I agree it is hard to find things again, but that's mostly because Slack's search is pretty bad, not because of any inherent properties. It's no easier to find old emails or old IRC messages or even wiki pages.
I agree it is hard to find things again, but that's mostly because Slack's search is pretty bad, not because of any inherent properties. It's no easier to find old emails or old IRC messages or even wiki pages.
But the worst... The worst offender on our team thinks all of their replies must be seen by everyone. So they use the "Also send to #mainthread..." for every message they send. It's almost as if training on async chat is required for some as there's a total disregard for etiquette from some.
The problem is Slack, not your coworker. Slack's threads are conversation killers. Your coworker doesn't want to get siloed into a discussion in a thread with only the people who saw the first message, but Slack encourages that.
Sorry you're mad. Zulip does solve this problem one way.
I'm not mad. And there is an etiquette. I'm not blaming Slack - if you use it with some constructs in mind for how to keep conversations succinct and in their own places for others to easily find and use later - it works out better for all involved. There is value in using a tool in an efficient and repeatable manner that benefits all. This isn't a matter of being right or wrong. There are values in a user base being consistent in how they use a, mostly, unstructured tool - especially in the case of this example.
Unfortunately abusing a feature that's meant for other use cases and is not there to always be used ("Also send to #...") can be used incorrectly, and in this case it is. Everyone who needs to be in the thread is already there. It's just broadcasting to everyone who doesn't need to be the statement they've made.
I don't actually believe Zulip solves this problem, but it does look interesting for a number of other reasons.