Central communication medium for chatting in Node.js about community-committee HOT 86 CLOSED

One concern that I didn't address in my initial post revolves around hypothetical accessibility concerns of IRC. I'd like to address that now:

https://webchat.freenode.net/
https://www.mibbit.com/
https://kiwiirc.com/

I spent 20 seconds googling "web IRC client" and found 3 well-known and reliable options.

None of these options require downloading a new application.
None of these options require the use of proprietary APIs or protocols (RFC 1459).
None of these options require the user (or maintainer) to spend money on licensing.
None of these options require any specialized knowledge of IRC.

None of these options require doing anything but opening a browser.

All of these options can be adopted to provide an accessible, extensible & low-barrier entry into our community.

To be perfectly honest, I'm alarmed by the fact that we're actually having this discussion. We are the folks who cunningly wrested our precious project from the grasp of its former corporate handlers for the sake of the community at large. Why are we now clamoring for a trendy "solution" that provides less freedom, less accessibility, and less potential for growth?

I get that we all love to use Slack for collaboration between members of our latest startup/local meet-up/special-interest group. That does not make it a panacea. That does not make it appropriate for a use-case that is explicitly unsupported by its creators.

Please, think of the needs of those who haven't already been sublimated into the cult of JS. Not just what is most convenient for you in your daily routine.

We owe it to them to hold the door open.

from community-committee.

FWIW, the programming language Rust is also having this discussion right now:
rust-lang/rfcs#1865

i think this comment by a contributor who happens to be blind is worth reading, so i am cross posting:

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.

from community-committee.

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

from community-committee.

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.

from community-committee.

tl;dr— I'd like to express my strongly-held opinion (based on years of experience) that a "public" Slack will be deeply problematic for the long-term health and success of our community. I believe that IRC remains the only free and open option that has the capability of adequately serving our community's needs.

Slack has made it clear that their current goals do not align with the needs of those who use Slack as an "open" community platform. They do not provide adequate tools for fair moderation in a community setting, and—to the best of my knowledge—they currently have no plans for doing so.

This leaves Slack community administrators/moderators with no recourse other than wholesale exclusion of individuals who violate CoC, which is heavy-handed at best; if not harmful.

IRC has been and continues to be a valuable resource for many people in our community. There is a wealth of diverse individuals who already contribute their time and expertise for free on an ongoing basis to anyone who comes to the existing Node.js community support channel with questions. Over the years, individuals who initially came seeking help have become trusted experts who now help others.

With additional resources and commitments from key individuals, our existing community support channel can provide much more value and transparency than anything we can do with Slack's current offering.

I am happy to participate with any efforts to improve & support our IRC-based community efforts.

from community-committee.

from community-committee.

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/

from community-committee.

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.

from community-committee.

Just now jumping into the conversation per invite from @williamkapke

Yes, I created a Slack group a long while back (over a year or two ago???). It's completely free, I take no credit, everything is completely community-driven. I've done no advertising or promotion and yet we've somehow amassed ~2,500 members.

Couple of thoughts to respond to the above discussion -

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)

• We've already tried this once, as one of our members was nice enough to create an integration/bridge between irc and Slack. Mostly the irc community got annoyed at us (seemingly because we were crossing communications somehow), and vice-versa , our community was getting annoyed at an irc channel being flooded with banter talk taking up our Slack discussion thread limit. Because of this, the group decided to eventually kill the integration.

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.

• Yes and it's free (even at our size). The message limit is currently a rolling 10k. I'm involved in a few slack groups bigger than the node.js one and this limit isn't really an issue. As mentioned above, the only time this has ever created an issue is when we had a bot bringing in the irc discussions which filled our limit up too quickly.

The number was 7.5K. Is there a reason no one here is concerned about this? I was active in the node community for months until I discovered the unofficial NodeJS Slack group (2.5K members) and fear joyously imagine, actively advertising a Node.js Slack group could very well push it to ~7K.

• Slack has never had a "stated limit" afaik. But since the whole Reactiflux-Discord thing, I've heard (anectodally) Slack has been much more lenient on the actual membership number. The FED (front end devs) group I'm in currently has close to 10k members, another I'm in has nearly 8k. We're at 2.5k currently in Node.js, if we approached ~7k, I plan to try reaching out to Slack. And if I don't get a response we'd probably look to start pruning inactive members (after sending some reminder emails).

I'm not here to upvote/downvote a Slack option for an official chatroom, just wanted to give some context. The entire concept was created by me while coding in a coffeeshop and wanted something more "real time" discussion. Many devs I know (including myself) use Slack daily, so it just made sense to make a group there. It quickly blossomed into a community and I make a point to make sure that I alone am not in charge of anything (it's all community driven).

Anyway, I'll keep paying for the registration page domain, I'll keep contributing on conversations when I can, but if anyone from the Node.js official community would like to get involved/help-out, you're more than welcome :)

http://nodeslackers.io is the registration page - if you want to join and discuss anything

from community-committee.

@MylesBorins we could also embed an IRC client which addresses all of the accessibility concerns surrounding the use of IRC.

from community-committee.

That overlooks the network effect though. Freenode is like GitHub: everyone who's into open source is on it. /join #<random-project> has better than even odds of joining that project's official channel. Starting our own little walled garden means many people simply won't bother.

from community-committee.

(I do think experimenting with Discord could be a good idea, though.)

There's a cost to having up these channels and not having enough people in them to give quality responses. If we can't do better than what is already on Stack Overflow we shouldn't be putting something up. Does anyone remember the Node.js Mailing List?

from community-committee.

I'm all for experimenting with new technologies and platforms but for this something tried and true is needed. We should limit the choices to:

1. A slack org
2. Freenode IRC
3. Self-hosted IRC

If I may, I'd like to call for a raise of hands on these options... perhaps list your preferences in order. For me, the order would be: 3, 1, then 2.

from community-committee.

If we decide to go with Slack, @zeit can sponsor free hosting of the Slackin inviter 👌

I'd like to cast my strong vote for Slack for a simple reason: it's what a huge number of people are already using. The ability to switch to the Node.js org with one click would dramatically boost participation. It's akin to having a conference room in your physical office where the entire Node.js community hangs out :)

from community-committee.

Strong vote from me against anything proprietary, whether Slack, Discourse Discord, or otherwise. Aside from the ethical concerns, this introduces serious limitations in accessibility - no serious possibility to develop custom clients for impaired/disabled users, for example. Further, it would reduce the control that channel moderators have over the environment.

Given that bouncers, IRCCloud and and webchat clients have all been brought up at some point in this thread, it kind of surprises me that nobody seems to have suggested the idea of running a custom IRCCloud-like bouncer/client service, free of charge, for use with the Node.js channels.

This would:

• Require minimal maintenance - IRC is well-understood and has remained effectively unchanged for a decade. Once done, it's pretty much done forever.
• Be a relatively small amount of work - there is already a lot of tooling for dealing with IRC, including in the Node.js ecosystem.
• Not negatively affect accessibility for regular IRC users, who can still connect to the network directly.
• Solve the problem of accessibility for new, non-IRC-savvy users.

Whether a custom IRC network is involved is pretty much irrelevant as far as the users are concerned, since it's all just IRC. The only thing a custom network would change at that point, would be that it gives channel moderators more possiblities for implementing custom community management features. I also suspect that Freenode would be open to supporting such a service (eg. by adding a WebIRC block).

Would this not be the best of both worlds?

from community-committee.

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

from community-committee.

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

from community-committee.

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.

from community-committee.

@alextes that's a nice comparison chart but since it's from 2015 I think it's missing an option that might be one of the best ones out there: Matrix. In combination with the Riot.im client it's accessible and ticks almost all the boxes in the chart. ✅

This means it's usable from mobile and desktop, is open source, has history search, free to host, roles, markdown support and tons of bridges. It would be a shame to leave Matrix out of the discussion.

from community-committee.

@emilyrose - incidentally, Rust does this now. When you click on the Rust beginners IRC link on the website it takes you to: https://client00.chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust-beginners

from community-committee.

@jonathandturner this is great! I want to make this happen for Node.

from community-committee.

Cool @nebrius can you start a separate issue referencing this issue there about that prototype, the planning, and who is doing it?

from community-committee.

hi! i would like to strongly voice an opinion against anything that requires more maintenance or code. i think the question of whether we have enough moderators for a pre-existing solution nullifies the idea of adding even more work.

i think anything that is beyond Slack or Freenode IRC should really be considered not in scope.

from community-committee.

If we're going to experiment with something we should set a timeline to evaluate how it has done and decide whether or not we want to continue. It's easy to start these things and then forget about them, maybe we should check back in 6 months?

from community-committee.

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.

from community-committee.

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?!

from community-committee.

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.

from community-committee.

from community-committee.

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!

from community-committee.

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

from community-committee.

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

from community-committee.

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.

from community-committee.

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

from community-committee.

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?

from community-committee.

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.

from community-committee.

As a community organizer(and the main reason I ended up supporting Slack as an option) was that it has a demonstrated a growth and persistence in community that I've seen dwindle in IRC. Where I've seen IRC channels/communities turn into crickets over the last 4 years, I've seen Slack channels explode and remain a vital/immediate parts of the online community world. This is about finding a common space where our users already exist. There are tons of Node.js IRC channels and many Slack orgs that are spread far and wide.

In Freenode #Node.js' case, there are -so- many people it can be difficult to ask a question and keep a thread going. In this case, the user experience provided by Slack orgs is really helpful. They can see all of the channels we provide easily in a list and could have much more topical channels to help alleviate the-kitchen-sink channel. Someone new to the Node.js chat experience has to dig, currently, to be able to find channels in IRC or Slack because they aren't listed in one place. I'm not going to make a case for threads in Slack because it's new and meh.

I can hop into my #boro.js Slack org right now to ask a Node.js question and get a really great quality answer. I can go into #node-dev on IRC and have a really sharp person respond to me quickly with some esoteric quirk that I didn't know about and will save me banging my head against a wall for hours. A lot of folks -don't- have these networks yet.

Stack Overflow is an important and very separate issue, though a good one(and not a chat service which was implied but not explicitly stated as to what we are focusing on here). Maybe open that as a separate issue? We have no domain and application of the Node.js code of conduct over how people collaborate/behave on Stack Overflow, so as a community organizer and protector of community experience, I tend to not send folks there unless I feel there is no other choice. I can't guarantee a nice experience there. I can help work on that experience within our community(and our IRC moderators have done a really incredible, thankless job it that over the years).

Again, I think there are pros/cons of both. I just want to know where we can find common ground. I think one of the two works for that. Otherwise, we're bikeshedding forever and continue to have folks having to rely on whatever more-local/project-specific group they discover on their own. For many folks in smaller towns and not networked well, is not a great experience. As for worry over having to switch technologies, we work in Node.js. Everything is ephemeral. We have to learn new technologies every week. It's worth the effort if we take the time to weigh and get input, and it comes out having more value to invest in one than throw up our hands and wait for something else to fix itself.

from community-committee.

I agree with @mikeal that a Slack's treatment of "public" access--in other words, there is no such thing--is problematic. It won't change soon, if ever. Registration increases friction.

Slack is also nonfree, which may concern some (Hi GitHub!).

But contrast that to a new user configuring their IRC client. What server do I use? Should I use encryption? What do the symbols mean next to people's aliases? Why can't I talk in this channel? Who is NickServ? What's IDENT? How do I send files? How do I send a PM? Why are people grousing at me for PMing them?

If Slack registration is a fingernail scratch, then learning how to use IRC effectively is road rash. 😝

It's important to recognize Slack's disadvantages, but IMO the advantages are overwhelming.

from community-committee.

It's important to recognize Slack's disadvantages, but IMO the advantages are overwhelming.

No, Slack limits are very restrictive. For a relatively small «public» Slack with 184 active members, there are issues with the history — it lasts for about 8-9 days. That might look enough on a first glance, but in fact that means that only 2-3 messages of backlog are preserved in slightly less popular channels (I'm looking at a real setup right now). In fact, some of the rooms got all history deleted and don't have anything to show when one opens them.

That community I am talking about had to setup a separate logger to extract logs and are thinking to migrate somewhere else from Slack (they had Mattermost in mind, but they told me it's not ready for their usecase yet for some reason, I don't remember the details).

I expect that the Node.js community, given that there would be many rooms, will be much larger than 184 active members.

from community-committee.

If you want to look at (or even join) some current Slack communities around large open source projects to get a feel of what works and what doesn't, there's a useful list at https://medium.com/@angiecois/an-incomplete-list-of-communities-on-slack-1b1b6f157bda#.3kcgdvdte.

I've heard the message history thing is definitely a problem for the EmberJS Slack. I can't imagine the how bad the issues with that must be for the WordPress Slack (unless they're somehow not on the free tier).

Anyway, not advocating for Slack or arguing against it. Just providing some info. I'll see myself out. Thanks!

from community-committee.

Just for more info as well: I already mentioned this above but Babel has been using Slack since June 2015 and SlackArchive since August and I think it's been pretty great (on a free tier). I believe we have ~5000 registered and ~300 active?

from community-committee.

@ChALkeR If we're talking "free" tier, retaining messages would be an issue w/o 3p addons. As @hzoo wrote, there are options available.

As a non-profit, I imagine the Node.js Foundation would qualify for the cheaper non-profit pricing structure (though if that is based on # of users as per usual, it's pointless).

An IRC channel archive would be requisite anyway, since IRC doesn't "retain" messages, so this argument feels moot.

from community-committee.

I agree with @emilyrose: moderation in Slack would be awkward at best; I hadn't considered this. That's a major problem, and maybe a deal-breaker?

Yet, IRC is also unwelcoming; it's difficult and antiquated compared to a Slack. IRC won't become easier to use. It won't become more popular. But it probably won't go away soon.

OTOH, Slack could further restrict or kill the "free" tier entirely. We'd be at the whim of whatever Slack chose to provide or not provide.

Neither of these tools are suitable, but we're already using one of them, so we might as well maintain the status quo. Please subtract 1 vote for Slack. 😉

from community-committee.

Something I realized after a little more thought is the utility of being somewhat silo'd and why that has probably been a good thing for so many of these communities, but is somewhat inaccessible for us.

In particular, diversity oriented communities on Slack have done quite well. In those cases, creating a new space that is disconnected a bit from the rest of the open source ecosystem allows them to create a space that is easier to access and can set new norms for behavior.

Unfortunately for the Node.js project we don't really have this luxury. The problems of the open source world at large are our problems, we don't really get to remove ourselves from them, we're the people responsible for changing them. It's our responsibility to create a forum for a 7M user community that is expected to double again in the next year. Any and all problems that happen at an ecosystem of that scale are our problems to solve.

@emilyrose's comments are particularly resonate with me in this context. If the goal of a Slack presence is to appeal to more users then how will we manage that effectively without the tools we've been using to manage the existing community on IRC which, if the Slack hypothesis is correct, is smaller than this eventual Slack community?

from community-committee.

Has anyone contacted a decision-maker at Slack about our use case? Historically, they haven't catered to open communities, but that doesn't mean they wouldn't work with Node.js to solve our problem (unless they've stated as much already).

from community-committee.

@boneskull

An IRC channel archive would be requisite anyway, since IRC doesn't "retain" messages, so this argument feels moot.

No, for IRC, I have logs inside my client and can search those and go back, on any channels I joined. That doesn't work that way for Slack — it looses the logs for the conversations I participated in.
There are thirdparty options like a separare log, though.

Using a separate log (like those for IRC or like those doable for Slack) is less convenient than in-messenger logs, though separate logs are a must have for both those setups (IRC and Slack).

from community-committee.

First, a strong vote for Slack over IRC. I feel IRC compared to Slack is far too hard to use for the average developer. If accessibility is an important goal, I say IRC is a bad option. I've used IRC on many platforms over the years, and some of the basics of digital communication are still much harder compared to alternatives such as Slack. The big ones for me are search, secure sign-on, offline communication, and notifications. e.g. I think everyone wants an IRC bouncer, yet only the people voting here will have them. Something I hope you will all keep in mind.

That said I'd also much prefer something that isn't controlled by one for-profit corp. Slack and IRC are the big two and taking on something less established has a big downside with regards to adoption. Still, I notice myself agreeing rather strongly with @mikeal in that neither seems a great option. If at all feasible I wouldn't mind a third option at this point.

There's also a question I'd like to pose to all of you. Recently the React community switched from Slack to Discord. They wrote down their reasons on the React blog. The TL;DR:

Slack decided that Reactiflux had too many members and disabled new invites.

The number was 7.5K. Is there a reason no one here is concerned about this? I was active in the node community for months until I discovered the unofficial NodeJS Slack group (2.5K members) and fear joyously imagine, actively advertising a Node.js Slack group could very well push it to ~7K. Has the Node Foundation already been assured by the Slack team the situation won't be the same for Node.js?

from community-committee.

Ping: @jxm262
...who, I believe, created & maintains the existing NodeJS Slack group. Perhaps he could share some valuable thoughts there.

Also- it has been advertised on http://nodeirc.info (which is in the topic of the IRC channels) for a long time as well as the list of existing Node IRC channels.

from community-committee.

@emilyrose after giving your initial post another read and seeing jxm262's reply I'm taking back my vote for Slack. I share some of your concerns. Slack seems less free, it's sole option for banning harsh, and knowing there are also large communities that didn't feel forced to leave does little to reassure me personally. Slack has different goals, and sometimes they seem to clash with ours. I do remain unsure about how to weigh these concerns.

Before the React community switched to Discord Jordan Hawker researched alternatives. His conclusions are on his blog. If the foundation is still open to a third option, it's a good read. The article also makes a strong case for Slack if one discounts the member limit issue Reactiflux faced. There's even a scored comparison chart!.

We (@emilyrose) seem to have significantly differing opinions on what constitutes accessible. Perhaps our subjective experiences differ a lot. In light of wanting to be inclusive<3, I feel accessibility and ease-of-use are of great concern so I'd like to defend my position on this one last time for all those reading along.

We both seem to agree that the barrier to entry should be as low as possible, awesome! You then appear to disregard my stated concerns and in conclusion write:

None of these options require doing anything but opening a browser.

I ask you try and be more understanding before opposing me so strongly.

• The first option you give (webchat.freenode), has no nick coloring by default, does not explain or link how to register at all, and replies to my first message with an in-chat reply "== Cannot send to channel: #Node.js." Luckily on freenode's web chat, the topic is quite prominent. If the user notes the helpful link in there and completes the ~400-word guide, they'll be able to speak a couple of minutes later. Keep in mind this assumes you immediately entered the #node.js channel and didn't start wandering on the status channel.
• Your second option, after some searching around, explains they're not allowed to connect to freenode at all.
• Your third option does the same as the first but has a much less prominent topic. After identifying to freenode's NickServ, this option works okay. Nothing I'd like to use more than once, but it lets me ask my question.

All the previous is just getting text into the channel. After this come the clutter of join/part messages, complicated and ephemeral private messaging, auto sign-in, secure sign-in (SASL anyone?), needing a stable connection or bouncer, search, history, notifications, sub-channels... I could go on. Again, I wouldn't be surprised if many of us have beautifully functional IRC workflows. Many (aspiring) node devs, however, will not. Just joining and asking a question will, in my opinion, be nothing like 'opening a browser.' I also hope we can aspire to more than users stomaching the web clients. Joining our community should feel great - also on sign-up - because it is great! Slack has its issues, but I expect none of them to be as impactful to inclusiveness as the above combined. (Bar Slack limiting our member limit 😅).

I wish I had numbers on developers using Slack vs. IRC, but I do not. Same on how they rate the ease with which they can drop in on a community platform with IRC vs. Slack.

Here are some numbers we do have. The Node.js getting involved page links the IRC channel directly and makes no mention of the Slack group. There's about ~1k users in the #node.js channel. There's about ~2.3k users in the Slack group. Keep in mind these numbers are quite unsubstantial without looking at how many are inactive, how long both have been around, etc., etc.

So let me restate: If inclusivity<3 is what we want, and accessibility - and to a lesser extent ease-of-use - are important facets, I say IRC is a bad option.

I feel a tad unconstructive just adding to the cons over here 😓. I'll finish by expressing my hopes in finding and agreeing on ways to work past the concerns we have for Slack or finding a third option. Can't wait to see new faces pop up wherever!

from community-committee.

At this point in time, I think there are enough negatives for Slack that to me make it a non-starter. On the other hand, it seems that IRC can do everything we need it to do, but the downside is that it has a stiff barrier to entry for non IRC users.

Perhaps what we need is a guide to using Node's specific IRC setup, along with a "best toolset" guide that leads new users step by step in how to use a specific IRC client that is beginner friendly. I also think that whatever tool we pick needs to make "online/offline" seamless, as Slack does. (Needing to configure a bouncer is a non-starter IMO).

from community-committee.

from community-committee.

Once upon a time USENET was a great thing...

Sigh

:-)

from community-committee.

Given the discussion, I'm leaning strongly in favor of IRC over Slack. That said, I do not believe that using freenode or one of the other open services is the way forward. Other organizations, such as the W3C for instance, run their own IRC servers. This is likely something that we should look into.

from community-committee.

Other organizations, such as the W3C for instance, run their own IRC servers. This is likely something that we should look into.

Seems like a lot of effort, perhaps even liability, without obvious benefit. Can you explain what the benefit would be in your view?

from community-committee.

Seems like a lot of effort, perhaps even liability, without obvious benefit. Can you explain what the benefit would be in your view?

Replying to my own question: I suppose if doing so would give us access to robust moderation tools that we wouldn't have with the free services, etc., that could be a significant benefit.

from community-committee.

Another potential benefit would be to be able to make it easier to use than standard IRC.

from community-committee.

It's minimal effort from what I understand (@emilyrose would be far more qualified to speak to the exact requirements tho) and exceedingly little liability. It would primarily only require a few brave individuals willing to manage it. Our CI infrastructure likely incurs far more liability.

The key benefits would be greater administrative control over the environment and flexibility for channel management / archiving.

There's nothing to say that we cannot maintain a couple of freenode channels for general use. An irc.nodejs.org server would be of benefit primarily to Node.js Foundation members, collaborators, etc. Having a private IRC server strikes a nice balance between a near completely walled-off slack garden and the completely open freenode.

from community-committee.

There's nothing to say that we cannot maintain a couple of freenode channels for general use. An irc.nodejs.org server would be of benefit primarily to Node.js Foundation members, collaborators, etc. Having a private IRC server strikes a nice balance between a near completely walled-off slack garden and the completely open freenode.

Agreed. I would love to see, for example, the ability to click a link in the README that automatically brings you in to chat, having authenticated against GitHub, similar to the login flow for gitter. This would also be really helpful if, for example, we end up being targeted by trolls again because we can effectively ban in both spaces. Normally we would not want to ban in both spaces due to the differences in how they operate, but there will be some instances where it's appropriate. That's not something that's easy to do right now.

from community-committee.

So... I wrote a thing.

I've been unhappy with the state of art in public realtime forums for a while and built https://bongbong.chat.

You can put it in a room using a querystring: https://bongbong.chat/?room=nodejs

It's entirely embeddable as an iframe.

Obviously, it's open source https://github.com/mikeal/bong-bong

It's an early project. There are lots of bugs and unanswered questions. But I think I'm done trying to work around issues in IRC/Slack/whatever that are, at their core, a problem with tools that aren't built for and don't really care about our use case.

from community-committee.

I'm just going to point out that developing the moderation solutions suggested in mikeal/bong-bong#1 all seem to be far more work than anything suggested so far.

from community-committee.

@Fishrock123 that issue is out of date.

Initial versions of bong-bong were trying to do everything in a pure p2p fashion.

The new versions uses web sockets and requires an authenticated signer to write any data, which makes moderation pretty simple actually.

from community-committee.

@mikeal why not use Matrix (Riot) instead of rolling your own p2p code.

from community-committee.

Ok so I'm going to address a couple things I saw after reading through the whole thread.

Most of these just end up highlighting reality: IRC is a protocol. It is IRC client's and server's own faults that so much of the protocol is exposed in raw.

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.

I would like to point out that IRC is far larger than it ever has been. Not in IRC client use, of course.

Twitch.tv has probably billions of chat messages every day. It all runs on IRC but, who would know if you didn't interact with the dev api? I think you could actually argue twitch channels effectively have the best IRC client to date.

The big ones for me are search, secure sign-on, offline communication, and notifications. e.g. I think everyone wants an IRC bouncer, yet only the people voting here will have them. Something I hope you will all keep in mind.

I don't have a bouncer.

All the previous is just getting text into the channel. After this come the clutter of join/part messages, complicated and ephemeral private messaging, auto sign-in, secure sign-in (SASL anyone?), needing a stable connection or bouncer, search, history, notifications, sub-channels...

I'm not sure about search but most of these things work just fine on IRC but clients kinda suck and don't do what you'd hope by default. (Besides Bouncers for stable connections)

There's also a question I'd like to pose to all of you. Recently the React community switched from Slack to Discord. They wrote down their reasons on the React blog. The TL;DR:

I had forgot about Discord - it works well for many gaming communities and is directed at open communities. We could disable voice channels too. I'm not certain about moderation but I know it has a good amount of options.

One thing I will note is that Discord does not handle notifications well. It is overly noisy and has poor muting options.

Also idk what paid Discord plans look like.

from community-committee.

It's an early project. There are lots of bugs and unanswered questions. But I think I'm done trying to work around issues in IRC/Slack/whatever that are, at their core, a problem with tools that aren't built for and don't really care about our use case.

So I'm going to re-iterate the Twitch.tv thing, because I sincerely worry that this approaches the problem wrong.

The big problem with IRC is actually using IRC. Because, well, then you're actually using IRC.

Very few of us want to use IRC itself.

But, technically it works well. Again, Twitch.tv serves (probably) billions of messages in tens of thousands of channels daily with full history, incredible moderation tools, integrations (bots, badges, emotes, etc), AND the UI works great for millions of people who have nothing to do with programming or what the chat is made with.

I simply can't see trying to reinvent something that can work at both a small scale and a scale such as that a good thing. IRC has remained alive in these places because it technically works well; not because using it in of itself makes for a particularly great experience.

If we are going to make "our own thing" so-to-say, why not just use the thing that could work all along and make it actually have a good experience? We don't need to call it IRC or anything, but running on IRC would probably save us a lot of work.

from community-committee.

(I do think experimenting with Discord could be a good idea, though.)

from community-committee.

this issue has been going on for quite a while. how can we wrap it up and try something? picking one solution doesn't necessarily drop the potential of exploring others later. i think it's important that we get going on making a decision and seeing how it goes, and then responding to practical feedback we get. thoughts?

from community-committee.

I'd say go for it!
My preference: 3, 2, 1.

I do hope someone who feels strongly responsible for the community reminds themselves to evaluate the taken path in a couple of months. If our member count, looking at the trend, won't ever rival that of unofficial channels, I'd encourage an 'official' initiative to reflect and see if we can't do better. Be it through trying to push for improvements or looking at alternatives.

The unofficial NodeJS slack group sports ~2.600 members after being around for 23 months. I'd applaud the effort to beat this number in two years; I'd suggest the above if we're trending nowhere near it. All should be able to enjoy our great community!

from community-committee.

3, 2, 1 with notes and caveats:

3. Notes on self-hosted IRC:

• Need to find costs
• Research setup details
• Still need to build a usable web irc client that doesn't expose raw irc to end users
• Still need to figure out how we'll manage everything in a multiple channel setting

2. Notes on freenode IRC:

• Still need to build a usable web irc client that doesn't expose raw irc to end users
• Probably need to build a bot

1. Notes on Slack

• Still need to figure out how we'll manage everything in a multiple channel setting
• Need to host an inviter

I think 3 is probably the most work but probably not by as significant as a margin in the long run as it may look.

I also think that using Mikeal's own solution would end us up in an almost identical situation to 3.

from community-committee.

Thanks for the bump, @ashleygwilliams.

This is clearly an extremely important issue for community members. An interesting question brought to me was how we DO finally decide this. I'm not going to make that call. I can't. We'd need some sort of vote, but a simple majority may not necessarily represent what will set us up for success. It's possible the volume of people voting may not have struggled with each of the mediums, the logistics of moderating them, and the problems with onboarding new folks to either. I find that weighing collaborators/moderators of IRC(or Slack if there are any currently)/community-at-large as separate votes may help us figure out the final call.

I think @jasnell's list is a good one to go from, though as @Fishrock123 has pointed out there is certainly some work on any of these. I'd like to create a cross issue for the CommComm and the TSC to figure out the voting mechanism quickly and move it along.

from community-committee.

My preference is 3, 1, 2. (EDIT: to clarify, I think 1 and 2 are about the same and lag behind 3 a fair amount).

I think we should start by experimenting before voting. Option 3 isn't quite a "signup and go" operation, and it's harder to talk about it without something specific to point to.

I think it would be useful to create a prototype before we vote to get a feel for what is involved. I've had some offline chats with @emilyrose and a few others around what that could look like and it sounds like it wouldn't be difficult to create a small scale prototype.

from community-committee.

agree, @mikeal ! one thing that i want to make sure doesn't happen is that #19 is not a blocker for us getting going. we've already been taking quite a while, so i'd love to start something by the end of the month and maybe check in after 3-4 mos. if in the meantime, ya'll want to prototype something sure, but let's get going with solutions that already exist. the communication/moderation story is gonna be the longer/harder part of this and we've already kicked that off in #20. i'd like to make sure we have something for the volunteers to start working with.

from community-committee.

@ashleygwilliams @mikeal Yeah, I think in this case then we'd be talking about voting in the meantime, and if #3 wins, then essentially transitioning folks from Freenode to the self-hosted upon its success as a prototype. If the prototype isn't working out, then we can fall back to what came in 2nd. That's a bunch of ifs ;)

Regardless, I think waiting 6 months for an initial is too long, but that's me making an assumption that that's what you meant.

So, plan is

1. to work out the voting logistics while concurrently building/testing prototype and recruiting/training moderators
2. Vote
3. If vote is

• Freenode IRC: great! we can follow steps to bolster/improve and point community here.
• Self-hosted IRC: we check-in to see what's going with prototype. If it isn't in a place to say the implementation worked out, then we rely on Freenode IRC for the time being and work to improve it. Otherwise, if this is good. it's good and we just move forward.
• Slack: We do all the work required for this to be a success.

Clearly an oversimplification, but a start. The problem with concurrently doing the prototype is that it could potentially not get the most votes due to it being vaporware, depending on the stage its at when voting commences.

from community-committee.

👍 for slack simply because of the large number of existing members (just voted in the top thread). We're already up to >2,500 on Slack now, which is quite a large number of people. And yeah I already host nodeslackers.io, out of pocket, but it could use a UI revamp (sponsorship would be awesome). The cost of hosting on S3 is minimal compared to the recurring cost of the domain.

I'm willing to help contribute wherever needed.

Anyway I'll be in the Slack group if anyone wants to find me or the other admins ;)

from community-committee.

@jxm262 Can you link to that Slack? I'm having trouble finding it. I'd love to talk to y'all(the admins) and see if admins would like to help with moderation, regardless of the medium we result with. And the experiences so far with running that Slack! I've seen a number of the working group slacks, but never that one.

from community-committee.

@hackygolucky sure, http://nodeslackers.io

And yeah that would be cool. We already moderate and have a mini system in place :) It's been around for a while, it's just not integrated into anything "official" with Node

from community-committee.

Just because I felt it is worth noting: The Node.js Gitter channel is already quite active: https://gitter.im/nodejs/node

from community-committee.

I think Gitter is indeed not a bad choice. Comparing them quickly:

IRC: Lightweight, cheap, handles easily a magnitude of users.
Slack: Great styling options (code/quote/bold) which are very efficient when discussing code snippets and discussing longer, more advanced topics. Slack might come with a hefty price and the sign-up / join, has some friction compared to IRC or Gitter. Personally, I am getting tired to be logged into 5+ Slack groups.
Gitter : Combines IRC and Slack quite well. Gitter is a more open channel like IRC but has, in addition, the styling options (code/quote/bold) for discussing code snippets and various topics.

I'd say that the styling options are important, I know many people like to use terminal styles, but when I am having deep conversations about code, I really can appreciate improved legibility of text. I personally can hate a documentation page purely through the "compacted" impression it gives and poor legibility due font and colors.

For that reason, I think Gitter is not a bad 3rd option.

from community-committee.

@joepie91 Github is a proprietary tool that we all use because its simply more communicative than hosting a own repo somewhere. You can develop custom clients with IRC but I have yet to see a good IRC client for mobile phones. Also in response to IRC I would like to mention: https://irc.gitter.im

from community-committee.

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

from community-committee.

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

from community-committee.

from community-committee.

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

from community-committee.

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

from community-committee.

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

from community-committee.

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

from community-committee.

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

from community-committee.

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

(was: nodeslackers.io)

from community-committee.