111–120 of 126 posts
Am I the only one that just can’t stand the way zulip looks? I really don’t understand it myself, since it looks more or less the same as other apps, but my instinctual reaction is still ‘yuck!’.
- The UI looks better the more streams you are subscribed to
- The UI just "works"
I'm still not sure if the UI works because it is not distracting me with good looks ;)
How does it compare to mattermost?
Exactly. We're looking at paying for Slack and mattermost seems to offer most of what Slack does and is something that would be pretty easy to run. It's slick. Well documented and installs nicely in a container. Has anyone here used Mattermost? https://mattermost.com/
Our use case is basic chat features with some integrations for a team of around 40.
We run it in a t2.small instance along with another tool. I only had to manually restart it once, which is fine by me.
A postgres backend and S3 storage is most welcome and makes it very simple to manage.
My only complaint would be that the config file is not included in the postgres database so you need a separate routine for its backup. (If anyone from Mattermost reads this, please just include it in the database)
It could also handle importing multiple emojis for us Hipchat castaways.
Earlier quoted context omitted.
At the bottom of that link[1] you can find instructions on how to send notifications directly from your server, but it involves recompiling the apps (which is hardly Zulip's fault). [1] https://zulip.readthedocs.io/en/latest/production/mobile-pus...
Yes, this was covered under our evaluation, I appreciate it's not your fault. For what it's worth Zulip was at the top of our list when we evaluated hipchat replacements. Happy to look at it again if you ever will have direct notifications.
Earlier quoted context omitted.
You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.
Is this a common workflow? Googling suggests almost religious feelings about this.
It takes a little more work for each contributor but leaves history on master very clean.
Earlier quoted context omitted.
I looked at Zulip vs Mattermost several months ago and, if I recall correctly, this was one of the primary reasons I went with Mattermost. I just wanted something I could spin up in docker on a vps without having to setup anything else (like an email server). Mattermost lets you generate "invite links" that you can just paste in a chat or text message. The other really neat feature was having multiple "teams" on a si…
Hi, I don't know enough about Mattermost to be sure I understand you correctly about 'multiple "teams" on a single server' but you can host multiple organizations (realms in zulip-speak) on a single zulip server https://zulip.readthedocs.io/en/latest/production/multiple-o... edit: link updated to point to official documentation instead of github
From a quick glance, the differences I see are: * In mattermost, different "teams" (or "realms" or "namespaces", whatever) exist on the same server (same url), and a user account that logs in will only see the teams they are assigned to. A single user account can be assigned to multiple teams (they appear on the left, similar to how the slack desktop app shows multiple server connections).
* Zulip requires a different subdomain for each "realm", and it sounds like users have to log into each one separately. It is not clear if the same account is shared between organizations or a user must have separate accounts.
So it sounds like Zulip's approach is separate, isolated "organizations", like slack, just hosted on the same server. Where Mattermost's approach is more like having separate, but integrated teams/groups/namespaces that a single account can be part of.
Earlier quoted context omitted.
Hi, I don't know enough about Mattermost to be sure I understand you correctly about 'multiple "teams" on a single server' but you can host multiple organizations (realms in zulip-speak) on a single zulip server https://zulip.readthedocs.io/en/latest/production/multiple-o... edit: link updated to point to official documentation instead of github
That's neat, I may look at zulip again if I need to setup another server. From a quick glance, the differences I see are: * In mattermost, different "teams" (or "realms" or "namespaces", whatever) exist on the same server (same url), and a user account that logs in will only see the teams they are assigned to. A single user account can be assigned to multiple teams (they appear on the left, similar to how the slack d…
Correct. But Zulip does allow to import settings, profile picture etc from an existing account during signup if the email remains the same.
Earlier quoted context omitted.
Exactly. We're looking at paying for Slack and mattermost seems to offer most of what Slack does and is something that would be pretty easy to run. It's slick. Well documented and installs nicely in a container. Has anyone here used Mattermost? https://mattermost.com/
Have you tried out Zulip? You may find the user experience pretty compelling. It's an entire alternative interface to the slack or IRC-style of chatrooms, and it's OSS and documents how to make it containerized.
Both mattermost and zulip look well worth it for saving quite a bit of money over slack for a fair sized company though.
The responses from people here are really interesting.
Earlier quoted context omitted.
Well, it’s not fewer components regardless how you package it. Running docker compose wasn’t enough to get into a fully configured system to be able to evaluate it even.
Do you remember the problems you ran into? I'm evaluating zulip with the help of the docker container (1.9.0-rc2) at the moment and docker-compose was enough to get it running.
Judging from the zulip.org server it looks like there is a need for a chronological topic decay feature.
Zulip founder here; I'm curious why you think that? Here's our thinking. Topics within a stream are ordered by the time of the most recent message. We keep the complete history, both of messages and topics, because it's useful for search and following up on things. Personally, I regularly reply to a conversation whose last message was a month or more ago to follow up with new information (often after getting there fr…