Where should the compiler team (and perhaps working groups) chat?

compiler
1

Dear compiler folks,

Perhaps many of you have been following the recent discussion around Discord. The basic idea I think we are moving towards is that each team should select a “home” that fits them best. I am starting this thread for us to discuss what chat medium should be the home of the main compiler team (and its working groups, probably) going forward. I have my own opinions about this (which I’ll discuss below) but I wanted to hear from the rest of you.

In terms of procedure, we could just make a choice, but I also think it might be nice to do a “trial run” of the various options. For example, we could move the weekly meeting for N weeks and try out a few different things (I know that my opinions about each platform have been greatly influenced by putting the platform through its paces).

Why not just stick with IRC?

One option is that we just stick with IRC. I don’t think that’s a very good idea though. The bottom line for me is that IRC is not very acccessible for newcomers (or long term folks). In particular, I’ve found that being able to communicate asynchronously is key, since many of us are rarely aligned over timezones. But that requires people to setup a bouncer or some other kind of “advanced” setup (or pay for IRC Cloud). I’m sure all of us have experienced the frustration of seeing someone ask a question in #rustc but then finding that they are not online when you would like to send them the answer. Given the importance of getting people involved, I don’t think IRC is the right choice.

What other platforms might we consider?

The primary question, of course, is: if not IRC, what platform should we use? I’ve tried a lot of them. For the compiler team specifically, I personally prefer Zulip, but I think Discord is also very nice. Here are the main benefits I see:

  • Zulip is a different take on chat platforms: they include threaded conversations. Currently, the NLL working group is the only using Zulip. We love it, but the threads take some getting used to: many folks are a bit confused by Zulip when they first get there, and the mobile app is kind of nonfunctional. But once you get over that, the threads are really helpful for scaling the channel. They make it easier to catch up on what you missed if you’ve been away for a few days. They also encourage less use of privmsg, because it’s easier to retain context when people are talking asynchronously.
    • Pro: threads enable excellent scaling, great markdown support (links, tables, etc)
    • Con: takes getting used to, mobile app needs love (but perhaps we can encourage the devs to fix the bugs!)
  • Discord is a very polished platform. Very easy to use. Great mobile app. They use Rust internally and are keen to have us. There is GitHub integration and everybody is “online all the time”, making it easy to have async conversations. Basically, it Just Works. Also, there are a lot of other Rust folk moving to Discord lately. It’s great to have everyone in one place.
    • Pro: easy to use, people are there, responsive admins
    • Con: markdown support is limited, no threads (see below)

I think it boils down to this. Discord is easier to get up and going and better for newcomers, but Zulip’s threads scale very well. The reason that I lean towards Zulip for the compiler team is that I think we tend to have detailed convesations where it’s useful to be able to keep context over time (e.g., when discussing how to fix a particular bug), and I think that it’s ok to ask a little investment from people to learn how to use it if they’re going to hack on the compiler. An even better option might be to have Zulip with a Discord bridge of some kind.

Another contender is Matrix. I’ve not tried Matrix deeply myself. I like the focus on interoperability but have concerns about performance – it also doesn’t offer threads, of course. Perhaps some people here can speak to its benefits.

2 Likes
2

For me one of the most important factors is being able to participate without creating an account/logging in. The most notable reason for this is that I always use random passwords for all my accounts, and I have no real desire to get that password over to my work computer (where I still want to be available for notifications/discussions) or untrusted locations/computers in general (e.g. university campuses, although less relevant to me now). I also consider necessity to create an account to be a barrier to entry for newbies in general.

Other than that, as long as the app/browser tab is not consuming >100MiB of RAM on idle, anything is fine for me.

Bonus points for chat protocol being open.

Discord gets bonus points for quick and easy to setup voice comms.

EDIT: also, typing random passwords into a phone is a major PITA.

3

Interesting. That probably narrows it down to IRC =) but I do think that's an unusual requirement to me. At least, I kind of like knowing people have reliable nicks.

4

The other thing I was wondering: to what extent does Single Sign On influence your opinion (e.g., the ability to authenticate with your Github login)

5

I've shared a similar sentiment as in this message in the other thread about communications tools, so if you've read my reply to that thread and you've seen enough Zulip advocacy, you can probably safely skip over this post.

I've got some experience using IRC, Discord, Slack, Matrix and Zulip for working with others and I think by far the most suited tool to this is Zulip.

As @nikomatsakis said in the OP, IRC isn't very accessible, it's particularly troublesome to set up a bouncer or pay for IRC Cloud, particularly if you're just thinking about contributing for the first time and haven't used IRC before.

Matrix is a project that I really quite like - conceptually it's a really cool idea, but the execution (at the moment, and it's always getting better) isn't great. I used it for the last year or so until recently and notifications weren't all that reliable, the official homeserver would have some downtime (solvable if Rust hosts an instance, but then Rust needs to host an instance..) and everything just wasn't that polished (much less so than some of the alternatives discussed here).

Slack and Discord are great tools, they're very polished and work reliabily. I have certain reservations with those being proprietary tools, but pragmatism will certainly win in the end if they end up being the best tool for the job. But I think they both suffer from the same issue, and it's not something you really notice until you try an alternative like Zulip - they suffer at scale when trying to collaborate with others - you end up with conversations happening across each other, it ends up being really hard to follow a conversation if each participant replies every thirty minutes and there's lots going on in-between - this results in lots of conversations falling back to private messages where it's easier to have a context of the discussion. I'll go full shill for a second and recommend that you read the Why Zulip? page - they explain this better than I can.

Zulip initially seems very unfamiliar, but once you get used to it, and see the advantages of it, it's very, very nice - I've not found someone (and granted, I'm not really going around asking people) who has been using it for a few weeks who doesn't really like using it.

For example, I was working on a PR recently that, due to a variety of reasons, came together over the course of a few weeks - if that conversation was happening in Discord, there'd be hundreds of messages (at least in the NLL working group :wink:) between the little snippets of conversation relevant to that PR - in Zulip, that's isolated in a single thread, where I can easily browse through it, and as soon as I see a message in that thread, I instantly can recognize the context of the conversation.

I'll wrap up my gushing about Zulip there - if you have reservations, try it out for a few weeks and check out how the NLL working group has been using it.

@nikomatsakis I was speaking with Zulip developers just earlier about some of the feedback that had been shared in the other internals thread about communications tools and they shared the following regarding the mobile app:

The main thing I can offer on that is that we are working on it -- e.g. this summer there are 6 of us working full time on the mobile app. Bug reports (on GitHub or over on #mobile ) are appreciated, though there are certainly also major things we know about and are working on.

The Zulip team are very responsive and are eager to fix issues and add features to make it more suitable to large open source projects, I highly encourage anyone who has a problem with something in Zulip to post on GitHub or to hop over to chat.zulip.org (there's a thread called rust-project in the #feedback and #publicity streams).

1 Like
6

My GitHub (and many other services’) accts’ are also using a random password and I don’t authenticate to them from work computer/mobile/untrusted computers for mostly the same reasons.

What I tend to do instead is create a new keypair for the new device I’m on and spread its public counterparts to devices and services I want to have access to (home server, github, etc). Among the other things, this gives an easy way to revoke access too. If the chat service supported pubkey authentication (alas), that would be ideal for me personally.

The authentication requirement could also be a less of a factor if there was a way to access them over a CLI interface or the service used some sort of open protocol so that an authentication terminating proxy could be implemented. In that case access would be a ssh home away.

7

Ask and ye shall receive: GitHub - mjec/clisiana: A CLI zulip client =)

1 Like
8

I’d be happy with anything that can be rerouted into email and then read asynchronously.
I don’t participate in meetings anyway due to time-zones/schedules and ask questions mostly through GitHub, but it’d be interesting to look through the team’s conversations sometimes.

1 Like
9

I also prefer Zulip or something that has an easy and encouraging way of opening temporary and self contained topics of conversations, in the way Zulip’s threading system works.

It’s impossible to have a huge group working together and all trying to communicate between them at the same time in the same space as it happens in a #general channel. In places like that chatters frequently step on each other all the time. That’s also a very discouraging way to communicate because a lot of messages get lost in the middle of conversations. You don’t know if your message was read and discarded for some reason or was just lost. This happened to me when we used Gitter, I found myself tending to favor private conversations with @nikomatsakis because a lot of times messages were lost and/or threads of conversations or thoughts were lost.

As an ideal chat system, I agree that would be great to have conversations accessible publicly as @nagisa mentions but from my point of view only passively. In order to actively participate and write I’d require login so it’s easier to moderate and easier to know people by real nicks. Anyway, I don’t think such a system exists so unless we want to form an “implement the perfect chat system WG”, I’d stick with what better fits now :). But actually, a WG is not a bad idea for long term :stuck_out_tongue:

2 Likes
10

I’m a bit confused this doesn’t list an assessment of moderation at all.

For example, Zulip has open bugs for basic features of public chats, e.g. blocking/ignoring and is still lacking them.

11

To clarify the scope of what I am thinking: it seems ideal to consolidate the compiler team along with its associated working groups:

  • compiler team
  • WG-NLL
  • WG-traits
  • WG-compiler-performance
  • WG-codegen
  • are there more?

(I think I'd prefer to close down other channels like #rustc or compiler on the Discord and have just one place, but we wouldn't necessarily have to do that right away, and I guess it might make sense to bridge, too, if that is tolerable.)

1 Like
12

A strong point! I confess I assumed Zulip’s moderation facilities were more developed, though I’ve heard this criticism before (I didn’t realize the extent of it). That is certainly a potential problem. It hasn’t really been an issue for our usage thus far, obviously. I wonder if we can encourage them to fix that…

13

It probably doesn't help that Zephyr, the protocol that Zulip is heavilly on, was not designed with moderation in mind. I don't know what Zulip does on the inside, but it certainly would not play ball with their Zephyr integration. (If Zulip becomes A Thing among internals, I'd probably want that integration =p)

If you ask me, the only thing missing from Discord is ephemeral threading, something I dearly miss from Zephyr.

14

I am not affected by the decision in this topic, whatever that will be, but I wanted to share my feelings:) I find it interesting that people want to ‘chat asynchronously’. I think that’s what a forum is. I think a subreddit would work just fine for this purpose. That gives you threaded asynchronous communication, with the possibility of moderation, it is visible by outsiders and it is available on all popular platforms.

15

My 2cents, from a non-T-compiler perspective:

I think it is important that the language team and the compiler teams be able to talk to each other easily because they are unusually co-dependent teams. They even share the same team leader (@nikomatsakis). The lang team currently hangs out in Discord.

This does not mean that the compiler team also needs to be on Discord; perhaps the lang team should move to wherever the compiler team hangs out in. I do however want to advocate in favor of a centralization in communication platforms. It would be much simpler (and inclusive to non-team-members) if we only used Discord (or whatever we pick for chatting) + internals and nothing else.

4 Likes
16

Yes. THIS!

17

I haven’t used Zulip so I can’t comment on it. Between IRC and Discord, I much prefer Discord. It was very easy to set up, I could use the same client across Windows, Linux, and Mac, and I didn’t have to set up a server or something just to get notified when my name was mentioned. I’ll happily move to wherever the rest of the compiler team is but for me personally, persistent history and out-of-the-box notifications are a big deal.

18

I definitely see value in having everybody in one place. But I find Zulip's threading model a sufficiently big step up that I find it somewhat frustrating to use chat platforms without it now.

For example, I find it very hard to keep up with the #design lang channel, and so effectively I don't bother -- same with #rustc on IRC. I suspect it would be easier if that were on Zulip. I was contemplating proposing that the lang team move to Zulip as well. =)

I have definitely considered not using any chat platform at all and just using internals entirely, but I fear that the interface is a bit too heavyweight for that. For example, individual messages are typically many paragraphs, not individual lines, and the spacing and layout reflects that (you can't see nearly as much at once). It just doesn't feel as "inviting" to chat on internals.

3 Likes
19

:frowning:

Since the Discord devs are up for listening to our needs, perhaps we could get them to include the threaded model? (Tho it's a big ask.. cc @steveklabnik)

Personally I wouldn't mind trying Zulip out. Threading could be useful for lang team discussions as well to organize topics better. Another mechanism could also be to make more channels such as #design-impl-Trait, etc.

I'd very much like to retain some chat platform; The immediacy of chatting is pretty useful for me, especially when brainstorming unbaked ideas.

20

It is a huge ask, and not something I'd implement if I were them. The threading model, while awesome, is also what makes Zulip a bit more inaccessable for many folks, and one of the reasons we didn't choose it when we decided to announce Discord.

3 Likes