aero31aero

Interesting part about Zulip is it is really amazing for less frequent users. I usually come back to 3000+ unread messages and catch up on all conversations that I find relevant (thanks to stream>topic hierarchy and Recent Topics view).

Also, its trivial to have multiple teams on the same Zulip org, people are just subscribed to different sets of streams. So, say you have two teams: mobile and desktop, for example. You can have streams prefixed with that name:

#mobile-hangout #mobile-issues #mobile-support

OR

#m-hangout #m-issues #m-support

Good conventions for stream naming makes it really natural for multiple mostly isolated teams to exist on the same Zulip org, and share some streams like #announce, #general, etc that everyone is subscribed to.

1. FF 77 on Arch, with ublock origin enabled. I'd still say almost-opaque is a bad idea for text-over-text. Were it an image, an opacity: 0.5+ value would be fine, but text is very distracting even at opacity: 0.8 or so.

2. Maybe that could work. A red underline is fine but the error at the bottom is the biggest thing. Instead of switching between neutral/error state, why don't you experiment with working/neutral state? If the code is fine, show a green tick at the bottom, else just show the error with grey color and a grey icon so it's visible but not attention grabbing. On the other hand, you'd get the advantage of getting people hooked with getting the code back to green. Positive reinforcement.

2.

Good point! When I was new to the Zulip codebase I thought the same but after a while, my views changed. Its a very long model (and file) but very linear and organized, so it doesn't have that usual set of problems for which we have the common wisdom of not having long classes or methods.

Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.

> the topic thing is used by accident

It has been designed to be used with the topics and there is no workflow that allows you to avoid topics. I'm not sure what you mean by using topics by accident.

I think I should clarify some of the stuff you're saying:

1. Zulip has been in development since August 2012 (1 year before Slack was released), so is not trying to be a better Slack.

2. Anyone can host their own Zulip server, and have control for all their data.

3. For anyone wanting to migrate from the hosted instance to on premises (self-install) can easily get an export of all their data that they can directly import into their other instance.

4. This is anecdotal but so far, Zulip's full text search has worked well in finding messages from over an year ago easily.

This is where the topic editing feature comes into play; any user can change the topic of a message sent recently, and if someone posts something in a wrong topic, it can be moved to a different topic.

Also, after a while this paradigm grows on you and by forcing you to think of a relevant title for your conversation, it forces you to have more cohesive conversations in my view.

And, lastly, it is possible to send messages without any topic (it defaults to (no topic)). :)

It might not have been obvious, but for installation, you should use a dedicated machine or virtual machine.

That would mean your concerns regarding /root would be solved automatically.