81–90 of 153 posts
Earlier quoted context omitted.
"Log in with GitHub" didn't work for me. GitHub asked me to authorize Zulip then nothing happened, I can't login.
You'll want to sign up first, at https://chat.zulip.org/register/ .
The install procedure [1] looks like bad a joke. > You’ll need an Ubuntu system that satisfies the installation requirements. So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supporting only Ubuntu, they could have at least created some deb packages. There is an install script, but no details about what's going on under the hood or explanations of how to do it manually; what…
Claims like these are really off-putting. Is it done for SEO purposes?
Earlier quoted context omitted.
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
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.
The install procedure [1] looks like bad a joke. > You’ll need an Ubuntu system that satisfies the installation requirements. So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supporting only Ubuntu, they could have at least created some deb packages. There is an install script, but no details about what's going on under the hood or explanations of how to do it manually; what…
This comment is a great illustration of why companies and investors prefer software as a service business models wherever possible.
I recently had to test a complex Django-based Document Management System: https://www.mayan-edms.com/
The install was a breeze. Even with very little experience with Docker it took me a matter of minutes to fire up a Digital Ocean droplet, paste in a few commands and have a fully working install.
Every open source web app should have some equivalent that is as simple as this.
Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users. I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything. Does anyone know about any hard limits wit…
Earlier quoted context omitted.
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…
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 descr…
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.)
It's really hard to get a sense of how Zulip works without any screenshots or videos anywhere on zulip.org, just general descriptions like "the world's most productive group chat" and "email threading model." The fastest way to find out how it works is to go to https://chat.zulip.org/accounts/login/ and click "Log in with GitHub". They really need to make that path easier to find.
We're definitely planning to provide a slick explanation on zulipchat.com. Using chat.zulip.org is helpful, especially if you visit a day later and read the message history; since you really only experience Zulip's magic properly when catching up on a bunch of unread messages (the `n` hotkey in particular is super great). That said, https://zulipchat.com/features has a screenshot; and https://twitter.com/b0rk/status/…
Just a quick question... How difficult is it to build, install and run from source? I guess I'm slightly concerned about the "it expects to have the whole machine" in the requirements section. Is that just for your installation scripts, or are there assumptions baked into the server? (Apologies for asking without looking myself!)
Making that build process super easy (if it isn't already) might lower some barriers for the technical crowd (personally I don't like setting up VMs... maybe it's just because I'm old :-) ). Possibly you can leverage more from your free software angle.