Rocket: Community Communication

[sgrif]

Does this crate have a gitter room, slack channel, IRC room, or some other place for the community to communicate and ask questions that are less suited for Github issues? If so, could that be documented in the README? If not, I'd like to advocate for using Gitter over IRC, it's easy to set up and much more approachable for more junior developers (and provides history without the need for bots)

[botev]

At the moment its in IRC #rocket. I personally also agree gitter feels better, but that is probably up to the devs.

[marcusball]

I like the IRC channel, most because the majority of other Rust support and discussion also takes place on IRC. While IRC may not be ideal, I do like the consolidation of the Rust community into one location.

[SergioBenitez]

Indeed, it is #rocket on irc.mozilla.org. I've added this to the README in ef7d18f15afcbc4ea193eff015ae1ec8946ad2e2.

I don't feel strongly for or against Slack or Gitter, but I'm generally opposed to having more than one "chat" place for people to go to. I like IRC - I feel that the problem is really one of clients. I'd hoped to have a simple web client hosted on rocket.rs so that a simple link could be clicked to join. Unfortunately, I didn't find any existing project that met my usability goals for this. (In short, they are: 1 click to join room, maybe with nickname, automatic logs max(~24 hours, 100 lines), constrained to a single network/channel). I'll eventually build/repurpose an existing one that does this as I do feel that joining an IRC channel can be a pain for those unfamiliar.

In the meantime, I'm open to having a gitter/Slack if there is _strong_ support for one.

[sgrif]

It's worth noting that both slack and gitter have an IRC bridge. Gitter's in particular seems to be really good.

The issues with IRC that make it so intimidating aren't really about the client IMO. It's the fact that in order to see any conversation or be contactable you must be online and present at any given point in time. There's no persistent messaging or semi-async communication.

[botev]

Yes I think persistent messaging is much better. Some time I ask something, go to bed and I hear later that smn replied, but I can never see it. Also different people in different time zones might not manage to meet in IRC for this same reason, with gitter/slack you have the option of answering and getting your message there.

[SergioBenitez]

@sgrif But both of those issues are client derived. There's no reason why there can't exist an IRC client with an accompanying service that plays back a log when you sign in and notifies you of mentions while you're away. ZNC gets you most of the way there. IRCCloud gets you the full way there.

I'm proposing a web client that gets you logging when you're gone, but not asynchronous notifications as that would require some kind of registration. This would mean you can ask a question, leave, and come back at any point in time to see if it was answered.

In any case, I am open to alternatives if there is enough demand.

[sgrif]

I'm not arguing that IRC can't do these things, but they are actively more difficult for beginners than something that only requires a github account.

[sebasmagri]

Probably a Telegram group with an IRC bridge bot? Several Mozilla teams use this approach.

[SergioBenitez]

I've thought about this some more today. I'm currently thinking of writing a tiny IRC bot and a tiny Gitter bot that sits in both channels and relays messages from one to the other. Any message sent in gitter will be relayed to #rocket, and any message sent in #rocket will be relayed to gitter. The relay will include the user's nickname on the other service. This makes cross-venue communication possible and simple. I think this resolves all problems. We could even add another service, like Slack, in the future and maintain all of the cross-talk.

The only downside with this approach is that the active user list won't reflect the number of users on both networks, but instead, the number of users on each network individually. This seems okay, and the bot could simply have a way to be queried for the list on the other side.

[cbrewster]

Is there any particular reason to not just use gitter with its IRC bridge?

[SergioBenitez]

I like IRC. Others like IRC. IRC has been around for a very long time, and we can count on it being around for a longer time. It's dependable and distributed. It works _really_ well, for the most part.

Gitter has not been around very long. Will it be around in 5 years? Who knows. It's owned by a single group; if they decide to shut it down, it's gone. To use it over IRC, you need to connect to _another_ network.

[belst]

I'd go with Matrix or IRC over gitter/slack anytime. I do not like closed communication protocols.

Matrix has full chat history and you can setup your room to be guest joinable. + it has nice irc support.

[lholden]

I am a huge fan of IRC. I can't imagine the mozilla IRC server going away any time soon and it's where the #rust channel lives. I don't really see much incentive for Rocket moving off it personally. If the issue is retaining history... that's pretty easy to address. Ex: https://botbot.me/mozilla/rust/ - https://botbot.me/request/

[jansol]

Another vote for Matrix. The entirety of mozilla's IRC network is already accessible via a bridge on matrix.org and having an official Matrix room that bridges to the IRC channel would make it easier to find.

[SergioBenitez]

After exploring the available options, I've decided to go with a Riot/Matrix room which bridges seamlessly to the IRC channel and provides an easy way for guests to join. It also provides free logging. The IRC channel will remain the primary official form of communication with the Matrix channel as secondary.

The README has been updated accordingly. If you feel this is inadequate, please feel free to reopen the issue.