You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Repository navigation
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
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
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.
On Tue, Jan 24, 2017, 11:38 AM mLuby ***@***.***> wrote:
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.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAecVwnLdTZdLM6xiCPjn2HvVfhjFKmBks5rVlM8gaJpZM4Lsmr0>
.
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!
@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.
@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.
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.
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?
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.
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.
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.
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.
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.
@joepie91 we've been considering a custom IRC deployment, although unfortunately the effort seems to be stalled right now (cc @emilyrose). Check out #19.
@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.
The idea I personally most excited about is not trying to centralize
communication channels by rather distribute best practices for moderation
and community management. When it comes to the question of support I think
it should be solved independently. Nodejs/help is a good first pass at a
persistent support channel... although we do need to be able to make it
seamless to transition to real time chat.
On Sat, Apr 15, 2017, 6:01 PM Sven Slootweg ***@***.***> wrote:
@nebrius <https://github.com/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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAecV0tVbW3JaaXJZhLM1gdQwJszUJBSks5rwT47gaJpZM4Lsmr0>
.
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 ...
I'd like to reiterate a conclusion we had during the last collaborators
summit
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.
We should train existing spaces on moderation and only officially promote
those that we have trained.
Better support is a completely different problem all together that we
should consider solving from first principles using tools made for better
support
@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.
@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).
Reacted by Tierney Cyren, Richard Littauer and Alexander Tesfamichael
Activity
mLuby commentedon Jan 24, 2017
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.
MylesBorins commentedon Jan 24, 2017
hackygolucky commentedon Jan 24, 2017
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!
hackygolucky commentedon Jan 24, 2017
@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.
ChaosTheCorax commentedon Jan 24, 2017
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/
boneskull commentedon Jan 24, 2017
Was wondering if Gitter had already been considered, and is no longer on the table for reasons?
hzoo commentedon Jan 24, 2017
Might be relatively easy to setup alternative logging: for Babel we use http://babeljs.slackarchive.io/development/ for a searchable archive of slack channels.
bnb commentedon Jan 24, 2017
@hzoo Having IRC logging + slackarchive.io would be a nice double buffer. 👍
hackygolucky commentedon Jan 24, 2017
@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.
Fishrock123 commentedon Jan 24, 2017
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.
This is required for either option. The CoC does not appropriately handle moderation methods within realtime chat.
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.
Fishrock123 commentedon Jan 24, 2017
Also I do not think the options have been explored enough to actually vote on it yet.
nebrius commentedon Jan 25, 2017
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 the voting above is more to gauge interest than a final deciding vote, correct @hackygolucky?
jasonrhodes commentedon Jan 25, 2017
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.
Fishrock123 commentedon Jan 25, 2017
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.
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.
mikeal commentedon Jan 26, 2017
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.
59 remaining items
joepie91 commentedon Apr 15, 2017
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.
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.
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.
nebrius commentedon Apr 15, 2017
@joepie91 we've been considering a custom IRC deployment, although unfortunately the effort seems to be stalled right now (cc @emilyrose). Check out #19.
joepie91 commentedon Apr 15, 2017
@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.
MylesBorins commentedon Apr 15, 2017
martinheidegger commentedon Apr 16, 2017
The point about communication is that you want to remove friction and all tools are
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.
Go ahead, nobody stopping you 😉; meanwhile Slack & Gitter work.
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.)
The IRC bridge is Open source: https://github.com/gitterHQ/irc-bridge (and written in Node.js). PR Welcome?!
nebrius commentedon May 22, 2017
I'm removing
cc-agendafrom this issue because the discussion is going well in GitHub.ChALkeR commentedon Jul 5, 2017
Gitter is now open-source (MIT licensed), can be self-hosted, and can also operate as an IRC server.
bnb commentedon Jul 5, 2017
@ChALkeR Seems like a very good option, if that's the case.
MylesBorins commentedon Jul 5, 2017
bnb commentedon Jul 5, 2017
@MylesBorins If that's the decision the Community Committee as a collective has come to, then this issue should be closed.
nebrius commentedon Jul 5, 2017
@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.
jxm262 commentedon Jul 5, 2017
@MylesBorins Sorry, I wasn't aware of any collaborator summit's. But I actually like this decision you mention -
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).
williamkapke commentedon Sep 11, 2017
FYI: the slack registration is now at http://nodeslackers.com
(was: nodeslackers.io)