Central communication medium for chatting in Node.js #11
Comments
|
Have you looked at the cost of running a large slack org? |
|
🐨
…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. |
|
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/ |
|
Was wondering if Gitter had already been considered, and is no longer on the table for reasons? |
Might be relatively easy to setup alternative logging: for Babel we use http://babeljs.slackarchive.io/development/ for a searchable archive of slack channels. |
|
@hzoo Having IRC logging + slackarchive.io would be a nice double buffer. 👍 |
|
@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. |
|
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. |
|
Also I do not think the options have been explored enough to actually vote on it yet. |
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? |
|
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 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. |
|
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." IRCOur 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?). IMHOTaking 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. |
|
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. |
|
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. |
|
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. |
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. |
|
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! |
|
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? |
|
@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. |
|
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. 😉 |
|
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? |
|
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). |
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. 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). |
|
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:
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 |
|
Ping: @jxm262 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. |
|
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/ 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 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. |
|
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 -
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 |
|
@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. |
|
@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 |
|
Just because I felt it is worth noting: The Node.js Gitter channel is already quite active: https://gitter.im/nodejs/node |
|
I think Gitter is indeed not a bad choice. Comparing them quickly: IRC: Lightweight, cheap, handles easily a magnitude of users. 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. |
|
Strong vote from me against anything proprietary, whether Slack, 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:
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? |
|
@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 |
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. |
|
@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
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?! |
|
I'm removing |
|
Gitter is now open-source (MIT licensed), can be self-hosted, and can also operate as an IRC server. |
|
@ChALkeR Seems like a very good option, if that's the case. |
|
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
…On Jul 5, 2017 7:22 PM, "Tierney Cyren" ***@***.***> wrote:
@ChALkeR <https://github.com/chalker> Seems like a *very* good option.
—
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/AAecVxdl_T5xVxSogufZRXrFgfqY0_Fxks5sK8ZVgaJpZM4Lsmr0>
.
|
|
@MylesBorins If that's the decision the Community Committee as a collective has come to, then this issue should be closed. |
|
@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 -
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). |
|
FYI: the slack registration is now at http://nodeslackers.com (was: nodeslackers.io) |
and others
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.
OR
(2) Creating a new, central Node.js Foundation Slack organization
I would love to hear comments below about the pros and cons of each! But voting is really helpful here.
If you'd like to vote, the Emoji reaction survey system is this:
React with
😄 === IRC 'refactor'
🎉 === Central Slack org
cc @nodejs/tsc @nodejs/ctc @nodejs/evangelism
The text was updated successfully, but these errors were encountered: