New communication channels #1865
Conversation
|
I don't like it. It just splits the community. |
|
It's already hard to deal with the three official communication channels of irlo, git, and irc. Adding another would just be more to deal with. Additionally, slack takes a lot to set up, and requires a log in, as opposed to irc, which is easy to access with mibbit, or a simple downloadable program. It also means relying on another company, as opposed to only relying on Mozilla. |
|
To be clear, this proposal does not require anyone to use Slack or gitter, only to allow people who wish to use those platforms to be able to have a well-supported way of getting help with Rust questions. |
and
are in conflict. |
|
What kinds of moderation tools are available in these chat rooms? Are they comparable to what is available with IRC? (I've never used gitter before, and while I use Slack at work, I've never had to think about moderation.) |
Slack is generally perceived as having poor moderation tools for exactly this reason: it's a chat product for work. The needs are very different than a public chat room. My understanding is that there are basically no tools for moderation at all. |
|
@steveklabnik - there are ways to moderate. See: https://get.slack.help/hc/en-us/articles/201314026-Roles-and-permissions-in-Slack Moderation also came up in the thread. It's something the moderation team would need to explore, but there is at least some support there. Can you explain how they are in conflict? |
|
Maybe some more general points: We're big enough now as a community that it's no longer just a small handful of us answering beginner questions. We're better able now than ever before to support people and support their preferred communication channels. I think @steveklabnik 's feelings are shared by some but my worry here is that it's a way for us to continue to exclude people rather than trying to accommodate. Yes, some of us just don't like Slack and we have our reasons. Some of us love IRC or have grown very fond of it, which is totally understandable. Many of us spend many hours a day there, myself included. None of that, though, addresses the issues being raised. It's not about which technology we personally like more, but about how welcoming we are as a community. In a way, I'm suggesting we look past our own biases and try to accommodate more people and more ways of communicating. |
|
I'm not saying do this or don't, I want to be clear about that up front. However: if you are blind, Slack is almost entirely unusable. I believe this is being worked on, but for the moment this means XMPP or IRC gateways, neither of which are necessarily fully featured and both of which are inconvenient. I know at least one person who had to resort to using the Slack API to get something unavailable to them through these avenues. Gitter was completely inaccessible last time I bothered trying. I doubt this has changed. So, fine. Do this by all means. But if we end up in a situation where I must use them to continue contributing to the compiler, I'm probably out. At least, unless that's after Slack gets their accessibility act together. The one thing about IRC is that it's guaranteed to be accessible, one way or another. |
|
I have no love for IRC as a protocol at all and I agree that our use of it is a real barrier for people, but splitting the community across more official communication channels seems counter-productive. I would much rather see an RFC for creating a beginner's guide to engaging with the Rust IRC community, which could range from just getting connected to IRC social expectations. For an example of the latter, I've seen many new people make the mistake of asking a question and expecting an immediate response, though in reality questions are often answered with much delay during certain times of day and in slower channels like I think with such a guide we would have an easier time advertising the IRC community, by simply pointing people at the friendly guide, and making it more valuable to them, by explaining what to expect. This solves some problems that would exist even if we introduced Slack and gitter channels. FYI, the current advertising we do for the IRC channels here is mostly just a list of mibbit links to the channels that exist. What do y'all think about doing more to ease the introduction to IRC? |
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.
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.
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
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,
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,
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:
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. |
|
Some of the concerns here are thoughtfully expressed & important to address, but some of what I'm seeing feels like a kneejerk response (especially all the thumbs). I can imagine easily that an inverse community, which has only a slack and no IRC channels, might react in exactly the same way to a proposal to add IRC. Who among us would not have been able to contribute to that community? Who today is not able to contribute to ours? I want to challenge the idea that you have a need or even a right to be present in every communication channel that exists around Rust. Ultimately, 'official' actions are taken by git operations rust-lang owned repositories, and that is the only venue you "need" to participate in. My presence in IRC / gitter is fleeting, I don't feel disempowered by that at all. We should be optimizing to cast a wide net, not for having the same people present in every medium. This proposal puts a responsibility & a burden on the community/moderation teams to maintain the slack and gitter, but not on anyone else as far as I'm concerned. And I'll be clear that I don't care much for slack. I even don't care for the narrative I see floating around sometimes that it is 'more accessible' than IRC & keeping to IRC is 'elitist' or 'backwards.' There are people to whom slack is more accessible than IRC, and people to whom it is not. But I wonder also if its necessary for a slack to be 'official.' What exactly does that mean? The key distinction here I think is the question of who is responsible for moderation. The subreddit has succeeded despite being unofficial, with a distinct set of moderators from the Rust project. Also, despite being unofficial, the subreddit is linked both from the website's community page and the rust-lang/rust README. Perhaps the status of the subreddit should be generalized to a 'tier ii communication platform' and the slack should have a similar status. The gitter seems like it should be made official since ownership of it is tied to the repo. |
I've seen users actively request a slack channel several times. I haven't seen users request any of these other services. |
|
From the RFC:
What does this mean? What makes a communication channel "official"? |
|
So I have various thoughts on this, wearing various hats. With my mod hat on, I feel that these communities will have to organically grow moderators. I've tried hanging out in the gitter channel before and it never lasts, even though I like the place. Slack is worse; it eats up RAM. We can help bootstrap, but ultimately you'll need folks who actually want to hang out there. I'm unsure how many members of the team will be able to hang out on Gitter and Slack. Not all members of the current mod team actively hang out on all channels anyway, though we do make decisions together when issues occur. Additionally, there are other mods on these other channels who help handle more mundane isses (spam, blatant stuff, etc), so this wouldn't be a new concept. There's not much work in moderation since incidents are rare (spam, less so), but you have to have the capacity of being around 24/7 (collectively) and catching the more egregious incidents quickly when they happen. The mod team can expand, but I'd prefer it be approached in the opposite way -- identify trusted individuals who seem to like to hang out on the slack/gitter channel, and let them moderate there (possible uplifts into the mod team can happen later if we want) With my community team hat on, I strongly share @steveklabnik's concerns. It's a matter of how much we're actually promising here. Are we promising that core development discussion will happen there? That's extremely unlikely to work. Are we promising that folks who like helping newbies will be there like we have with #rust-beginners? That may work, but it may not as well. We don't really promise anything for the beginners channel or reddit but it does end up working out on its own. Splitting the community is a very valid concern and needs to be explored thoroughly. I don't spend much time on Discourse, and I'm one of the few people lucky enough to be paid to write Rust code. This (not spending time on Discourse) is true for many people. People participating in their free time will be further sequestered. As a beginner-help channel I think it's a good idea, but attempting to copy more of the communication channels over could be disastrous. Communication needs agreement on the communication channel. Right now we have multiple, but there is general agreement on their purpose. For project-related discussion, we have (-internals, -lang, etc) IRC for on-the-spot rapid discussions of a particular topic which often get flushed as comments to GH or irlo, irlo for informal idea discussion, GH for formal discussion of rfcs and issues. For discussing programming in the language itself we have #rust/#rust-beginners and urlo, but it's fine for these to be fragmented, since it's not an "everybody must communicate with everybody" situation like language design and other internals discussions are. I realize that not having an internals channel on Slack means that we're effectively excluding people who want to participate in these discussions but don't use IRC. I think that's inevitable. If we copy over to slack, we'll have some of the discussion happening on slack, which the IRC-only folks aren't included in, and the rest happening on IRC, which the slack-only folks won't be included in. While this is a strict increase in participation, we may end up excluding as many folks as we include for any given discussion. This doesn't cover moving to Slack, but I feel that there are already plenty of arguments against an open source project using Slack as its primary venue, and besides, the churn itself (with current participants leaving) could be disastrous. We did this before, with the mailing list, and there was churn then, and the community using the list was much smaller at the time (so the impact wasn't too bad). I don't think we could do this now easily. If we started out with Slack I would have similar arguments against switching to or sharing with IRC; a lot has to do with maintaining the health of the existing community. With my novelty "I ❤️ Open Source" hat on: I'm usually very much for keeping multiple ways for participating in an open sourceproject. I am a big advocate of projects that use patch mailing lists to also accept patches (and allow patch reviews) on Github with the discussion being forwarded to the list for newcomers, and nudge them to the mailing list as they grow into seasoned contributors. We have a similar dual-entry system for Servo and I'm quite fond of the model. I think we can do the same here, by keeping general purpose discussion channels on Slack/Gitter, but still keeping them second-class in terms of serious participation. Folks can still have internals discussions on these channels, but it will always be a smaller crowd so for something more involved the more official channels would make sense. This means that folks can start getting involved however they want, and as they become seasoned participants they can include IRC. This is very different from officially encouraging internals discussions on those channels, since that will have the aforementioned split issues. I'm not very fond of asking people, seasoned or otherwise, to use a particular tool, but in this case I feel that it's better than the alternative of splitting. My personal ideal solution for this is:
|
This is an interesting point. I feel like in the inverse situation, my reaction would indeed be exactly the same: double down on the existing communication channels and do not introduce an official channel on a new service. I think that splitting the community along chat service lines will make these communication channels less valuable to everyone compared to making the existing service more accessible and keeping everyone together. It's great having so many people together... on IRC I can start up a quick chat directly with the friendly authors of tons of crates I use. Once you're on IRC, there's so much knowledge you can tap into with just a small amount of effort. Our community is so nice. <3 So it's a shame for someone to miss out on this over IRC's UX problem. But I don't think the best answer is to spread across multiple chat services, which will make certain people less accessible to each other or force people to run more clients. I would rather focus on making Rust IRC more accessible so we can have more people benefit while preserving the connectedness. We happen to be on IRC due to historical accident, and it's worse than some alternatives in objective ways, but I think the value of a more connected community outweighs that and I'm optimistic that we can make it much more accessible than it is now. |
|
Gah, accidentally closed it, butterfingers.
Me too. But I don't think that this ("We would chose Slack in the reverse situation") needs to be too relevant here -- there are plenty of arguments here that deal with "We use communication channel A and want to add B" that are agnostic over A and B. I personally would like to avoid any discussion of which channel is better (not that anyone is doing so now, but we've had plenty on the older internals threads), like Steve I feel that this cuts both ways and IMO the tradeoffs are too complex to make a sound judgement on. So while survivorship bias will be involved in the reactions to this, I think we can try to separate this from this discussion. For example, my comment doesn't really dwell on the differences in slack and IRC, it mostly focuses on the fact that we're already using one of these channels. |
Just for the record, riot.im (or rather matrix.org) has full IRC-bridging capabilities, and has been bridged with mozilla irc network for several month now. Several people (me included) use it to access the IRC channels. So this is most likely why no riot.im users have made such requests. However, advertising the matrix bridges would not imply any split of the community, as they effectively target the same channels. |
|
From my recent personal experiences. I found out tokio/futures only has a dedicated gitter or whatever chat set up and not an IRC channel. I enter webpage, see
Page gets insta- Now, this is just one of the very many problems with this service that would prevent me from participating in this media. That being said, I couldn’t care less about where people figure out their first encounter with borrowck – its always possible to guide them towards IRC later on. |
aturon
added
the
T-core
|
Imagine if you will, a system that:
With bonuses:
If this thing existed, it seems like it would be the better fit for us. I think we mention things like Slack and Gitter, but as others have pointed out, those solution come with their own set of problems (eg, they lack strong moderation). Does IRC have any big advantages over the above solution? Of course, it's familiar to us, it's a known value that people have learned over the years. Still, I believe that this magical unicorn solution would be a better fit for us and something we'd quickly grow accustomed to. |
|
@vberger I hadn't heard of KiwiIRC before, but after trying it for a few minutes I immediately run into things like 1) I can't even join #rust without knowing that it's not on the default server and how to look up what the correct server is (I happen to know these things, but obviously newcomers will not, and shouldn't have to), 2) If I reload the page, it forgets everything. So I don't think that particular web client solves the problems with IRC. |
It is an open, well understood protocol that one can use over as simple an interface as telnet. That’s trivially not true for most of the other options. |
|
@nagisa - absolutely. And I think that'd be true for the unicorn solution as well. |
|
@Ixrec I was thinking it'd be hosted by Mozilla, e.g. like http://webchat.freenode.net. |
IRC is visually pleasant for my tastes.
One of the things I like about IRC is that it doesn't allow for strong moderation. What is said has been said. There is no editing of things or anything. That's great. You can kick/ban/silence users who behave badly, that should be enough. One of the things I hate about the rust subreddit is that moderators often just delete posts. I wouldn't want it to extend this censorship to IRC.
I dislike this as well. On real time platforms like IRC it should be obvious that people only read and reply to the non edited variant. You shouldn't have to check every post in the history about whether someone has edited something.
Again, please no. It creates vertical bloat I don't need or want. The only two things in your list I that I think are positive features is the easier sign on and better persistence. IRC really should provide a better solution for this. But that should be no reason to use something considerably worse like gitter or slack. |
|
@est31 - right, there is no "one size fits all" solution. For some folks, like yourself, the style of IRC works just fine. That said, I'm sure you can recognize what you find valuable that others would not find equally inviting. |
|
There is a lot of throwing around "IRC bad, hurts adoption" sentiments like it's an empirical truth in this rfc. Where is this coming from? Is it based off twitter diatribes? It's definitely not supported by the majority of emojis in this rfc. I don't see anything being reported about IRC after the State of Rust Survey 2016. "Challenges for Rust"
|
|
@salpalvv - it has come up a in person, on twitter, etc. Sadly, there's no place that aggregates all of the comments, but you can see some of them in places like this thread: https://twitter.com/jbeda/status/833008797459230721 |
A community born in IRC will have some degree of self-selection bias for IRC. I mentor people for joining open source; and IRC is a barrier for many. Slack/etc are barriers for others, too, but IRC stands out here. |
I agree, in the sentence you quoted I misspoke. The need for a guide proves that IRC is a problem, but then also not having a guide just makes it more of a problem. Really, I think we should have an IRC guide if we continue to have any substantial IRC presence. This isn't really about solving the main problem, but it seems like a useful thing to do regardless of the outcome of this RFC unless we manage to move all important discussion off IRC. |
Yes, exactly. This is an RFC asking for support from the community, which it doesn't appear to have, to implement something the majority doesn't want nor believe will be a net positive relative to the downsides without any data to the contrary sans anecdotes. |
Inclusion is hard. Almost every inclusion discussion has the self-selection bias issue; and you need to punch past it to get somewhere meaningful. I do think there was decent support for having semi-official Slack/etc channels for analogues of #rust and #rust-beginners, it's the internals thing that is more contentious. |
|
Coming back to this thread after some discussions on IRC, I'm struck actually by how diverse our community already is. We're certainly not a monoculture that likes things a certain way. Sure, there's a self-selection bias around IRC, and lots of questions around it and how to proceed. I'm realizing though, that I made a few mistakes in putting this RFC together. One that I think is the most pressing for the conversations at hand is that for something like this, I should have really tried to have gotten broad consensus around what the current issues are (a la https://internals.rust-lang.org/t/two-stage-rfcs-motivation-overview-then-details/4252). After that point, we could fire away giving solutions that could help with the issues we agreed we wanted to fix. It feels like a lot of this thread was just people trying to get a grasp on the issues, with people solving what they thought they real issue was. I'd be happy to rewrite the RFC in the staged approach and see if we can rally around the motivation/issues to be resolved. Thoughts? |
Indeed, I do agree to adding such channels. Currently my main problem with the RFC is about: 1. the language that assumes that slack/gitter is better in all ways than IRC or wanted by everyone, and 2. that I'd prefer to have discussion about rust development not leaving IRC. |
|
Re: Inclusion - Part of the reason I keep commenting on this thread is that I'm under the impression I'm one of the few in this community who is actively using IRC despite my opinion that (even for people like me that know how to use it) it is sorely lacking compared to all other popular chat software. That said, I don't know what if any alternative we should be looking into, because 1) virtually every alternative has the basic functionality IRC lacks so I honestly don't care which one, 2) I don't know what functionality the rest of the Rust community cares about (is "usable over telnet" a feature we really need?), 3) I don't have a good grasp on how much risk there is of splitting the community by doing something like this, 4) Rust development is the part I'm really interested in so I'd probably have to remain on IRC even if Slack channels did appear.
Sounds like a good idea to me. As is probably obvious by now, I'm much clearer on what the issue is than on how it should be solved. |
|
Staged approach for the win. FWIW, it's worth noting that I'm in the same boat as @Ixrec here: I use IRC, but as noted upthread think it has some serious limitations which are least obvious to the people (a) most comfortable with it and/or (b) who tend to prefer command line tools. (That's not a critique of groups a or b, either, merely an observation.) I am in those channels far less than I would be with something not IRC (Discord/Slack/whatever else) precisely because of the frustrations IRC poses from a UI and UX perspective to me. I think an i.r-l.o and/or u.r-l.o and/or Reddit discussion would be very helpful, and I think that having it not just in internals is important because of the self-selection issue: folks already in internals are the least likely to be those pushed away by IRC. |
|
Uh, I'll advocate for Discord here. Currently as it is, the moderation tools are really strong. You can set roles with permissions, so spamming can be dealt with easily, you can log all messages for posteriority and a lot of other stuff. So yes, moderation isn't a problem in it. As for the ease of new users, they can have access in all platforms. It works in pretty much any browser and has apps for Linux, Windows, Android and iOS, so it covers everyone. It's also very intuitive to use: you just register, join the server and chat. And it has one thing I like better than Slack: you only have one account, rather than having one account per server. I know that the first time I tried Slack I got very confused by this, so I wonder if other people would get confused too. One thing that IRC doesn't have is voice chat, so that could help out immensely as well, especially when hot ideas are being discussed. You can have voice chats in a server and individually too, so it offers max flexibility for conversations. The voice chat is also very good: the voice quality is amazing and it consumes little data, so people can talk about Rust anywhere they want. It also has support for bots, so stuff like compiling in the playground definitely works, along with syntax highlighting, which is definitely a must. In fact, the new bot is still being worked on. It's being rewritten in Rust, and I'd love to get newcomers to Rust to try and help on the bot. It's a great first community project to work on. 😄 Since it also has support for bots, it can (and should have) an IRC bridge. Then, all the messages that get sent to the discord also get mirrored on the IRC, so for the people that like the IRC more they can still watch what's being talked on the Discord without actually having the client open. Another cool thing that the bots allow is webhooks, so you can hook them up to the Rust repo over on Github and it will send a message whenever a new commit is pulled, a star is added, basically any git interaction with Rust. You can also mirror /r/Rust from Reddit to a channel, so when beginners post questions or an interesting article is posted you also get notified instantly. Here's a link to it if anyone wants to judge and build an opinion on it. Keep in mind that as of now it's really in rough edges and that I'll gladly accept suggestions to improve it for everyone in the community. 😃 https://discord.gg/23sA8nR PS: Yes, the server link is not very friendly. However, there's a way to get a custom server URL like https://discord.gg/rustlang or something. It takes some time though, so I don't think we can get it anytime soon unless some other things happen. |
|
I agree with @solson's proposal of an IRC guide for newcomers. Really, no communication platform is going to be 100% intuitive to everyone, so I think that a guide to get started on whichever platform would always be useful. |
|
@vberger I have an open pull request to the rust-lang website linked here to add kiwiirc with pre-configured channels. Kiwi only solves so much though, the users won't see a history and similar things, but it's a huge improvement on the "this is so hard to get started/looks very dated" side of things. |
|
I agree to, any proposal we take means we should document to people _why_ they should bother and how.
…Sent from my iPad
On 20 Feb 2017, at 02:45, Curtis McEnroe ***@***.***> wrote:
I agree with @solson's proposal of an IRC guide for newcomers. Really, no communication platform is going to be 100% intuitive to everyone, so I think that a guide to get started on whichever platform would always be useful.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
On 19 Feb 2017, at 23:17, Chris Krycho ***@***.***> wrote:
I think an i.r-l.o and/or u.r-l.o and/or Reddit discussion would be very helpful, and I think that having it not just in internals is important because of the self-selection issue: folks already in internals are the least likely to be those pushed away by IRC.
The discussion on URLO and Reddit has happened, the outcome of this was this RFC. Let's not loop again or we could go on with this topic forever.
This is the kind of topic where an infinite amount of opinions can be gathered, but the solutions and their validation need work and effort and are also constrained by people willing to work on certain solutions. If we continue the discussion state (which has been going on for close to half of a year), we'll shy away people that want to work on solutions instead of discussing solutions.
|
Yes, as that’s essentially what salvages us all from all those Electron "Eatin' RAM for breakfast everyday” Applications. I happen to have strong feelings about this stuff (both simple protocols and electron-sort-of apps). I’m glad discussion is only revolving around new venues equivalent to |
|
Huh. I double checked just to be sure, and Discord will always be free.
(Taken from this post) |
I don't agree. Rust has a very specific split of channel and groupings and even if the guide just documents "If you are a beginner, click this link and talk to people in #rust-beginners", that's alright. |
|
Just checking in on this, @jonathandturner, do you plan to close out this RFC and move toward discussion elsewhere? |
|
@aturon - I'm happy to close it, but IIRC I was asked not to close it? But yes, I'm fine closing this issue. |
This RFC proposes adding official gitter and Slack channels to compliment our official IRC channels.
Rendered