31–40 of 126 posts
The one good thing about not having an on-prem Slack is communications after your company network goes down.
We (the Recurse Center) have been using Zulip since early 2013, and it is the core of our online community. Zulip is excellent both for small teams (we use it for our team of 7) and big groups - we also run a realm with over 1,000 users posting 10s of thousands of messages monthly. I can't recommend it highly enough.
How do you handle high availability for Zulip? Last I looked that was a problem for it.
I mistakenly assumed there wasn't a paid offering. So it's becoming clear that the only revenue model going forward is open core model.
I also recommend RocketChat https://rocket.chat/
The one good thing about not having an on-prem Slack is communications after your company network goes down.
Earlier quoted context omitted.
I liked that too. But I prefer to hide merge commits using: git shortlog -sn --no-merges
Zulip has a rebase-based development workflow and doesn't use merge commits because in my experience, it produces a much more readable commit history (which is really important for understanding historical changes). We've been very happy with this approach. Some relevant reading on our version control approach for those who might be interested: * https://zulip.readthedocs.io/en/latest/git/overview.html * https://zuli…
Anybody knows why this over rocketchat?
Zulip has a thread based Instant messaging model which helps facilitate multiple different conversations in the same channel without losing track / context. More on their homepage - https://zulipchat.com/
Earlier quoted context omitted.
Zulip has a thread based Instant messaging model which helps facilitate multiple different conversations in the same channel without losing track / context. More on their homepage - https://zulipchat.com/
What is the advantage of threads over just more specific top level channels. e.g. in their example why not #annual-summit-name-tags etc. One immediate thing slack does wrong is it makes channels too hard to make and destroy and leave and join, but if that was fixed... What is the advantage of the nesting?
Earlier quoted context omitted.
Zulip has a rebase-based development workflow and doesn't use merge commits because in my experience, it produces a much more readable commit history (which is really important for understanding historical changes). We've been very happy with this approach. Some relevant reading on our version control approach for those who might be interested: * https://zulip.readthedocs.io/en/latest/git/overview.html * https://zuli…
Doesn't using rebase generally mean you have to rebase on top of master and thus with your local branch you may need to git push --force ?