Pre-RFC — Call for discussion: Opening a new chat collaboration platform

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:

  • What is the extra coordination cost incurred by people not being able / refusing / giving up on dealing with Matrix?
  • What is the amount of frustration caused by Matrix by people working daily?
  • How many notifications lost in Matrix?
  • How many discoverability problem do we create / encounter everyday in our NixOS space because it’s hard to work on things like “building a page of every Matrix channels” or “curating a list of answers for our support channels” because we lost our factoid automation and we are doing everything by hand?

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.

3 Likes

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 :slight_smile:

7 Likes

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.

3 Likes

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.

3 Likes

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

4 Likes

Discourse has a chat plugin these days. Can we try that out and see if we can consolidate on Discourse?

6 Likes

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.

16 Likes

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.

4 Likes
1 Like

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):

  • Make sure you are using online key backup! There should be no reason to lose your DMs!
  • Try use element-web in your normal browser, if you are having issues with electron
  • There are more clients than element:
    • Gomux and and Nheko are great desktop clients
    • Fluffychat is a (in my experience) much less laggy but still feature rich mobile client
  • If you are missing notifications on your phone, use the gplay flavors of element (NOT F-Droid)
    • Or make sure your phone lets element wake up always, this is mostly an aggressive power saver issue unfortunately :frowning:
  • Make sure your homeserver is set up to deal with the load of your rooms
10 Likes

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:

  • Someone will find in themselves to improve and fix https://logs.nixos.dev/ so we can reobtain the lost nice experience we had with GitHub - whitequark/irclogger: Simple and good-looking IRC log viewer. Logger is included. No strings are attached..
  • Someone will find in themselves to explore the channel discoverability issue we have and mentioned in You're invited to talk on Matrix (my proposal is to use a stupid and simple website as a directory of channels).
  • Someone will find in themselves to explore how to make our support channels sustainable: You're invited to talk on Matrix
  • Someone will find in themselves to explore what does it cost to have threads-only or non-threads-only channels: it’s useful to force everyone in a thread or to force everyone not to use thread.
  • I would like to explore using Zulip as maybe a very fancy client to Matrix and maybe write a homeserver implementation baked inside Zulip to make it federated with Matrix in a very simple way as another way to work on nixpkgs as a thought of experiment and maybe I will hack some prototype (in test channels obviously).

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.

1 Like

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.

7 Likes

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

2 Likes

Yeah… When Matrix works. If Matrix works. The network effects don’t mean anything when I simply can’t send to the Fedora channel because Synapse is convinced I’m not in it.

It will take me less time to signup to a Zulip instance, login on my phone, and poke around than I spent filing bugs, sending email support emails, or asking for help with Matrix, in the last two weeks alone.

Even ignoring the technical/UI-bugs with Matrix/Element… I just cannot remotely keep up with nixpkgs, Discourse, even just a handful of the Nix Matrix channels, let alone the exploding number of (new) community projects. Some of you seem to manage it, but I think I believe you have found a way to skip sleep! :sweat_smile: It’s an exciting time, but also overwhelming; I think threads would really help.

As it has come up a couple times now, I really really hope we do not consider consolidating more things into GitHub, ala Discussions. GitHub has memory-holed nixpkgs content and I would hate to reward them for that by making asking the community to increase their footprint by feeding contributions into a dead-end that we don’t control – At the very least the lack of an export makes it a non-starter, for me.)

7 Likes

Right, interestingly for me, the Zulip I mentioned: Lean, Coq, HoTT seems to benefit from a network effect between themselves because it’s very easy to re-import your account from another Zulip to a new, though, it’s still a silo in the end. Zulip does have a concept of cross-realm that is increasingly being used / developed, but it seems to be catered towards “guest users”, “cross realm DMs”, etc. Not that interesting for network effects you are mentioning.

Yes, I was planning to go from there.

I definitely think if we increase any reliance on GitHub, it must come with proper archival process and exports, because as you say, it is increasingly dangerous and we already lost data.

1 Like

I made a Discourse chat room to try it out.

2 Likes