In Slack threads are an annoyance. They lead to missed answers and discussions, because they are rarely used in average user groups. When they are they default to private only for the writer and appear out of the natural flow for the reader.
In zulip every message belongs to a topic. (Well there is the "no topic" topic, but it shouldn't be used and even if it is it appears exactly like every other topic). So no surprises.
I have used slack (and irc and xmpp) for a long time, and Zulip for 2 months. Zulip is certainly much better for the geek.
Slack user experience is somewhat more straight forward for the naive user not caring about things done "right".
For hacker news readers zulip is likely to be the preferred choice. Expect resistence from your non hacker news colleagues / managers / team members.
In busy channels in medium-sized companies, lack of threading is a huge pain: person A says "Hi, I'm trying to do X, how do I do this," person B says "Hi, I'm getting error message Y" 2 minutes later, someone shows up 5 minutes later and says "Have you tried installing this thing" and they were talking to B about solving Y but A tries to install it and use it for X and then everyone is confused and wastes time.
Slack is positioning itself as an email replacement, and to some extent all of these tools are replacing at least some email. Imagine taking 20% of your email and not having subject lines, just authors. What's the "LGTM" for? (Or worse, the sender anticipates that and says "Re @pm at 00:10, agreed" and then you get to track that down.) Or imagine taking your in-person conversations, the ones that you'd eventually want to move to IM to support distributed or remote teammates, and having a rule that you couldn't go up to someone's desk, instead every in-person conversation had to take place at this one water cooler. If multiple people wanted to talk, well, either they can have multiple conversations in front of each other, or they can wait until one conversation is done.
(Slack's implementation of threading, meanwhile, doesn't actually solve the problem that well because of the way it pushes threaded conversations to a side. Imagine email without a reply-all button - it solves some problems and creates so many others. You can and should live without Slack threading.)
... also, another argument that threading matters: you're using a threaded forum right now. Remember phpBB? Would HN be improved by switching to a phpBB-style UI? If you unindented all the comments on this page and sorted them by time, would it be a workable experience?
Why not to use direct messages for the example you gave ? Or even better reply to the message itself which creates semi topic under it ?
Also if you have some specific topic you would like to discuss like k8s or linux there should be specific channels for that in a company.
You can reply to exact message in slack. Ive been using it for over a year in a company hiring few thousend people and we had no issues you describe here...
> Why not to use direct messages for the example you gave ?
Slack sells itself as a searchable archive. Ideally if someone asks the question a second time, they (or someone else) can look up the answer. Direct messages mean conversations don't get publicly logged, which is a serious negative for the company.
> Also if you have some specific topic you would like to discuss like k8s or linux there should be specific channels for that in a company.
My company has three channels for GitLab, Git, and software development / build infrastructure, which sort of seem like overlapping topics already. But even with this split, we regularly have multiple conversations attempting to happen.
Think of, say, JIRA queues vs. tickets. We also have three separate JIRA queues for GitLab, source control, and development tooling, but we still use separate tickets in each queue, not one general-purpose ticket for all GitLab discussions.
It's hard to describe the benefits of this system to someone who's only ever used linear chat (or linear chat with weird thorns sticking out periodically, like Slack). On Zephyr, which is what Zulip was modeled after, I was in chat rooms that created a separate topic for each development issue and each customer support ticket, which made it easy for different groups of people to work on different things and still stay in the public chat room, and also extremely easy to go look up history later. Searching for things related to a ticket or a pull request in Slack is basically impossible.
These problems aren't obvious because people learn to work around them, mostly by avoiding public channels and IMing their friend, talking in person, keeping things in email or an equally high-latency system like JIRA, etc. But they're still problems that a good tool could solve. (Plenty of companies would say, we don't have group chat at all, we're working fine with email and person-to-person IM; probably you'd tell them that having something like Slack would be worth trying.)
"Reply to the message itself" is what Zulip does best, and where Slack is lacking. I have to zoom in to a thread to see what's going on with it, I can't just follow the main room and see the tag for a sub-thread interleaved.
It's a filtered event stream, where you have 2 tags, "chat room" and "topic". You can see the full firehose with both tags, or zoom in to a room and see topic tags, or filter to just the topic if needed. Slack won't give you the first option, and does the second poorly since you can't see the topic responses inline.
It's one of those things that I didn't realized was a big deal until I experienced the alternative -- I just signed up, tried it for less than five minutes, and I'm already sold on this over Slack.
(I'll also add that I recently spent over a year working from home where most of my interactions with other team members was through slack, so I'm fairly experienced there.)
Very differently. Slack does threading on the basis of replies to a message and hides/collapses those under a thread, showing them only to people who expand and notifying only those who are already involved in the thread (by replying to it or being OP)
Zulip's threading is based, more like email, on a Subject which all messages (can) have. Though Zulip subjects are more likely to be one or two words.
In this way threading is tacked on to Slack whereas it is as at the heart of Zulip
Threading in email works via message-ids and references to preceding messages, nothing to do with subjects. That is, except as a workaround for garbage email clients and services too incompetent to use email correctly.
I mean, depends on your MUA in practice. I think by standard for server side threading— https://tools.ietf.org/html/rfc5256 — "base subject" is definitely a valid consideration. I only skimmed though. :-) feel free to extract a spec, I'm curious (but not enough to read 19 pages right now)
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading". The searched messages are sorted by
In other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Yes, the REFERENCES algorithm also uses the base subject--but never to override message-id based threading, only for merging together threads that couldn't be joined using message-ids ... or in other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Well, and for merging together chunks of a thread where you have major gaps in your mailbox, so that reference headers don't overlap enough to make the connection, but the point remains that it's not really a threading mechanism, just a last-ditch attempt to recover a thread where proper threading information is missing, which is fine for corner cases like large gaps in which messages you have in your mailbox, and doesn't change that a sender that doesn't supply reference headers in the first place is incompetent.
