- there are ways to moderate.
Cool; I wasn't aware of this, this must be a recent change. Specifically, "remove someone from a channel" was not there the last time I looked into this. And "slack has poor mod tools" is a thing people often say. I'm sorry that my understanding was out of date here.
Can you explain how they are in conflict?
If nobody is required to use those channels, then we can't be sure that they're properly staffed and supported. In order to support them, we need to mandate at least some people be in them at all times, like for example, the mod team. And if we want to truly provide good support, then we need to have some degree of knowledgeable people around to answer questions, etc. So, unless this just happens organically, which it might, then it's still going to be a burden. I'm not saying that this is impossible by any means, but "officially supported" and "don't worry you don't need to be there" seem pretty clearly at-odds.
It's not about which technology we personally like more, but about how welcoming we are as a community.
What really always rubs me the wrong way in these discussions is that the people who prefer Slack always assume that it's inherently more welcoming, and it comes across as extremely condescending. You're not exactly doing that here, but stuff like
More recent chat platforms like gitter and Slack have filled in the usability gap, and are now preferred over IRC.
is toeing the line. that's one of the reasons why it's so heated. "People like it more" is just repeated over and over again, against any criticism. You aren't doing this yet, but it's something I fear from this thread. I just had yet another conversation today with someone else who really doesn't like Slack. It's not as straightforwardly better or universally a slam-dunk as it's often presented.
The reality is, adding more and more official channels is going to fragment the community. Unless you're going to try to mandate that nobody continue to use the existing ones... and while you say you're not, at the same time,
At the same time, core developers spend a fair amount of time discussing issues on IRC, so it's an essential place to participate if you want to be deeply involved in the project. By requiring people to use IRC, we're creating an boundary between the Rust community and potential contributors.
So, which is it? Are we going to make all core development happen over Slack to erase the boundary we've artificially created by adding a Slack? Or are we going to perpetuate "oh the real work goes on on this hard thing, all the easy beginner stuff is for the easy thing."? This is tough.
If we're not going to fully move over to Slack, then this split is a serious drawback, and isn't really addressed in the drawbacks section. The reply to this in the drawbacks section is pretty much just saying "well it happens".
FWIW, I think much of the drawbacks could be negated here by making the unofficial Slack, like was originally proposed in the pre-RFC. In the alternatives section,
The drawback of this approach is that if we don't promote them how will the users they're intended to reach out to find them and how will the sense of equality we want to reach be fostered?
We do already link to unofficial things, /r/rust is linked to on https://www.rust-lang.org/en-US/community.html, for example. An unofficial Slack could go there as well.
Furthermore, there are a number of alternatives that are not at all discussed in this RFC: Why not Mattermost? Discord? Riot.im? Zulip? All of these provide an "easier interface than IRC" but change several other variations of the equation; some have extra features, some are open source, some are self-hosted and others are cloud services, etc.
To end on a bit of a positive note, since I've been almost entirely negative:
If our goal is to create a warm, welcoming community, then part of that work means working with technologies that are more familiar and comfortable to this potential community.
I do agree with this in principle, and don't think that we should inherently always stay with exactly what we have. The motivation here is good. I'm just extremely skeptical of the RFC as-written.