Skip to content
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
This repository was archived by the owner on Apr 22, 2023. It is now read-only.

Central communication medium for chatting in Node.js #11

Closed

Description

@hackygolucky

As part of the strategy to improve inclusivity in Node.js, it was proposed to create a more central, discoverable communication medium for Node.js.

See improving our central communication channels discussed here at Node Interactive

Thoughts on the comparison:

(1) Revitalizing and cleaning up the IRC community.

  • Publish list of channels with webchat link to them on nodejs.org under ‘Get involved’
  • All published channels would be those who have agreed to adhere to the Node.js CoC and will list it as a topic in the channel
  • Require logging for reporting of issues to moderation
  • Outreach effort to encourage positive community and conversational energy to IRC, as many of these conversations have fled to Slack organizations that can be difficult to discover or get into.
  • For this option to work, the moderation policies in current existence for IRC would need to be refactored and pull requested into the nodejs organization as part of a guide for the Code of Conduct. The current policy does not handle online, year-round communities comprehensively.

OR

(2) Creating a new, central Node.js Foundation Slack organization

  • Open by default--We will set up an open sign-up to allow for anyone who would like to participate in the Slack to do so. This sign-up also allows us to gate participation in the community ONLY by requiring participants to agree to adhering to the Code of Conduct.
  • unpaid Slack org with IRC bridge enabled. Other non-profits we've talked to that have as large of a userbase as us and have tried have run into exponential cost increases, even with the severe non-profit discount Slack provides upon application. A suggestion was made for alternative logging(can be used via an IRC bridge/logging)
  • General, random, and working group-ish channels(could have private ones for discussions needing to be protected with a policy of keeping convos pointed to public channels as much as possible)
  • Allows for the ability to moderate with admins easily--all channels can be seen and in instances of reporting for violations, there is a log.
  • Since sign-up is required, it can be more difficult for abusers to cloak themselves under another name and continue to be toxic in a community that is gated.

I would love to hear comments below about the pros and cons of each! But voting is really helpful here.

If you'd like to vote, the Emoji reaction survey system is this:

React with
😄 === IRC 'refactor'
🎉 === Central Slack org

cc @nodejs/tsc @nodejs/ctc @nodejs/evangelism

Activity

  1. mLuby commented on Jan 24, 2017

    @mLuby

    Have you looked at the cost of running a large slack org?
    If you aren't paying for it, you'll quickly hit the message limit where old messages disappear so quickly it's more or less snapchat. It's frustrating for conversations lasting longer than a few days.

  2. MylesBorins commented on Jan 24, 2017

    @MylesBorins
    Contributor
  3. hackygolucky commented on Jan 24, 2017

    @hackygolucky
    ContributorAuthor

    Hah @MylesBorins I had to change the reaction emojis because I'd forgotten they limit the emojis severely for reactions vs. comment usage. But 🐨 4 life!

  4. hackygolucky commented on Jan 24, 2017

    @hackygolucky
    ContributorAuthor

    @mLuby Excellent question and one that I'll update above. We are not going to be using a paid Slack org. Other non-profits we've talked to that have as large of a userbase as us and have tried have run into exponential cost increases, even with the severe non-profit discount Slack provides upon application.

    I agree that the otherwise ephemeral nature of disappearing history can be problematic. That's why a suggestion for alternative logging(can be used via an IRC bridge/logging) was mentioned to me. It's important for the moderation group as well. Implementation details are important to consider. Thanks.

  5. ChaosTheCorax commented on Jan 24, 2017

    @ChaosTheCorax

    And for those that really prefer IRC you can integrate it into Slack!

    https://github.com/ekmartin/slack-irc

    Obligatory relevant XKCD comic: https://xkcd.com/1782/

  6. boneskull commented on Jan 24, 2017

    @boneskull
    Member

    Was wondering if Gitter had already been considered, and is no longer on the table for reasons?

  7. hzoo commented on Jan 24, 2017

    @hzoo

    A suggestion was made for alternative logging(can be used via an IRC bridge/logging)

    Might be relatively easy to setup alternative logging: for Babel we use http://babeljs.slackarchive.io/development/ for a searchable archive of slack channels.

  8. bnb commented on Jan 24, 2017

    @bnb
    Contributor

    @hzoo Having IRC logging + slackarchive.io would be a nice double buffer. 👍

  9. hackygolucky commented on Jan 24, 2017

    @hackygolucky
    ContributorAuthor

    @boneskull My experience as a community organizer with Gitter is that it is very similar to Slack but hasn't been able to engage folks in the same way. I know a lot of orgs who have really enjoyed it. I actually -like- Slack's ability to gate via a signup, for the reason I mentioned above(agreeing to community guidelines upon entry). Also, the one-to-one relationship for repo to chatroom in Gitter has always felt very inflexible to me. What I worry is that we'd have conversations stuck in a room that might be better suited in a place that doesn't have a repo directly attached(or maybe multiple would suit it).

    I did consider Gitter here in the research, but there's a lot of folks using Slack and IRC right now in Node.js and userland(Gitter is close, too). Maybe my anecdotal experiences colored that approach.

  10. Fishrock123 commented on Jan 24, 2017

    @Fishrock123

    Some thoughts:

    Due to limits on unpaid slack orgs, custom logging will be necessary for both. Searching the logs will end up fairly similar for both options.

    For this option to work, the moderation policies in current existence for IRC would need to be refactored and pull requested into the nodejs organization as part of a guide for the Code of Conduct. The current policy does not handle online, year-round communities comprehensively.

    This is required for either option. The CoC does not appropriately handle moderation methods within realtime chat.

    Open by default--We will set up an open sign-up to allow for anyone who would like to participate in the Slack to do so. This sign-up also allows us to gate participation in the community ONLY by requiring participants to agree to adhering to the Code of Conduct.

    Since sign-up is required, it can be more difficult for abusers to cloak themselves under another name and continue to be toxic in a community that is gated.

    These are largely IRC misnomers. IRC is just a protocol; you can do anything communications related with it. We could implement the same things with some website and backend tooling, and an IRC bot.

    Also, IRC has many ban (and mute) options. I am very sure that you cannot cloak though most of the best practices uses of those options. If we combined that with signup, there is definitely more moderation options on a technical level, not less. Whether having more options is good or bad is something to be left up for debate.

  11. Fishrock123 commented on Jan 24, 2017

    @Fishrock123

    Also I do not think the options have been explored enough to actually vote on it yet.

  12. nebrius commented on Jan 25, 2017

    @nebrius
    Contributor

    These are largely IRC misnomers. IRC is just a protocol; you can do anything communications related with it. We could implement the same things with some website and backend tooling, and an IRC bot.

    Also, IRC has many ban (and mute) options. I am very sure that you cannot cloak though most of the best practices uses of those options. If we combined that with signup, there is definitely more moderation options on a technical level, not less. Whether having more options is good or bad is something to be left up for debate.

    I'm not particularly knowledgeable about freenode, but would this require that we run our own IRC server, or does freenode support required signup/integration with GitHub? If it's the former, how much engineering/devops effort do you think this would require?

    I could get behind this approach, given the added flexibility for signup/moderation/accountability. This despite me being a Slack person, not an IRC person ;-).

    Also I do not think the options have been explored enough to actually vote on it yet.

    I think the voting above is more to gauge interest than a final deciding vote, correct @hackygolucky?

  13. jasonrhodes commented on Jan 25, 2017

    @jasonrhodes

    Correct me if I'm wrong, IRC folks: if I want to stay connected and be able to get pinged by highlight words or read back scroll later, I either need to set up my own znc bouncer or pay $5/Mo for irccloud, right? (Not sure if there are free easy alternatives to irccloud.)

    I come from the perspective that IRC users can use their existing setup to connect to a Slack team, which isn't true the other way around. For that reason and the bouncer thing I mention above, if you can figure out logging I can't really see a good reason to not try Slack.

  14. Fishrock123 commented on Jan 25, 2017

    @Fishrock123

    I'm not particularly knowledgeable about freenode, but would this require that we run our own IRC server, or does freenode support required signup/integration with GitHub? If it's the former, how much engineering/devops effort do you think this would require?

    I could get behind this approach, given the added flexibility for signup/moderation/accountability. This despite me being a Slack person, not an IRC person ;-).

    I think this should be possible on freenode alone. Keep in mind freenode sign-in is already required for #Node.js, but we can easily expand to make it so that either voice or join permissions are gated in some outside way.

    I'm not 100% sure if that is acceptable in freenode TOS but I don't think anything would be strictly against it.

    As for hosting our own? I really have no idea.

    Correct me if I'm wrong, IRC folks: if I want to stay connected and be able to get pinged by highlight words or read back scroll later, I either need to set up my own znc bouncer or pay $5/Mo for irccloud, right? (Not sure if there are free easy alternatives to irccloud.)

    I'm not sure slack pings stay once the history goes either? I'm a bit worried that this will happen anyways. :/

    I suppose if we ran either a proxy or a custom irc server we may be able to serve (some?) history even if that is counter to most IRC.

    A bot could also solve this, it could just search the logs since your last login and forward you the messages.

  15. mikeal commented on Jan 26, 2017

    @mikeal
    Contributor

    I'd like to hear some perspective from the current IRC moderators. That has been a huge task that they've fulfilled for years and they probably have some critical perspective on all this.

    I also don't think it's very productive to bounce around a bunch of our own personal favorite tools and workflows when they are unlikely to be representative of our 7M user, and growing, community.

    A little lost in all the back and forth here is some of the context of "where we are at now."

    IRC

    Our IRC channel has been open since the project started but has never truly been "under" the core project. The policies have been created and iterated on by the moderators. For mostly historical reasons I believe @isaacs is still the "owner" and has said more than once that he'd like to hand this off.

    IRC has had its ups and downs. It's the first point of contact for a particular developer profile and as a result requires a lot of education, both technical and behavioral, and that burden has fallen on the moderators, some of the hardest working people in the Node.js community who get very little credit for their service.

    We've heard from both users of IRC and from moderators of IRC that they need help and support to keep up with our growth. We've heard from other users that there is a lot of additional unmet demand for another entry point without a lot of the technical hurdles or IRC.

    That said, there's only so much any person or institution can do here. The foundation doesn't have the resources to tackle more than one of these problems and the impression I've gotten from some of the moderators is that without support IRC may devolve into an unusable state (similar to the Node.js mailing list, how is that still a thing?).

    IMHO

    Taking off my foundation hat for a moment so I can give a bit of my personal opinion based on my history with the project and with open source.

    My view here is that neither road looks good long term. IRC is being slowly replaced for people new to development and is addressing an ever shrinking market.

    Slack is a brilliant tool but doesn't seem interested at all in supporting public forums. To even have a usable experience you have to run a service to auto-invite people to the network (ironically this runs Node.js and was written by @rauchg). Being that Slack is younger than Node.js and I've seen many similar companies come and go, I'm skeptical that the experience of public forums is going to improve given zero signals from Slack that it's a priority. I have a hard time justifying investment in a use case that just isn't a priority for a well capitalized company, if they cared they have the money and resources to work on it so they've clearly decided that they don't care, and why should they, all of their money comes from other use cases.

    So where does that leave us? We either double-down on a technology that by most indicators is falling away or invest in a service that doesn't really want us.

    I'm also skeptical of investing in silos, networks that we build from the ground up for "our" community which will predictably grow more distanced from the rest of the community that evolves around JS, open source and the web generally.

    Meanwhile, there's a massive amount of Node.js users trying to get help on Stack Overflow and we have no official presence there and are spending no effort to improve the quality of support people are finding there.

    I think it's worth asking "where are our users already trying to get help" before trying to build entirely new forums from the ground up. It's also worth trying to connect whatever we invest in with the broader community of web technologies that we are intertwined from CSS to IoT.

  16. 59 remaining items

  17. joepie91 commented on Apr 15, 2017

    @joepie91

    Github is a proprietary tool that we all use because its simply more communicative than hosting a own repo somewhere.

    I believe the reason is rather different: the network effect. From a convenience point of view, GitHub is rather limited and awkward... but it's where the developers are.

    And even in this scenario of using it out of necessity, the proprietary nature of GitHub still regularly causes problems for many projects (including Node.js, if I'm not mistaken), especially in the areas of project management and dealing with problematic users.

    It would be a terrible idea to add another proprietary uncontrollable component into that mix, if it's not absolutely necessary. The "freedom" aspect of open-source isn't just a feature bulletpoint, it has very real consequences.

    You can develop custom clients with IRC but I have yet to see a goo IRC client for mobile phones.

    It's never too late to build one :)

    And realistically, with #Node.js being a channel about programming, the bulk of the users is not going to be on a mobile device, but rather on a workstation of some variety. Programming on a mobile device is not really a viable long-term idea.

    While it's a good idea to support mobile devices in such a custom webclient, I would therefore not consider it a priority.

    Also in response to IRC I would like to mention: https://irc.gitter.im

    Yes, I use Gitter's IRC bridge out of pure necessity, because some projects have decided to move their channels there. It's "unpleasant to use", to say the least (why does it PM every user every time the server restarts, and constantly send WHO commands?), and it doesn't solve the problem of lacking control for channel moderators.

    Tab-complete is also totally broken, because the userlist is incomplete, and this makes it very irritating to have conversations with people - especially when a channel is busy, and you want to address a specific person, so that your message doesn't get lost.

    It's not really viable for serious extended use.

  18. nebrius commented on Apr 15, 2017

    @nebrius
    Contributor

    @joepie91 we've been considering a custom IRC deployment, although unfortunately the effort seems to be stalled right now (cc @emilyrose). Check out #19.

  19. joepie91 commented on Apr 15, 2017

    @joepie91

    @nebrius Aha, I thought that was just about running a custom server, but on a closer read, it indeed also addresses the concept of a webclient.

    I feel like it may be better to approach the webclient idea separately, since that can work with the existing IRC channels, which means server infrastructure won't be a blocker for that. Any additional features (think GitHub-based login) can be added onto it later, if the idea of a custom server/network turns out to be viable.

  20. MylesBorins commented on Apr 15, 2017

    @MylesBorins
    Contributor
  21. martinheidegger commented on Apr 16, 2017

    @martinheidegger

    but it's where the developers are.

    The point about communication is that you want to remove friction and all tools are

    it has very real consequences.

    Indeed, no arguing here. If IRC and its users were even closely aware how uncomfortable it is to use then companies like Slack or Gitter wouldn't exist. Because the consequence of IRC would be that many people don't even start talking.

    It's never too late to build one :)

    Go ahead, nobody stopping you 😉; meanwhile Slack & Gitter work.

    the bulk of the users is not going to be on a mobile device, but rather on a workstation of some variety.

    During my commute, or in other vacant times, I am using mobile clients like Gitter to catch up on communication. (So do many others imho.)

    It's "unpleasant to use"....
    ... why does it PM e...
    ... Tab-complete is ...

    The IRC bridge is Open source: https://github.com/gitterHQ/irc-bridge (and written in Node.js). PR Welcome?!

  22. nebrius commented on May 22, 2017

    @nebrius
    Contributor

    I'm removing cc-agenda from this issue because the discussion is going well in GitHub.

  23. ChALkeR commented on Jul 5, 2017

    @ChALkeR
    Member

    Gitter is now open-source (MIT licensed), can be self-hosted, and can also operate as an IRC server.

  24. bnb commented on Jul 5, 2017

    @bnb
    Contributor

    @ChALkeR Seems like a very good option, if that's the case.

  25. MylesBorins commented on Jul 5, 2017

    @MylesBorins
    Contributor
  26. bnb commented on Jul 5, 2017

    @bnb
    Contributor

    @MylesBorins If that's the decision the Community Committee as a collective has come to, then this issue should be closed.

  27. nebrius commented on Jul 5, 2017

    @nebrius
    Contributor

    @bnb, as I stated in another thread, this wasn't CommComm's decision to make. Rather, our purpose here has been to facilitate discussion with the broader collaborator base.

    Since the consensus so far seems to be to not centralize communication mediums, as @MylesBorins pointed out, I do think that yes, this issue can be closed.

  28. jxm262 commented on Jul 5, 2017

    @jxm262

    @MylesBorins Sorry, I wasn't aware of any collaborator summit's. But I actually like this decision you mention -

    I do not believe we should be focusing on centralizing communication. There
    are many avenues that already exist

    There are two problems, moderation and support.

    As someone who feels partly responsible for moderating the admittedly "unofficial" slack group, is there any way our group can get trained/involved in the correct process+procedures? I'd like to think that even if we don't have the actual blessing of the Node committee, we could still use your guidance or can help provide input (after all we have +3,300 members in the slack group).

  29. williamkapke commented on Sep 11, 2017

    @williamkapke
    Contributor

    FYI: the slack registration is now at http://nodeslackers.com

    (was: nodeslackers.io)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions