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

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.

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

1 Like

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

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

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.

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

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…

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.

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.

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

Yes. THIS!

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.

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

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

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

It's worth noting that the Zulip team are also interested in better supporting open source projects like Rust. Just yesterday, there was a small discussion about this discussion in the Zulip organisation's chat where Tim Abbott, the lead developer of Zulip said:

I should mention that in general we're quite responsive to the needs of open source projects; if folks involved with Rust want to talk to some of the open source projects that have adopted Zulip and been really happy with it, we can set that up.


This would work for things like #design-impl-Trait but would struggle to be as flexible as Zulip's model when it comes to a channel per issue (which is effectively how the NLL working group is using Zulip's threads currently).

It seems like we should talk to them about moderation features like bans.

1 Like

I'm been trying that, but I've not found it particularly satisfying. One of the things I think I like about the threaded model is that they are relatively small and transient -- you can create a new one effortlessly, and once a particular conversation is done, it kind of fades away. Making a new persistent channel is useful, but it's a kind of "decision" to do it, and then you have to "decide" to remove it later on... it just doesn't quite serve the same purpose.

3 Likes

Idea: Maybe the threading model could be opt-in per channel to have our cake and eat it too?

I don’t see us changing any of those products substantially.