+1 for Zulip.
Matrix seemed like a good idea. I wanted to like it. But the constant friction has slowly eroded that goodwill for me. I am ready to try something new.
With an open-source system, that has SSO, and where public backups are available, we can move hosts in case something bad happens. That replaces some of the interesting aspects of federation.
The main downside is for those who live in the Terminal and use WeeChat. I don’t know if there is a good solution for them.
Well the nice thing is that fixing weechat-matrix is probably harder than having weechat-zulip IMHO.
Of course, there’s a big elephant in the room: threaded discussion in IRC are just simply not a thing, they are mostly channels but Zulip has metachannels and channels.
I think people living in their Terminal (like me) are probably better served with the official Zulip terminal client: GitHub - zulip/zulip-terminal: Official Zulip terminal client. (didn’t try, not an endorse)
I am one of these people; I only created my Matrix account to be more closely connected with other people working on Nix.
And I really don’t mind creating another account for Zulip. That’s what I have a password manager for.
I’d say let’s try it.
Generally against this. I don’t think it matters what we use. IRC worked, Matrix works, Zulip would also work, and so would pretty much anything else. Sure there are some differences, but nothing major, they all get the job done.
But switching this is really expensive in so many ways:
I don’t think the Nix community has enough resources to go for that right now. There’s a million problems with the Nix ecosystem, and Matrix is on that list, but it’s far down the list imo. I’d rather people spend their time on more important things.
I mean, for people working daily in nixpkgs with Matrix, they don’t really get the job done in the same way IME. The amount of issues encountered is on a completely different scale for the last months we have been implementing this decision.
Absolutely agreed, but, I dare to say that the cost of switching is important to compare with the cost of not switching and letting the experience be as-is without any recourse for contributors who workarounds every day and every time and then with Matrix deficiencies.
As you proceed to list, I would also list:
That’s one time cost.
Correct, but, as everyone is learning and relearning how to improve workarounds in the Matrix world as Matrix experience slowly degrades along with the announces of “here’s sliding sync, you will never have to wait again in a channel”, etc.
That’s an interesting one, since we switched to Matrix, I lost at least 6 or 7 times my DMs with fellow contributors because Matrix is not able to fulfill this feature alas. Losing more and more history is happening on a larger scale anyway and expecting people to save their own history actively against Matrix woes (or asking them to run the Electron desktop application to workaround application bugs) shows the absurdity of the situation.
Furthermore, no one has bothered building a proper log viewer for our chat history, like we had one for IRC, and the Matrix archive viewer is… suboptimal.
Plus, search usually doesn’t work in Element.
So… well, do we even have history in this project beyond people joining our NixOS space and all the channels via weechat-matrix… ?
Correct, some people even switched back to IRC after a while, some people stayed in both but are more active over IRC. The question about whether it is important to please people who doesn’t think that Nix is important enough is an interesting one though.
In this discussion, I have been focusing the angle on working daily in Nix, I agree this is a tough one because I would like to have all the nice things: have the people who just want to hang around in Nix, people who want to get support on Nix, people who work sometimes on Nix, people who work daily on Nix. But the reality is that this current situation is possible because people can tolerate a certain level of problems of a platform.
As this level of problem is increasing, the need for a solution is increasing. I don’t think it’s a good idea to not discuss the elephant in the room w.r.t. to our chat collaboration platform.
People have been explicitly saying no to join the platform but still contributing and this deprives us from ways to collaborate efficiently, increasing friction in the GitHub platform for no reason.
We can ignore that problem and say this is their problem of not joining the Matrix or that it should not give raise to friction, but the reality is that there are contributors for whom we cannot go down in a synchronous platform, have a chat with, solve problems quickly and move on to async on GitHub.
Maybe this problem is too small to care about? I don’t know, but I definitely see that having no solution is forcing people to find their own solutions and it appears to me that fragmentation is happening nevertheless.
Well, here’s the thing, I don’t think we need to all agree on that, the Matrix switch was done in a hurry and was authoritative: hey, let’s go over there. No one was consulted, we just all hurried over and said meh OK. No offense to the folks who made the decision, they tried too.
Today, there’s no reason to re-question this as the situation is not-so-good without any clear plan in the future to address it.
I politely disagree, I think caring about the well-being, the comfort and the efficiency of the tools that everyone uses on a daily basis is extremely important and is structural for tackling the bazillions of the other problems and this is especially important given that people spent an absurd amount of time in this platform doing those more important things.
Again, we can say that we don’t care about this problem, but it only means that people will find their own solutions at some point. My belief is that not addressing this (that could be: OK, here’s our strategy, let’s not move for now, let’s evaluate X or Y) will probably force us to address at an inconvenient time as it is with all the things that are basically growing unsatisfaction with working conditions for a group of people.
And to be frank, I have been bottling up this feeling about how Matrix was broken for at least a good year, a lot of fellow contributors know how I am tired of Matrix, and I have spent all my time every moment I could discussing with Matrix folks to see what can be done and what can be hoped. At some point, we also have to cut on losses and move on.
Maybe it does not mean moving all the community, I don’t know, hence this discussion.
I think given that other people seems to be echoing some sentiment about the frustration, I would say this is not such a “far down the list” problem, in my personal opinion.
Also, I think that @delroth raised interesting points on how to lean more on GitHub, I don’t think they are wrong, I just don’t know what are our realistic options over there, increasing our reliance on GitHub has always been frowned upon, I like the idea of redundancy and having copies of our data / stuff over two platforms at least, but maybe this is the right direction to go.
Let me also add an interesting thing I have seen recently in Decision Making 2.0! (1.0.1?) - #23 by matklad — the sheer list of potential place for discussion in the Rust community.
I would say historically the Rust project tried to organize “one true venue”, but that didn’t pan out, the current state is more of a product of accidental historical factors, rather than intelligent design (some may recall that Rust move off to discord off the IRC, but then it somehow end up using Zulip. Today, I also feel that the internals discourse isn’t really any more “the place that matters”, but there wasn’t an official deprecation).
A bit of a meta point on decision-making. In a decentralized system like ours, we all get to pick our own priorities. That’s how we vote where the system should go. Something important to one is nothing to the other. Of course, here, changing the chat affects everybody, so there is that to consider. But in general, I’d rather we encourage and unblock motivated actors.
I know it’s a bit unsettling; it’s like a sea of contributions on which we don’t have much control. But looking at myself, I am much more effective when I work on the things I am passionate about. Assuming this is true for everybody, even if we don’t work on the top priority, the more people we unblock, the more throughput we get from the system. Plus, the project is going to be more fun like that.
Anyways, that’s the model I have in mind. End of side point 
This breaks down when you start requiring others to take action to follow your changes, though. Then you’re also impacting other people’s priorities by requiring unwanted work from them. I think this change qualifies, by requiring significant workflow changes from a large part of the developer community.
I’m not saying there’s no place for such disruptive changes, but I don’t see how they’re compatible with a decentralized decision making, and I also don’t think they’re an individual decision like you’re implying.
Zulip is fascinating. It’s good at really structured discussion, in a way that none of the other real-time/synchronous platforms manage. The view lets you follow multiple threads and see current/recent updates across several conversations in an organised way, without lots of switching between channels and display navigation.
It’s great if you’re really immersed in a number of topics, and understand both how the tool works and how the community working in it organises the topics. It’s possibly better to catch up after a short time (like, overnight) on active conversations of interest. It can be overwhelming after a longer period, but perhaps that’s in part because the structure lets you see just how much you missed, rather than just having had it all scroll past never to be missed.
That same sense of overwhelming complexity is the initial experience for new users, and can be persistent for casual, and otherwise less technical or less entrenched users even if they get past the first hurdle. It really can be too much structure. I like it, but it’s very selective for a particular type of personality and purpose. If we’re going to use it, we need to be rather more intentional about how that structure is used (especially for anything “official” or binding that needs to be referenced later).
Therefore I think it’s a valid question as to where we think that structure belongs. As per some previous comments, is it actually better in github? Because I think trying to replicate that structure in several places would be a mistake, and perhaps a more ephemeral and loosely-structured chat is better as a complementary medium. Because otherwise we wind up with more platforms and more problems, not less.
This seems like it would be easy to mitigate, if we wanted to, by having a stream or two for casuals that was unstructured by convention. It’s not like Zulip forces you to make topic threads for every sub-conversation; if there’s only one topic in a stream, posts go to that topic by default.
Just have all new users dumped into the casual streams, the ones who are already Zulip-aware or are comfortable experimenting can join the other streams, and you have the best of both worlds, right?
Never tried Zulip, but I’m on the verge of ditching element
/matrix, it is completely insufferable. ~+1
Discourse has a chat plugin these days. Can we try that out and see if we can consolidate on Discourse?
The big value of Matrix, IMO, is that it’s federated. Zulip is a silo. On Matrix, somebody who’s just a bit interested in NixOS can keep up with one or two NixOS Matrix channels, or we can talk to some expert who’s not part of the NixOS community, and maybe bring them into a discussion temporarily, without having them go through the process of creating a whole new chat account, which they’re likely to be very reluctant to do. Matrix has enough critical mass at this point that people who work on free software are quite likely to have a Matrix account already.
On a more personal level, I’m able to effectively keep up with hundreds of Matrix rooms using weechat-matrix. I don’t expect I’d be able to do nearly as well using the Zulip website, and I expect not being able to do that would substantially reduce my ability to be involved in the community.
-1 from me.
This is always going to be the case. You’re never going to find a solution everybody is happy with. There were people who we couldn’t chat with because they didn’t want to use IRC, and there are people we now can’t chat with because they don’t want to use Matrix, and there will be people you can’t chat with because they don’t want to use Zulip.
Matrix has so far worked pretty well, in that it’s been good enough that people have mostly been willing to tolerate it even if they don’t like it (which was not the case with IRC), and that’s the important thing if what you’re optimising for is being able to talk to as many people as possible.
I stand corrected - thanks! Must have confused that with the channel notifications or so; this faulty memory came from a rather low-traffic instance
One of the main ways NixOS attracts new developers, and why we have so many drive-by contributions from a large community is because all our work is on one central platform that has a lot of reach, where the barrier to entry is extremely low - namely github. I think how easy it is to join the development channels has a similar effect.
Cross-pollination between open source environments is already happening a lot around the matrix rooms. But also the other way, nixpkgs maintainers can easily contact upstreams that are available on matrix, much like you used to do on freenode when everyone were there.
More casual contributors who might be in a different “main” community are easier to reach.
I don’t think we should be downplaying these network effects. If nixpkgs development would be on zulip, I would open that as I sit down specifically to work on nixpkgs, vs how I now get live notifications in a client I have to keep open for a lot of the other communities I’m already in. I’m sure a lot of people are in similar boats.
I understand the complaints, and agree with most of them: threads suck, there really should be a way to block them on a room level.
But maybe the solution here is to explicitly ban them, make a bot to enforce this if we cant disable them on the room levels.
Stuck notifications suck (but are related to threading)
The old mobile clients are terrible laggy messes that don’t at all scale with the amount of rooms people are in. ElementX is only worth using because for a lot of users the tradeoff of the app not being laggy is a bigger feature on the go than all the other things it misses out on.
Delivering notifications to android phones is a real pain when you have to wake the apps up to decrypt and so on.
Zulip threading is really cool and a nice way of creating these ephemeral rooms in a broader context.
But ultimately I think these issues don’t outweigh the benefits of us operating on matrix.
I’ve used matrix for a number of years now, and helped graham a lot through the hasty migration from freenode that happened. So I have a few tips for people with similar problems to Raito here (which many of you might have tried in vain - but which I’ll document anyways):
Thank you for all the reactions, it is very helpful and I can say that even though I see support for Zulip, I take very seriously the fragmentation problematic and I am considering if there is a way to get both worlds and what is the development cost to go through this to avoid leaving anyone behind.
As immediate next steps I would like to explore and invite people to explore on the matter:
While discussing with people offline, I have been made aware rightly so that moving from platforms to platforms will not necessarily solve the inherent problem of what we actually want.
For example, if we had a Phacility - Phabricator which integrated everything, we could have sidestepped some of the issues.
I think it’s interesting to frame the discussion in terms of “what are the problems we want to solve for our contribution workflow”. For me, as a contributor, I feel like sometimes I would like to consume the platform in a project management style, but GitHub has not been very practical for this. Zulip constituted a clear improvement for this based on my own experience in other projects, but maybe, what is needed is a third platform for project management?
I agree with a lot of your points but on this one I strongly cannot find myself in. I am very active in Matrix and IRC and… most of the community I work with, which are not NixOS, are on… IRC.
And much more that I am hiding because it would be too long, so it’s probably related to my own interests and subcommunities, but I think the cross-pollination thingie is a myth or a thing local to certain interests.
No matter what we do, I will always be forced to have all the chat collaboration platform because this is how it is and I definitely notice which one is hurtful to me on a daily basis vs. the others.
For me it’s about 50-50, but the point here is that with both IRC and Matrix, you get network effects when multiple projects use the same thing, same account, etc., and with Zulip you don’t.
I agree with a lot of your points but on this one I strongly cannot find myself in. I am very active in Matrix and IRC and… most of the community I work with, which are not NixOS, are on… IRC.
That’s fine, different people have different community groupings which make different platform choices. Im aware a lot of upstream “types” which are on slack or even discord as well. Or gitter, which is just matrix now
I use IRC through matrix, and many of the rooms in that list at available on matrix as well.
I have seen many people from my communities at least spill over to nixos rooms, through this.
FWIW I believe zulip has shipped their own matrix bridge for a few years, it might be worth looking into for your exploration of the problem space
