weixin_39936388
weixin_39936388
2021-01-08 19:42

New communication channels

This RFC proposes adding official gitter and Slack channels to compliment our official IRC channels.

Rendered

该提问来源于开源项目:rust-lang/rfcs

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

98条回答

  • weixin_39893274 weixin_39893274 4月前

    Is it based off twitter diatribes? It's definitely not supported by the majority of emojis in this rfc.

    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.

    点赞 评论 复制链接分享
  • weixin_39998541 weixin_39998541 4月前

    More precisely, the fact that a guide is required at all is what makes IRC esoteric compared to other chat systems. This is why simply creating guides is not a solution to the problem

    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.

    点赞 评论 复制链接分享
  • weixin_39634438 weixin_39634438 4月前

    A community born in IRC will have some degree of self-selection bias for 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.

    点赞 评论 复制链接分享
  • weixin_39893274 weixin_39893274 4月前

    This is an RFC asking for support from the community, which it doesn't appear to have

    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.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

    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?

    点赞 评论 复制链接分享
  • weixin_39985842 weixin_39985842 4月前

    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.

    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.

    点赞 评论 复制链接分享
  • weixin_39757212 weixin_39757212 4月前

    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.

    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?

    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.

    点赞 评论 复制链接分享
  • weixin_39907131 weixin_39907131 4月前

    Staged approach for the win.

    FWIW, it's worth noting that I'm in the same boat as 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.

    点赞 评论 复制链接分享
  • weixin_39634576 weixin_39634576 4月前

    I agree with '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.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

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

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39664746 weixin_39664746 4月前

    is "usable over telnet" a feature we really need?

    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 #rust and #rust-beginners, which I don’t frequent, and by extension cannot care much about them. However, the same moment the discussion begins involving the rest of the rustc development channels (i.e. the stuff I care about), it becomes a discussion about splitting the venue I myself frequent, which leads to exclusion of myself from some or (eventually) all of the discussion.

    点赞 评论 复制链接分享
  • weixin_39664746 weixin_39664746 4月前

    A concern I haven’t seen pointed out yet is that Slack is a paid service. This may cause unnecessary problems. See for example 1, 2.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • we should definitely make some time to chat about unofficial channels.

    I find myself vacillating between "this can wait, we can revisit later" and "this actually is a very real hindrance to Rust adoption"

    I think is right to keep pushing for a solution. I woke up this morning to this thread on Twitter, which to me underscores the sentiment I was trying to represent:

    screen shot 2017-02-20 at 8 21 56 am

    点赞 评论 复制链接分享
  • weixin_39893274 weixin_39893274 4月前

    Yeah, I agree.

    I find that the initial RFC was very aggressive towards moving off IRC entirely (with the whole "internals communication" part), which can't work for this community, and we may have gotten lost in the weeds with that.

    What I think is that we should push on incubating a semi-official Slack community (Gitter already exists), and list them on the community page along with the other channels. Your comment about "communication channels should grow organically" -- organic growth does not imply that we shouldn't do some work in this direction itself, and it doesn't imply that we should just twiddle our thumbs till a Slack appears. We can start a channel and give it some credibility by being on the community page as semi-official, and then let it grow.

    We should also mention irccloud on the community page if we don't already.

    Overall I feel like closing the RFC is a bit premature. There seemed to be a direction that folks were agreeing on, just that this wasn't the one in the initial post.

    "this actually is a very real hindrance to Rust adoption"

    Once again, we're conflating beginners/general chatter channels and internals channels, though. "This is a hindrance to Rust adoption" is very different from "This is a hindrance to contributing to Rust". There's a lot of conflation of these two throughout these threads, and the two have significantly different tradeoffs involved, and we should be very clear about which one we're discussing.

    But yeah, I agree that IRC is often a hindrance.

    点赞 评论 复制链接分享
  • weixin_39998541 weixin_39998541 4月前

    I think we could do quite a bit to kill the aforementioned myth about IRC and "real programmers" just by having a guide for getting connected and involved with Rust IRC on the website as I mentioned previously. I still think it's the most effective thing to do right now. I also agree with having non-IRC beginner question-focused communities, but centralizing discussion as much as possible has a lot of benefits and we're already heavily centralized on IRC, so we should make it as easy as possible to engage with IRC.

    I guess what I'm saying is that IRC is considered esoteric mostly due to a lack of good guides rather than inherent difficulty. (Okay, to be fair, also a lack of good clients in my experience.)

    Any good bridges that meet the criteria discussed previously (especially around moderation) would be quite effective, too.

    点赞 评论 复制链接分享
  • weixin_39805255 weixin_39805255 4月前

    IMO it would help a lot if Mozilla had a good webIRC experience, Mibbit is an awful first interaction with IRC and banned in lots of communities (especially on Freenode) because it facilitates abuse.

    点赞 评论 复制链接分享
  • weixin_39624980 weixin_39624980 4月前

    Regarding a good webIRC experience, KiwiIRC has been brought up a few time in the discussion already, and is a quite friendly interface.

    点赞 评论 复制链接分享
  • weixin_39757212 weixin_39757212 4月前

    I guess what I'm saying is that IRC is considered esoteric mostly due to a lack of good guides rather than inherent difficulty. (Okay, to be fair, also a lack of good clients in my experience.)

    More precisely, the fact that a guide is required at all is what makes IRC esoteric compared to other chat systems. This is why simply creating guides is not a solution to the problem; the only people who would read them are people who a) are aware IRC requires a guide to use properly, and b) are willing to read guides just to use a chatroom, and c) haven't already done so. Personally, I probably wouldn't be on the Rust IRC channels if I hadn't already been forced to learn IRC years ago for unrelated reasons.

    Trying to create a web IRC client that's good enough to not need a guide at all (i.e., one that takes care of remembering your rooms, your nick(s), verifying your identity and so on without any tutorials or configuration) would be far more likely to improve the situation imo.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

    Imagine if you will, a system that:

    • Is very easy for a new user to sign up for
    • Persists conversations, mentions, notifications, etc between logins
    • Is visually pleasant
    • Allows for strong moderation

    With bonuses:

    • Allows you to edit things you mistyped
    • Allows good interaction with things like GitHub

    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.

    点赞 评论 复制链接分享
  • weixin_39757212 weixin_39757212 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39664746 weixin_39664746 4月前

    Does IRC have any big advantages over the above solution?

    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.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • absolutely. And I think that'd be true for the unicorn solution as well.
    点赞 评论 复制链接分享
  • weixin_39805255 weixin_39805255 4月前

    I was thinking it'd be hosted by Mozilla, e.g. like http://webchat.freenode.net.

    点赞 评论 复制链接分享
  • weixin_39985842 weixin_39985842 4月前

    Is visually pleasant

    IRC is visually pleasant for my tastes.

    Allows for strong moderation

    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.

    Allows you to edit things you mistyped

    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.

    Allows good interaction with things like GitHub

    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.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • 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.

    点赞 评论 复制链接分享
  • weixin_39634438 weixin_39634438 4月前

    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"

    learning curve, immaturity of the language and libraries, and immaturity of the tools.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • 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
    点赞 评论 复制链接分享
  • weixin_39574720 weixin_39574720 4月前

    In reference to the discord IRC bridge, here is a couple of screenshots of how that client looks like. (ignore the conversation, not relavent) irc hack1 irc hack2

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

    Unless anyone objects, I move we close this PR. It seems like the original thrust of "let's make an official Slack and make the Gitter channel official" is far afield from where the conversation has landed.

    The general gist I'm getting is that communication channels need to arise more organically, along with their own organically grown moderation. The support for starting official channels, judging from the votes and the thread, isn't there and we should move on exploring alternative ideas.

    Thanks for the feedback.

    点赞 评论 复制链接分享
  • weixin_39747341 weixin_39747341 4月前

    That makes sense. I'd be happy to collaborate with you also on an RFC for describing the standards of conduct organically emergent communities need to meet to be listed along with the subreddit as 'unofficial channels.'

    Also as the pull requester you can just close this I believe without it having to go through FCP.

    点赞 评论 复制链接分享
  • weixin_39875516 weixin_39875516 4月前

    I'd be very interested in that RFC, especially since I just started that Discord server for it.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    I object, at least without some kind writeup of actions that are going to be done instead.

    This whole process has shown that the current state of things is broken and needs to be fixed.

    Especially with my proposed (although still rough) improvement for accessing the IRC channels https://github.com/rust-lang/rust-www/pull/701 hanging explicitly because of this IRC, we need some kind of writeup of what's going to be done, also how 's work is going to be handled.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    What we really need (though I'm sure at this point [a] no one has time to build it and [b] after all the times it's been tried it probably wouldn't catch on well enough if someone did) is a true open-protocol service that modernizes IRC. Heck, IRCv3 (welcome though it will be) is catching up to where non-IRC apps were 5+ years ago. So that's not going to make an appreciable difference in the issues listed above.

    have you tried kiwiirc? It at least eases the pain of joining for the first time. I agree that configuration is still a mess (and it kept me out of IRC until Rust gave me enough incentive to stay around there).

    I have high hopes for Matrix and hope they reach an amount of polish that makes it easy for people to participate.

    点赞 评论 复制链接分享
  • weixin_39602571 weixin_39602571 4月前

    Node.js is having a very similar conversation right now. https://github.com/nodejs/community-committee/issues/11

    点赞 评论 复制链接分享
  • weixin_39634438 weixin_39634438 4月前

    I guess I'd argue for linking to the unofficial channels, with a clear note that they're not official but that there are folks in there fairly regularly, and "anointing" moderators who are active there.

    This feels spiritually similar to propping up the blessed crates instead of adopting them into std. I like this approach; offloading the burden of "more" to the most passionate and trusting those to carry that torch.

    点赞 评论 复制链接分享
  • weixin_39985842 weixin_39985842 4月前

    Even if I were forced to use matrix/slack/... I'd attempt to configure it to be as much as IRC. Anything but pure text just distracts. I guess its the plaintext vs HTML E-Mail war all over again... (plaintext is better xP)

    But Matrix is the open source solution, so if one "non plain text chat" solution has to be picked, then I'd chose Matrix.

    点赞 评论 复制链接分享
  • weixin_39618597 weixin_39618597 4月前

    Matrix isn't as well load-balanced as other services (the main homeserver is hosted only in EU), but it's native bridging is definitely convenient. I would love to see more users on Matrix, since that enables us to see who is typing and who have read the message.

    点赞 评论 复制链接分享
  • weixin_39528289 weixin_39528289 4月前

    Just for the lazy I thought I'd mention the link: matrix bridge link https://riot.im/app/#/room/#mozilla_#rust:matrix.org

    点赞 评论 复制链接分享
  • weixin_39907131 weixin_39907131 4月前

    Possibly worth considering in the mix of options (though with the not-an-open-protocol downside): Discord is a high-quality app experience—much better than the other Slack-alikes I've used, and arguably better. The Rust channel is here.

    It is possible to join Discord rooms with IRC clients (here, but it's something of a hack.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • I think you're proving out that "people are going to do it anyways" 😄 I had no idea we had a discord channel already.
    点赞 评论 复制链接分享
  • weixin_39907131 weixin_39907131 4月前

    looks like it's pretty recent—as in, 4 days old. 😛

    点赞 评论 复制链接分享
  • weixin_39875516 weixin_39875516 4月前

    Hello, I'm the owner of that Discord server. I'm always open for suggestions and guidelines to help make it better for the Rust community!

    点赞 评论 复制链接分享
  • weixin_39789525 weixin_39789525 4月前

    I'd like to advocate for matrix again. For the last 18 months all Freenode channels has been bridged, so matrix users and IRC users can talk as if they were both using the same app. Matrix also supports guest logins, and other modern chat features.

    点赞 评论 复制链接分享
  • weixin_39761422 weixin_39761422 4月前

    and others who vastly prefer terminal based IRC, https://github.com/rawdigits/wee-slack connects weechat to Slack using Slack's HTTP API. It works very well, though obviously not in irssi. I use Slack for work and love that I can communicate without opening the Slack web app behemoth, and lurk in IRC from the same client.

    I thought I'd mention it if it helps with this one objection to moderating Slack channels.

    点赞 评论 复制链接分享
  • weixin_39761422 weixin_39761422 4月前

    Speaking personally... though I do lurk and ask infrequent questions, I've never been comfortable with IRC and totally get the "friendlier" appeal of Slack. I think we absolutely should have Slack channels that parallel #rust and #rust-beginners. I know I'm not a familiar face in the Rust community but I'd certainly be willing to be a presence in Slack. If that at all helps in any way. Which I doubt :)

    点赞 评论 复制链接分享
  • weixin_39906245 weixin_39906245 4月前

    Hi , I'd like to chime in on the specific point about Slack moderation tools from the perspective of an admin of a Slack with 8,500+ registered users.

    These tools amount to: deleting messages (the poster can up arrow and then enter to re-post), kicking someone off a channel (they can rejoin, and can read the channel without joining), and disabling an account (here the usual contingencies apply, but I do wanna note that email.com and email+1.com are seen as different emails by Slack). I think describe the available tools aptly, they're team management tools, as Slack calls them.

    The fact that the solutions are all or nothing doesn't leave much room for nuance :\ There's no way to ignore someone, shut down your DMs, block someone from entering a channel, etc. I'd also like to point out that displaying the name and the email for every user is set by the admins and are turned on by default, if I remember correctly (brought up in https://github.com/rust-lang/rfcs/pull/1865#issuecomment-274738583). It is also my understanding that automated logging is against the TOS, and with an active community the backlog churn can be hours.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

    We should definitely look into ways of making the IRC experience even better with addition tools (Matrix as one possibility that has been brought up a few times). Would love to see that get better over time.

    Something that came up for me during the community meeting this week is that while there are technical questions around IRC we should address, there's also just the basics of being comfortable with the tools you have. An imperfect analogy here is "do you make someone change browsers to view your webpage?" For us, since we want Rust to be open to the most number of people, we err on being as accessible as possible, and fixing the site so it works with anyone's browser.

    Of course, the analogy is flawed in that it doesn't take into account the increased burden on things like moderation. Still, I think it captures the essence of why some people are uncomfortable. Rather than being technical, it's about the choice and letting people make their own choices.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

    Granted the analogy is flawed in another way in that it splits the community, as pointed out in the first comment, rather than allowing more browsers to share the same resources.

    Maybe one take away is that if we do work on allowing Slack to be supported, then we needed to bridge the technologies so that a Slack user gets the Slack experience, an IRC user gets the IRC experience, but we're still all working and chatting on the same channels under the surface.

    点赞 评论 复制链接分享
  • weixin_39747341 weixin_39747341 4月前

    I think the real question at issue here is this: should we enable people to discuss Rust on the platforms they already use? (the wording of this question may be biased; IMO the answer is a resounding 'yes') And then, how can we enable them?

    I don't think its appropriate to create an 'official slack channel' out of the ether. I think what we should be figuring out is how we can enable the situation that has happened with the r/rust subreddit to happen on other platforms. What is the minimum we have to do as a project to allow groups to grow organically on different platforms? What standard do we hold for those groups to receive 'unofficial endorsement' from the project?

    I still don't feel that 'splitting the community' is a problem any more than r/rust and the discourse forums 'split the commmunity.' Our goal is to have a community too large to fit in one venue!

    点赞 评论 复制链接分享
  • weixin_39634438 weixin_39634438 4月前

    Any work toward supporting slack as an official channel is work that might also be allocated to making irc "suck less" for those embarriered individuals.

    If I am to use yet another chat tool, it's less ergonomic to get answers to my questions. As someone that already uses the available channels to ask what questions I have (and am perfectly happy with it), I don't feel that this will benefit me.

    So, this would be annoying for me (I may not be alone) and potentially helpful for others. Is there evidence that this will actually be a net positive? I prefer to not be inconvenienced without just cause.

    Since the purpose is to target prospective members that are hesitating to use rust because it doesn't offer Slack as an official communication channel, I would like to see data that supports the anecdotal "irc is a barrier for entry" assertion and how this has a causation on lower rust adoption.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    Any work toward supporting slack as an official channel is work that might also be allocated to making irc "suck less" for those embarriered individuals.

    No, this isn't true. First, because people working on one thing may not be inclined to do another, second, because IRC can only be changed so much.

    点赞 评论 复制链接分享
  • weixin_39875516 weixin_39875516 4月前

    I am currently setting up a Discord server with help channels, announcement channels, etc. How would I go about proposing it to be an official communication channel?

    点赞 评论 复制链接分享
  • weixin_39574720 weixin_39574720 4月前

    I wonder if a solution would be to bridge theses alternative clients to the IRC channels, and use that to allow people to choose their preferred client for chatting with other people. To me at least this seems to cover both the case of people who want alternative chatting applications allowing everyone to be able to use what they like best to communicate with the community, & those who worry about the community splitting over trying to change to a different service.

    Most of the clients proposed are all for the same medium, just using different forms and backends to allow chatting. I know for example that there are IRC bridges for Discord and Slack, and that a couple of communities I'm in have tied Discord and IRC/Slack and IRC to allow people to use what they want, without limiting the other party to on specific client.

    TD;LR I'm proposing we try to tie several together with the IRC being a "base" for everything to communicate to.

    I hope I wasn't to confusing in my input here, but I'm unsure how I'd put it in other words.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    Bridging has been brought up multiple times and isn't as nice as it sounds. Slack and IRC do have differences and the bridges often feel a bit clunky. Also, it makes moderation hard(er).

    点赞 评论 复制链接分享
  • weixin_39574720 weixin_39574720 4月前

    I didn't mean to convey that they didn't have differences, more of that at the core they are the same.

    I did however forgot about moderation factor of this, as it wasn't a big issue with the communities I'm in it worked out well since they have people of both fronts handling things, and this community is several times larger than that and would have some issues with handling it.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • I believe the process is to create an RFC that proposes the dischord channel be official.

    You may also want to look into the Rust community channel on IRC and chat with some of the community managers there.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • We can definitely set up an unofficial Slack channel. That was my first instinct. I heard a little push-back then because there was some concern over moderation and quality of the experience for new users.
    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    Well, if Discord fares better privacy-wise then Slack and is as well accepted I'd also be up to that.

    点赞 评论 复制链接分享
  • weixin_39520149 weixin_39520149 4月前

    I still don't feel that 'splitting the community' is a problem any more than r/rust and the discourse forums 'split the commmunity.' Our goal is to have a community too large to fit in one venue!

    While I certainly agree with the spirit of this comment, I think the framing is making a few false presuppositions:

    • What does it mean to be too large to fit into one venue, and do we have that problem today?

    • The desire to be large shouldn't necessarily lead to a "let 1000 forums bloom" approach. For me personally, the split between r/rust and internals on discourse is a frequent pain: I often want to raise important questions to "the community", and end up needing to cross-post and try to cross-polinate discussions, and of course some people end up never speaking to each other due to the distinct forums. The same is true with any other pairing -- IRC vs github, internals vs RFC repo, etc.

    • Relatedly, I think a central question is "where do the Rust teams hang out"? That matters for several reasons. Conversations with the Rust teams are the most likely to affect change in Rust. They are ways to get on the same page regarding the core values of the language and understanding tradeoffs. They provide mentoring opportunities. I talked about this a bit in my earlier comment, but I think that simply adding an unofficial Slack channel, while keeping the current IRC channel as is, will fail to have the impact of bringing people for whom IRC is an obstacle into contact with the Rust teams.

    I think others have made this point before, but the notion of "official" channels is also an important one, in terms of "places you need to watch to take place in core Rust evolution." I think we're in good shape there regardless of the outcome of this discussion, because everything of consequence goes through the RFCs repo. So what I'm getting at is less this "official" status, and more the de facto importance of "where core Rust devs chat day to day".

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    What does it mean to be too large to fit into one venue, and do we have that problem today?

    This isn't necessarily the way I would phrase that. It's more the question whether the communities are large enough so that the amount of effort to somehow join them (though mirroring etc.) stands in no relation to the gain.

    ... people for whom IRC is an obstacle into contact with the Rust teams.

    There is still the open question if those peoples pains are the pains of Rust IRC regulars and if we can provide "better horses" here. All channels with important issues of policy are logged and documented anyways and we can make joining as simple as one click. You don't need to know any IRC to just chat with us a little anymore. (see the kiwiirc example)

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • I think those are all valid points, and well-stated I might add.

    But I'm left with a sense of "but then what do we do?" Is there a way forward that addresses the points you raise?

    点赞 评论 复制链接分享
  • weixin_39520149 weixin_39520149 4月前

    My personal preference is to make the usual Rust play: try to eliminate the tradeoff.

    In particular, it still seems likely to me that we can go with a service that is as easy to use as Slack, but has a very strong bridge to IRC. Even Gitter is pretty good on this front, but many have suggested matrix.org as well. (I know that Slack, in particular, does not have a great bridge).

    mentions that bridges can feel a bit clunky; I agree, but in my experience the clunkiness is generally visible on the IRC side, rather than the "more rich" side -- so if this is mainly about accessibility, that seems like a potentially reasonable tradeoff.

    I'd like to see someone flesh out a more detailed proposal based on bridging to a service like matrix.org, accounting for issues like moderation and pros/cons relative to more well-known services like Slack.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    mentions that bridges can feel a bit clunky; I agree, but in my experience the clunkiness is generally visible on the IRC side, rather than the "more rich" side -- so if this is mainly about accessibility, that seems like a potentially reasonable tradeoff.

    Well, I know about the clunkiness of the slack bridge (even if I don't use it often, so I don't follow developments), so my side of the argument is just warning that the quality of those bridges varies and must be investigated. It's not a strong opinion :).

    点赞 评论 复制链接分享
  • weixin_39998541 weixin_39998541 4月前

    I'm a full-time user of the Matrix IRC bridge and it is currently very clunky on the Matrix side IMO. It's mostly invisible to users on the IRC side (since the Matrix bridge maintains a separate connection per Matrix user using the bridge), but I can't recommend using Matrix as an easy option for new users.

    I've written a blog post about how I switched from IRCCloud to Matrix for IRC if anyone is interested in the pros/cons. I need to update since a few points have gone out of date (you can see topics and join/part now and you can auto-auth with NickServ) but it's mostly still accurate.

    点赞 评论 复制链接分享
  • weixin_39520149 weixin_39520149 4月前

    I'm a full-time user of the Matrix IRC bridge and it is currently very clunky on the Matrix side IMO. It's mostly invisible to users on the IRC side, but I can't recommend using Matrix as an easy option for new users.

    That's unfortunate, but very valuable information.

    For my part: I communicate with the Tokio team and community Gitter channels through IRC. From the Gitter side, this works seamlessly, except for the occasional outage. From the IRC side, it works pretty well, with a couple of minor issues (the list of channel members is incomplete, and you have to make sure to type `` if you want to alert someone in Gitter).

    That said, the bridge goes through a dedicated IRC server: irc.gitter.im. So I'm not actually sure it could be used with our IRC channels on Mozilla's network...

    点赞 评论 复制链接分享
  • weixin_39907131 weixin_39907131 4月前

    I'll chime in here as someone who's in 7 active Slack teams (though not as many as , who I'm pretty sure is a 🤖 because he doesn't sleep):

    • Slack is much easier for me to use for things like sharing code, and it's far, far friendlier for a lot of people in my circles. There's a non-trivial divide in the tech world between the folks who are as or more comfortable in Vim and IRC than a GUI IDE and Slack, and the folks who are exactly the opposite. Me, I like a good GUI.

      • I deeply appreciate not having to pop over to some paste-bin or another to drop some code inline and have it readable. I have a good IRC client, and I've been using IRC for over a decade. I'm perfectly comfortable with it. But I have never loved it, and I never will. It's just plain harder than HipChat/Slack/etc. in certain ways—like code samples, which is a really common thing to be dealing with.

      • What the heck is a mode? I have some idea a decade in, but I still have to go look up what modes are what.

      • Configuring even a good client is still not trivial: server setup, nickname registration…

      • Don't get me started on notifications and history. It takes a huge amount of knowledge to get that stuff set up. And yeah, there are online things that get you a fair bit of that, but… discoverability is a problem.

      All of that is to say: there are real learning curve issues around IRC that I think are worth admitting freely. They may not be issues for everyone, and maybe not even a majority (I have no idea); but they are certainly issues for many.

    • On the other side of the coin, though: I full stop would not recommend using Slack itself. One of those Slack teams I'm in is the Ember team. None of the general benefits Slack provides for paid teams really apply to the Ember team: we lose context very quickly. A bouncer in IRC is a clear and easy win over that; so are the infinite histories available in some of the other—often less-pretty-but-more-free—apps. That plus the moderation issues are such that I would argue strongly against trying to make Slack the (or really even an official) channel.

      Mind: I have no particular ideological concerns with Slack (though I understand the concerns of those who do, e.g. ); I just don't think it's a good fit for OSS communities. It's a very useful business tool. It's not so great outside that niche.

    So… what then?

    I guess I'd argue for linking to the unofficial channels, with a clear note that they're not official but that there are folks in there fairly regularly, and "anointing" moderators who are active there.

    What we really need (though I'm sure at this point [a] no one has time to build it and [b] after all the times it's been tried it probably wouldn't catch on well enough if someone did) is a true open-protocol service that modernizes IRC. Heck, IRCv3 (welcome though it will be) is catching up to where non-IRC apps were 5+ years ago. So that's not going to make an appreciable difference in the issues listed above.

    If there is an open protocol out there (Matrix? I don't know) with clients that support more of those things and have shallower learning curves, I think it is worth seriously considering adopting one of those—migrating away from IRC, or supporting IRC via bridge only, or some such. :shrug:

    点赞 评论 复制链接分享
  • weixin_39664746 weixin_39664746 4月前

    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

    Sign in to start talking

    Page gets insta-Super Q/Alt F4d and I go solve my problems by being mildly offtopic on #rust-libs instead.

    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.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    A problem that isn't mentioned - and is rather fundamental - is that Slack publishes your email address to everyone.

    Also, I see a lack of research into other options. Some of the comments from the URLO topic weren't addressed.

    点赞 评论 复制链接分享
  • weixin_39804631 weixin_39804631 4月前

    I found out tokio/futures only has a dedicated gitter or whatever chat set up and not an IRC channel. I enter webpage, see

    [Sign in to start talking]

    Page gets insta-Super Q/Alt F4d and I go solve my problems by being mildly offtopic on #rust-libs instead.

    What's so bad about about Gitter's sign-in button? You just click a button, confirm it on GitHub's page (as GitHub explains on the permissions page, Gitter will get your name and email, but not write access to your repos or anything), and you're in. You can see the backlog without signing in, but there has to have some kind of nickname registrar to keep people from impersonating you, and Gitter's process is a heck of a lot easier than registering with NickServ. It also means nicknames on Gitter and GitHub are always the same, which is an annoying problem to hack around.

    点赞 评论 复制链接分享
  • weixin_39761422 weixin_39761422 4月前

    I agree with that riot.im is worth investigating as possibly The Friendlier access to IRC. While it's not as polished and visually attractive as Slack, it's a reasonable way down that direction.

    Another benefit is that it has bridges over to Gitter rust-lang/rust and tokio-rs/tokio channels.

    Riot.im does not require you to disclose an email address or any other personal information to a channel.

    The downside is that bridging causes a noticeable round-trip communication delay.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • I tried to address as many as I could. Did you see any in particular?

    From :

    
    * Have general purpose Rust/beginners channel(s) on Slack and Gitter. I don't particularly have an opinion of a #rust/#rust-beginners-like split, since #rust is still 90% beginners discussions and 10% offtopic banter, so it doesn't really matter IMO.
    * Link to them from wherever. Homepage, community page, readme, etc.
    * Grow mods organically from those subcommunities, so mod team only needs to be involved when bootstrapping them.
    

    An earlier iteration of this was exactly this. It's definitely a possibility.

    As points out:

    
    I've seen users actively request a slack channel several times. I haven't seen users request any of these other services.
    

    The requests on twitter and other venues (even people coming up to us at conferences recently) have asked specifically for Slack. While there are ways we can make IRC better, I think the focus on here is how do we help the Slack folks.

    点赞 评论 复制链接分享
  • weixin_39664746 weixin_39664746 4月前

    …You can see the backlog without signing in, but there has to have some kind of nickname registrar to keep people from impersonating you, Gitter's process is a heck of a lot easier than registering with NickServ…

    No it is not, because all you need to do is to close the tab/window/chat which contains any mention NickServ in it. Preventing impersonation makes no sense whatsoever when somebody is just asking a single/a few questions.

    I’ve seen this nice DiscordBridge thingy on #rust-libs recently. It was fine as a way to bridge multiple communication media. IMO its worthwhile to discuss something like this only if somebody spends time developing bridging between media that is same in purpose.

    点赞 评论 复制链接分享
  • weixin_39805255 weixin_39805255 4月前

    :+1: on bridging, there's no reason to fragment communities if it can be avoided. I am not likely to move off IRC unless a bridge back to IRC is provided, as I would rather not have more than one client - instant messaging is bad enough at this as it is, let's not repeat those mistakes.

    点赞 评论 复制链接分享
  • weixin_39520149 weixin_39520149 4月前

    I think it's definitely worth thinking about how to make our chat more accessible. People who do make it to our IRC channels tend to love them, but anecdotally there are plenty of people for whom IRC is a roadblock.

    I agree with the point that and others have made: there's a real sense that IRC today is the hangout for core developers and library authors. When considering adding another venue, there are basically three possible outcomes with respect to this group:

    • The core dev chat continues to be IRC-based.
    • The core dev chat becomes fragmented over several channels.
    • The core dev chat moves entirely to Slack (or whatever new venue).

    Now, it might make sense (as some have proposed) to consider "newcomer chat" as distinct from "core dev chat", with possibly different venues. But I think that would be a big loss; in my mind, we need to do everything we can to make it easy to transition from Rust beginner to Rust contributor to Rust core dev. And, similarly, I often gain insights by seeing newcomer questions, in terms of places to improve the language or libraries. (FWIW, I already find even the fragmentation into multiple IRC channels sometimes annoying, but at least there I can generally assume that the most relevant people will see a message.)

    So, from my perspective, I think that supplementing the existing venues, without any other change, is a risky step to take. We could consider instead trying to wholesale move the community elsewhere, but that comes with its own risks. What I don't quite understand is, if there are more accessible chat services that have a high fidelity IRC bridge, such that we retain the same set of channels globally -- what is the downside of using those tools? (I talk on the Tokio gitter channels using an IRC bridge, and it largely works well.)

    Finally, I think we should take 's suggestion about easing the onramp to IRC basically regardless of what happens with this RFC.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    I have multiple problems with this RFC, most that I don't find the motivation clear enough and no formulation of expectations that the Rust team has as a solution. Condensed, it's currently "IRC sucks for some, so let's also have a Slack". Also, it doesn't clarify whether the propose solutions should become a new primary entry point, as mentioned here: https://github.com/rust-lang/rust-www/pull/701#issuecomment-275278852

    (I'm not sure whether "primary entry point" is even a good thing to discuss)

    Privacy implications of the other solutions are currently completely ignored.

    The community team discussion yesterday has shown that there's a lack of deeper research into the problems at hand. http://logs.glob.uno/?c=mozilla%23rust-community&s=25+Jan+2017&e=26+Jan+2017#c17027

    • Why does IRC suck to some? Can that be improved? Can we make an effort to point them to easy solutions?
    • Would people only accept slack or any better alternative with better usability?
    • What is the Rust projects stance on the privacy implications of an offered solution?
    • Can we improve across the board?

    Especially the privacy point, IMHO, rules out Slack as a primary venue for discussion clearly. It publishes your email unconditionally and logs your messages forever (inaccessible messages on the free plan are logged nevertheless).

    Also, I get the growing fear that the ongoing discussion blocks active improvement in areas that already exist, such as the linked proposal to add the (IMHO really great and usable) Kiwi interface to the Rust website, making joining IRC a one click affair.

    点赞 评论 复制链接分享
  • weixin_39893274 weixin_39893274 4月前

    Why does IRC suck to some?

    Being unpingable when offline. Places with port blocking (yes, you can use irccloud). Having to navigate the choice of clients. Identity issues with nickserv. There's a lot of figuring out that goes with using IRC.

    Slack and Gitter are comparatively just "sign up and go". Especially if you already use Slack in your workflow.

    Would people only accept slack or any better alternative with better usability?

    I think (but have no evidence for) that it it is a bit of both.

    When it comes to things like #rust and #rust-beginners I don't think we should dismiss e.g. Slack because we have something like e.g. Gitter set up, or because something like IRCCloud exists that mitigates many of the downsides of IRC. These channels should have the lowest barrier for entry; folks should not have to "figure stuff out".

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    Being unpingable when offline. Places with port blocking (yes, you can use irccloud). Having to navigate the choice of clients. Identity issues with nickserv. There's a lot of figuring out that goes with using IRC.

    Sure, but how much of that is a problem? Many people use IRC for quick Q&A, where being unpingable is not a problem. The choice of clients can be addressed by just recommending one. There's really good new clients popping up recently, especially with WEBIRC becoming a thing. It's a bit sad that irccloud costs money for a simple plan, but there are alternatives if you can live without a bouncer.

    Identity issues with Nickserv is definitely a problem. (I'm not sure if someone is working on solutions there?

    We did not care for even attempting solutions on any of those fields.

    In any case, all those should be addressed in the RFC.

    Slack and Gitter are comparatively just "sign up and go". Especially if you already use Slack in your workflow.

    On the other hand, Slack is very unwieldy if you don't use Slack in your daily workflow. There's no alternative, accessible clients. There's no unified clients with other communication options. Especially Slack TOS explicitly forbids creating such a client.

    Slack self-signup is surprisingly weird (it confuses me definitely).

    Gitter, I really like as an option, as it has public communities as a core idea. (Still, clients are an option).

    点赞 评论 复制链接分享
  • weixin_39893274 weixin_39893274 4月前

    There's really good new clients popping up recently,

    My issue is that you need to figure this out, which I maintain is still a barrier to entry. I still have had to give a short explanation of IRC to every kid joining open source that I've mentored. Part of it is just "use irccloud", but this shouldn't be necessary. We can improve on this with better docs on the site, but I'm not sure if we can cram all the advice that you need for a good IRC experience there.

    Slack is very unwieldy if you don't use Slack in your daily workflow.

    Right, and I'm not advocating replacing our channels with Slack (see my longer comment in this thread). I'm advocating supplementing them.

    If folks are heavy users of Slack then Slack is probably the easiest way for them to get involved in the community.

    I personally hate slack. The web client eats up RAM no matter what browser I use. I don't like extra desktop clients -- if something wants my attention it needs to fit in a browser tab or a terminal window (I use irssi for IRC). Having a new account for each slack is annoying and hard to keep track of.

    But I know many people who prefer this, and have trouble getting used to IRC. So while I personally wouldn't really frequent a Rust slack, I do think we should have one.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 4月前

    My issue is that you need to figure this out, which I maintain is still a barrier to entry. I still have had to give a short explanation of IRC to every kid joining open source that I've mentored. Part of it is just "use irccloud", but this shouldn't be necessary. We can improve on this with better docs on the site, but I'm not sure if we can cram all the advice that you need for a good IRC experience there.

    Sure, but if IRC channels are going to stick around for important parts of participation (e.g. taking part in the community team meetings), we need to do that anyways. And the current state of business is that you can literally provide a "put your name here, click here" link somewhere and it just works.

    If folks are heavy users of Slack then Slack is probably the easiest way for them to get involved in the community.

    Well, but if this is the main issue, the core argument should be "Slack has considerable reach and much added convenience for those that have it open anyways". Then "IRC is hard", "Gitter is also there" and "Matrix could be an option, too" shouldn't factor in this RFC.

    If the questionable usability of IRC is the core problem, we should gather the features we need and then collect solutions. Including improving the usability of IRC and providing more usable alternatives that fit our wishes.

    点赞 评论 复制链接分享
  • weixin_39950812 weixin_39950812 4月前

    From the RFC:

    we make the unofficial gitter channel official.

    What does this mean? What makes a communication channel "official"?

    点赞 评论 复制链接分享
  • weixin_39893274 weixin_39893274 4月前

    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 '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 :heart: 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:

    • Have general purpose Rust/beginners channel(s) on Slack and Gitter. I don't particularly have an opinion of a #rust/#rust-beginners-like split, since #rust is still 90% beginners discussions and 10% offtopic banter, so it doesn't really matter IMO.
    • Link to them from wherever. Homepage, community page, readme, etc.
    • Grow mods organically from those subcommunities, so mod team only needs to be involved when bootstrapping them.
    • I don't particularly care if they're actually considered "official" or not. The gitter one already existed and could be considered a separate community, really. /r/rust is doing fine as unofficial and we could apply the same policy here (link to it, but let it do its own thing). AFAICT the only difference between official and unofficial is that official channels will have the rust mod team (plus any other mods local to that channel), and the rules are enforced pretty uniformly across official channels.
    点赞 评论 复制链接分享
  • weixin_39998541 weixin_39998541 4月前

    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?

    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.

    点赞 评论 复制链接分享
  • weixin_39893274 weixin_39893274 4月前

    Gah, accidentally closed it, butterfingers.

    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.

    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.

    点赞 评论 复制链接分享
  • weixin_39624980 weixin_39624980 4月前

    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.

    I've seen users actively request a slack channel several times. I haven't seen users request any of these other services.

    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.

    点赞 评论 复制链接分享
  • weixin_39586825 weixin_39586825 4月前

    I don't like it. It just splits the community.

    点赞 评论 复制链接分享
  • weixin_39586825 weixin_39586825 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39782500 weixin_39782500 4月前

    To be clear, this proposal does not require anyone to use Slack or gitter,

    and

    a well-supported way of getting help with Rust questions.

    are in conflict.

    点赞 评论 复制链接分享
  • weixin_39997311 weixin_39997311 4月前

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

    点赞 评论 复制链接分享
  • weixin_39782500 weixin_39782500 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前
    • 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?

    点赞 评论 复制链接分享
  • weixin_39936388 weixin_39936388 4月前

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

    点赞 评论 复制链接分享
  • weixin_39862097 weixin_39862097 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39998541 weixin_39998541 4月前

    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 #rust-internals, so they shouldn't be discouraged or feel ignored by lack of an immediate response. We could also get slightly more general and include a concise "how to ask good questions". Basic things like paste-binning and including exact error text can help people get helped a lot quicker, and they aren't obvious to every new user.

    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?

    点赞 评论 复制链接分享
  • weixin_39782500 weixin_39782500 4月前
    • 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.

    点赞 评论 复制链接分享
  • weixin_39747341 weixin_39747341 4月前

    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.

    I've seen users actively request a slack channel several times. I haven't seen users request any of these other services.

    点赞 评论 复制链接分享

相关推荐