KENT: And we're live with JavaScript Air. Hello, everyone! I need to change the way that I say that, like, "We're live with JavaScript Air. We're live." I don't know. I'll say something else next time, maybe. (laughs) I just feel like I do that every single week exactly the same. Okay, so this week, this is episode 39. We're gonna be talking about Node.js and Community. So really exciting, wonderful topic that I look forward to chatting with some awesome people that we have in the chat today.

So yeah, just kind of normal announcements as we get started. We need to definitely give a thank you and a shout out to our sponsors. So I'll start out with Egghead.io, our premier sponsor who has a huge library of bite-size web development training videos. Check them out for content on JavaScript, Angular, React, Node and more.

Egghead.io is also the host of two free Redux courses from Dan Abramov. I'm pretty sure that's how Brian (mumbles) told me to say his name. Find them at egghead.io/redux. And I just totally think that Egghead.io is awesome and they do so much stuff for free. I just love Egghead.

And I also love our next sponsor, Frontend Masters. They are also awesome and I believe they're in the middle of a 38% discount sale. If you go to frontendmasters.com/sale. Go support them. They're fantastic. But what it is is a recorded expert-led workshop with courses on advanced JavaScript, Asynchronous, and Functional JS, as well as lots of other great courses on front end topics. Grab that sale while you can.

And then TrackJS reports bugs in your JavaScript before customers notice them. And with their telemetry timeline, you'll have the context actually fix them. Check them out and start tracking JavaScript errors today at trackjs.com.

And WebStorm is a powerful JavaScript IDE. Give it a try for a more productive development with ES6, Angular, and React. Use the discount code JavaScriptAir at checkout at jetbrains.com/webstorm to get 20% off your WebStorm personal subscription, which is pretty cool. Thanks, WebStorm.

And Trading Technologies is looking for passionate and inventive full-stack JavaScript developers who want to work on cutting edge solutions in a collaborative and challenging environment. Go help them build the top choice platform for derivative traders.

Alright, sweet, so just a couple other opening announcements. This is a live show, which is super cool, and it allows us to interact with the people who are watching live. So if you have any questions, you go to Twitter and ask with the hashtag jsAirQuestion and we'll answer those at the end of the show. And it's fantastic and fun. Then we are a weekly show, so next week we're doing another onsite conference show, which is gonna be great. I'm gonna be at the Strange Loop. And I'm pretty sure that Dr. Boolean, Brian Lonsdorf will be there also as one of the panelists, so hopefully he'll be on. I think maybe one or two other panelists will be on there. But we'll be chatting with attendees and organizers and speakers about the things that they're talking about.

Our onsite shows are generally more flexible with the schedule and this time, it's actually gonna be on a Saturday, so we'll see how that impacts who's watching. It's Saturday. I'm pretty sure it's gonna be around noon Central Time. Just keep track with, actually, if you go to the calendar, jsair.io/calendar, you can subscribe to that and then you don't even need to worry about keeping track. Isn't that cool? Yeah, go do that, that would be great. And we'll see y'all next week in St. Louis at Strange Loop. Let's see, I feel like I'm forgetting something. Oh yeah, as always, follow us on Twitter, Facebook, and Google+ to keep up with the latest. I'll be totally honest, I spend most of my time tweeting. I don't do much Facebooking and Google Plusing, so just be aware of that.

Okay, cool, so let's go ahead and get an intro to everybody who's here. So like I said, my name is Kent C. Dodds, the host. And we have four amazingly awesome guests. They are Myles Borins.

MYLES: Hey.

KENT: And Tracy Hinds.

TRACY: Howdy.

KENT: And Gregor Martynus.

GREGOR: That's me, hello.

KENT: Did I say your last name correctly?

GREGOR: Yeah.

KENT: That was like one of those nice yeahs, like "yeah, sorta."

GREGOR: Yeah, that's perfect, you know.

KENT: (laughs) We'll you're nice, thanks. And James M. Snell.

JAMES: Hello.

KENT: So James, I think I have your middle initial in there because it's on your GitHub profile with the M. I'm pretty particular about my middle initial. I don't know if you are, but I like to be sensitive to people who include it in stuff. (laughs)

JAMES: Yes, I include it in everything. I have uncles and grandparents that are all James, so it helps differentiate.

KENT: Yeah, that's good. My "C" doesn't help to differentiate, I don't know any other Kent Dodds' in the world, it's just somebody started calling me Kent C. Dodds and it stuck. (laughs) Cool, so let's go ahead and get an actual intro to each one of you. We'll go in the order that I introduced you. Myles, do you wanna tell us a little bit about yourself?

MYLES: Sure. So I'm Myles, I have a bit of a cold, so my voice is a little raspier than normal. I think it's gonna work out for this show. I think I sound great. But my voice may stop at some point and then there'll be nothing I can do about it. I work for a small disruptive start-up called IBM, working on cloud technology and other small technology called Node. Full time working as contributor doing a lot of work on LTS and long-term support, doing a lot of thinking about community. Prior to this, I have an undergraduate in fine art and a masters in music. So I'm kinda all over the map.

KENT: Wow, that's awesome. I'm also a musician. I sing and play piano. That's fantastic.

MYLES: We should do a musical episode.

KENT: Oh, we should! That would be kinda hard though 'cause latency would make us like we're singing, like, singing in the Rain or something and like, yeah, that's not gonna work. (laughs) Maybe someday though the technology will be good enough. Tracy.

TRACY: Hi, I'm Tracy Hinds. I'm the Node Foundation Education Community manager, and that's been since March. Previously, I was working at that tiny start-up that Myles was also employed by for Watson doing product work, so it was really interesting. That's when I was my, all of my hobby time was community organizing, so it's nice to be doing that by day hours instead of all other hours of my life. Although that doesn't mean that I do any less of that. I guess the other side of that is I have a lot of friends and family right now that are playing the Where in the World is Tracy game because of all the travel I've been doing between work and fun, so. I'm in New York today. (laughs)

KENT: Cool, well thank you for being on the show. And Gregor.

GREGOR: Hey, I'm a developer myself. I am the founding contributor to Hoodie, an open source project where we care a lot about today's topic, so it's really nice to be here. Besides Hoodie, I'm a co-founder at a company called Neighbourhoodie, which we do consulting mostly around offline applications. And I just moved to LA. And, you know, getting to know the people here and engaging with the community here. It's all very fresh and new and exciting for me. So if you're from LA, say hi.

KENT: Hi. Yeah, if I come down, I'll say hi to you. (laughs) James.

JAMES: Yeah, I'm James Snell. I am, I work for the same small start-up that Myles and Tracy used to. I am IBM's technical lead for Node. I'm on the Node Core team. I basically get to have my hands in Node code all day long, which is fantastic and wonderful thing to do. I am in Fresno, California, which is not exactly a tech hub, but we got some really cool things going on which I can mention later, so that's me.

KENT: Cool, thank you so much for coming on to the show. So, Twitter is making me aware that people have to, we're competing with the Apple event right now. So, first off, I just wanna say thank you all for sacrificing your Apple event time to be on the show. Secondly, I just wanna say that we have 15 people who think this is cooler than the Apple event right now, so yeah. (laughs)

Cool, so, like I said at the beginning of the show, our conversation is gonna be centered around NodeJS and community, and obviously we have some people who know a thing or two about those things to chat about. I think the first thing to kinda get the ball rolling is why is community even something to be talked about? Can't we just develop our code in our silos like we do at work sometimes, and push it out to everybody and we don't know or care who works on stuff? Why is community an important part of software?

TRACY: I'll hop on that one. I think it's, I like to say, when I started programming that no person is an island when it comes to programming. Some people like to think that programmers, you know, sit by themselves and come up with these really awesome things on their own and then it grows. But I think we all know and learn very quickly that it takes a village to create these really awesome things that we use in our everyday work and create in our everyday work. I think the community is sort of the, some people really want that community and other people end up colliding into that community as part of needing help. It's an interesting sort of, nice to have and also need to have.

JAMES: I like to tell my kids that, "yeah, your dad knows everything," but my wife is very fond of pointing out, "no, you do not." (laughs) I think as we go though, as we're trying to do our jobs, just like Tracy said, we have to reach out to other people. We have to get those additional ideas and that richness of input in order for us to accomplish anything. Community is much more important than the software itself.

GREGOR: I would point out that they both go together pretty well. I think that if I just want to do my coding and this is what I enjoy the most, this just won't work on scale in a bigger project. If I just approach this by myself it works, but as soon as it grows and it has an impact and people are using it, there will be a lot of overhat and discussion. And I think good community work creates processes and the framework that actually lets me do the coding that I enjoy the most, whether others are more passionate about making everyone feel welcome and (mumbles) everyone, taking care of that. And I think those two go very well together from my experience.

KENT: Is there a place, though, for those people who just prefer to kind of code and that's just all they wanna do. They don't wanna really deal with people and just, like, I'm not that way. I like being with people, but I know there are, some people who just really prefer to be, kind of on their own. Is there a place for them, or, I think there's probably a place for them, but how do those people find a place in software where community is such a huge aspect?

MYLES: I'd like to speak to that really quickly. I've been using a term lately, soylent bits, as branched off of a great tee-shirt by (mumbles) that said Your Code is Made of People. So you ask if there's room for people who wanna just write code and not deal with people. And I think that question may be a bit of a red herring, even for those who feel that way, because everything is eventually about humans. What are you writing your code for? Even if you're writing a game, it's gonna be played by humans. If you're writing some service, that's eventually gonna service humans. If you're mining data, eventually that data is gonna be analyzed probably for some human need. I think that there's a difference, potentially, between that need and the ability to work with people. I think that wanting to engage in a community and being part of a large community is separate from being able to be cordial and collaborate. But it sounds like a really lonely island. And it doesn't actually seen very feasible to write any code with a human. The code you're writing was written by a human. Unless you're flipping all the bits by hand on transistors that were made by humans, you can't avoid the people.

TRACY: Yeah, I agree with you Myles, and I think that, so, when Kent asked the question, my first thought was, there's absolutely a space, right? There are spaces for people who don't care to interact as much with people who really just don't want to be a part of, or entrenched in the larger community. But I don't think that that excludes them from the community. I think, yeah, I mean, I am very active in community with a capital C and also in smaller communities or the ecosystem overall in potentially more than one language. But, yeah, I've been trying to think about this a lot and how do you include people who want to be left alone, who do just wanna code, because a lot of people don't wanna engage in the social side of the coding community. And I think that that's harder in the age of GitHub, but there are still ways of maybe, community norms that end up getting established to allow for that to happen, at least in a minimal way.

JAMES: Just within the Node Core group, there are people that just wanna go off and write code. There's times when I just disappear, I'm gonna go write code for a week, no one will hear from me and okay, then I'll come back and say, "oh, this is what I've been doing." I think that is very common, very normal. We have to just allow for people who have different ways of working, different ways that they wanna work. And some people will wanna just go off by themselves for several months and write code. At some point, though, all this open source stuff, it's a collaborative effort and any time you wanna start collaborating, you're gonna be dealing with people. As I said, the people, those interactions with other people are more important than that code. The code could be the greatest thing ever, but if how you're collaborating and communicating with people is not good, you're not gonna get much done.

GREGOR: I would like to add to it. I find the question a lot of confusing for myself. Like when we're talking about open source, of course there is place for someone who just wants to code. I mean, for me, I don't say it's not a challenge, but it is probably comparably the simplest of all challenges. Making a tech community a welcoming place for coders is something which we are comparably very, very good at. I think what we can do, or what we do at Hoodie is we prepare tasks very, very well, which are very well scoped. Where someone can just jump in and work it off without asking for permission, or where it is clear there is no more discussion anymore, something has clear requirements and if someone really enjoys working on tough code issues, for example, these are good things that we can include them in in our community. That's maybe just a tip, it works for us.

KENT: I think that if, like, this developer who doesn't really care to interact with people so much, they can just take those things and once the discussion's been done, they can say, "okay, let me go implement this." The challenge comes when that person disagrees with what the community has come up with as the solution. And so then, for you, developer who doesn't wanna interact with people, you'll have to stretch yourself a little bit because if you want to be involved in the discussion around the solution, and how that solution is to be implemented, then you're going to have to interact with people. Maybe that's a sad thing, but I think it's good.

JAMES: Yeah, I mean. So yes, we have to be able to collaborate on coming up, you know, on what the decision making process, and consensus seeking models are definitely important. There has to be recognition, though, that it's not just about people who want to kinda isolate themselves and work on code, it's also about people who don't feel like that can or that they have the opportunity to jump in and be part of the conversation. So they work in isolation because that's what they feel they have to do. We have to find some balance to, some way of including them in on the conversation and making them feel like you're part of this decision making process, you have the ability to impact the direction this project is going. Often times it's very difficult to differentiate the people that want to be isolated versus the people who feel they're being forced to be isolated, right? And we have to get better at delineating those.

TRACY: I think I've seen, just my experiences with friends who have contributed even to Core for Node, because I have not personally. I think I've seen some moments where someone's really excited about what they're contributing, and they're ready with their pull requests and then you sort of see the color drop from their face as the comments are coming in. And it's not because they feel like it's hate that's coming towards them, but they may not even feel nuanced enough with arguing or debating in order to be able to defend the choices that they've made. Even if other people have helped them and supported them through that process. So that's even more where the people come into play that you end up needing, it's kind of wonderful, I've seen this happen, that you end up sort of having champions who are able to more eloquently speak to what the person was trying to do. I think that ends up being a really beautiful thing. I don't wanna say it's like people swooping in, it's sort of this support network, the mentors and leaders of the orgs who end up helping support those people so that they don't feel like they can't, they're not gonna put another PR in.

KENT: Actually, that makes me think of something that I'm glad has just kind of come up out of our conversation, but it sounds to me like what we're saying is community takes all kinds, and there are like, we vary in our personalities and the types of things we like to do by such great measure that there's a place for everybody in community. We all have our own skills that we bring to the table. I think this is why, not to go on a tangent, but I think this is why it's so important for companies to hire outside of their culture and this is why we're getting this idea of diversity in tech and stuff, is because for us to really build up a good community or a company, we need to have a lot of different perspectives coming into the project, and also different types of people with different skill sets and not just coding-wise, but also socially and in the way that they impact the community. We have the people who aren't as skilled at communicating or talking with other people, but they have other skills that they bring to the table. And then like you were saying Tracy, we have these other people who can kind of be champions in that regard with communicating with the community and that kind of thing. I think that's one thing that's a really important takeaway from our conversation is that everyone in the community provides value in different ways. Cool. (laughs)

JAMES: So next week we have the NodeJS interactive conference and just last night I was putting together my slides for my talk there, and one of the things that I'm talking about is just the way that the community has grown. When I first got involved with Node directly, there was like 14 people on the Node Core team, most of which were in California, most of which were white males. I think there was maybe two that were outside of California. Or, no, three, big difference there. Now if you look at it, there are 85 contributors with commit access. And in just the past, I think, two years, we've been able to grow the contributions to Core by over 400 people, new people, contributing in that time. So it's been significant. What we've found, what my experience has been, is that we, you know, throughout this process, we have a long way to go, but there are, there's more of a diversity of these points of view. There's more champions, there's more of these people who felt like they couldn't contribute before who had a hard time contributing that are coming and they're finding those champions. We still have our trouble spots, we still have our rough spots, but as the number of people grow, we're seeing more and more of the benefit of having this diversity of opinion. And hopefully we'll be able to continue that progress.

KENT: What would you all say are some really important aspects of community, whether it be like specifically some things you've learned from the Node community, or, Gregor, from the Hoodie community? You have a really impressive community there, I think. What are some of the most important aspects of a good community? What does a good community look like?

GREGOR: I think, well there are a lot of things that we can do and I think we are in a unique situation where we are comparably still a very young team and the people who started it, I think, were ahead of the curve in terms of what they cared about in the community. I think we did a lot of things right from the beginning and do not face an issue yet where we have (mumbles) clashes, like you see in other communities, which is really, really hard for a community. What we invest a lot into is to create a space where everyone is welcomed and everyone is valued. This is the most important thing, pretty much. Everything else are like just, how do we actually implement it and how do we sustain it and how do we scale this thing? For Hoodie specifically, because it's just a side project run on volunteers, we decided that we have to invest in the community first and the actual code second because there is no other way we can sustain it long term. If you would put our product out there and we would market it aggressively, I think we would crush the user requests. And as an open source project, the only way we can take on the success of the project is if we have a healthy community that identifies with that community and takes ownership. So this is why we invest so much into it. And we can talk more about practical things later, but I don't want to take too much of the time.

TRACY: Hoodie's an awesome community. They're known for being super supportive and I think very inclusive. And I think that that's, it's not like, it's not just a stance that the people at Hoodie take, it's clearly the people who have interacted with leaders within the Hoodie project and feel a part of that. I've never heard anything but that, like, as part of Hoodie. I think that can go, when you're looking at some of these older projects I've been trying to look at precedence, or sort of, what is really awesome about other communities? And not just within software, because community as a thing, can, you know, you can take it from a neighborhood. You can take it from community growth or groups that have felt excluded, even in history.

So something I've looked into for Node in trying to make things better for the future, we have something that is called community capacity, and sort of looking at what the community members are able to do to contribute and whether they feel they have the agency to do so. And I think that that's, if you look at different communities, it's really interesting to see where you may a very large community of people, but there are very few people who feel like there's anything that they can do. That they sort of have to sit back and wait for someone to tell them or they don't have permission, instead of being able to take responsibility as an individual community member. Trying to look into seeing how you can, or I can, and others can, encourage people and sort of break down those thought barriers, or real barriers and biases that we've placed that we need to remove in order for people to feel like they can contribute. I think things like Python and Hoodie are excellent examples of that.

KENT: Actually, I kinda wanted to touch on what you talked about as well as Gregor. Gregor had mentioned that one thing that they've learned is that you kind of do community first, code second. And I actually, I remember when I first heard of this idea, I was like, that doesn't really make sense to me, but as I have been developing open source, every single project has a community, big or small. Most of my projects have very small communities. But I've found that as I've implemented some of the ideas that I've seen in other great communities, it's actually been an amazing experience and I feel like the projects are so much better.

Michael Rogers has a blog post that is just totally amazing. It's called Healthy Open Source and in it he talks about how the Node project will give commit access to people who submit non-trivial changes to Core which is pretty amazing. Node is a huge project that tons and tons of people use, and they're giving commit access freely. You mentioned, James, that there are 85 committers now, which is, like, that's super awesome. Even on smaller projects, I've been doing this where somebody makes a pull request and I give them commit access and it has really changed the dynamic of my little communities that I've built. So I can definitely say from my perspective, my experience that focusing on community is a really, really big and important part of my sanity as an open source developer. If I lose interest in the project in the future, but other people are still using it, there's a community to support that so I don't feel guilty when I don't have the time to contribute to it anymore. There are various reasons for this, but.

Then Tracy talked about the people feeling like they need to ask for permission or they don't know how to get into the things, and I think that's totally the case. For me, even, I've never contributed to Node Core, maybe I've made a pull request for documentation or something, but I'm kind of an outgoing person and I'm happy to jump into things. And I think that if the community isn't, or the people within the community aren't reaching out and encouraging other people to contribute, what you're going to wind up with is a community full of people who are kind of aggressive at jumping into things which may or may not be what you want. You have to kind of monitor the community. The community, it takes work, I think, and you shouldn't just leave it to chance because you may end up with something you don't actually want.

JAMES: Yeah, absolutely. There are a ton of absolutely fantastic open source technologies that have failed because of a lack of community around them and because their technology basically just dies because the original maintainers move on and burn out or whatever, and there's no one really there to pick up and maintain the momentum on it. I'd say, going back to what you were saying about Node, it hasn't always been good. It's gotten better. My first experience contributing to Node was about a year before I became officially involved, was not a good experience. I reported a bug, I think it was on the HTTP stack, and was promptly told that I didn't know what I was talking about. It was not a good experience. So I opened a PR fixing the bug and just left and I didn't want anything to do with it. I think it was a year later, my boss had come back and he said, "I heard you contributed to Node once. Guess what you're doing from now on?" (laughs) It was a bit of a work in progress.

Now, one of the things I've been trying to focus on is this idea that no change is too small, no pull request is too small. If somebody wants to contribute, and all they're doing is fixing a typo in the documentation, to me that is just as valuable as someone coming in and fixing long standing bugs actually in the code or making these huge pull requests, that kinda thing. No change is too small. And the size of the pull request doesn't equal the value, right? Everything has equal value and it's something we want. That's something, I think, we're getting there. It's getting better and we just need to keep that momentum going.

GREGOR: I would like to follow up on something that Kent said that if you don't actively invest into how your community grows, there will be preselection of people who, you said aggressive, I would say maybe very confident or maybe only people that actually use your product will become contributors. I would like to compare this really quick to how our conference has evolved over the past years. I think especially around the JS community or JS Conf events, and do a really, really good job. And I think what worked out for them very well is for one, to create a safe space and make sure you enforce it. So this is like a precondition obviously. But then it will not get fixed by itself. You have to actively reach out. And if you don't actively reach out, then I think we don't do this as open source projects pretty much at all right now. Then you also miss out a lot because there are a lot of people who really want to contribute to open source, but they don't know how and they don't feel welcomed. And it's not that they don't feel welcome because we actively keep them out, they don't feel welcome because there's a certain kind of people who really enjoy their work, open source projects, mostly work today and they really like it. And when someone who is different looks at these projects and sees the tone in them and sees what kind of people are contributing and how the threads are like, they just see that this is not a space for me. This is something that we need to actively change and I think that our conference has showed us that it's worth it and that we can do it. And I would love to see similar efforts in the open source project community.

KENT: Gregor, you mentioned that one of the dangers of not being actively working on your community is that you could end up with not having anybody contributing to the project who's actually using the project. I often feel like people contribute best to something that they are actively using themselves. So could you talk a little bit about the value you see in having contributors who don't actually use the project itself?

GREGOR: Of course. Obviously I very much value people who use Hoodie today. There are also, probably, in terms of the quality of the contribution that they do just from the core perspective, probably their contributions are the most valuable. But what I try to avoid though, we actively avoid is to kind of highlight it too much and celebrate these too much because we think that they're very different kind of contributions like what James said, even very, very small ones who might be equally important or even more important. Because, you know, not everyone has the time to contribute to open source, for example. Many, many people just have different interests in life and if we don't invest in to creating a space where they feel as appreciated as these heavy code contributors, then they will do something else with their free time, right, because this is where we compete with and if you are not fun, the people will go somewhere else. But having as many perspectives as possible, it's just extremely valuable for any projects, I think.

JAMES: I'd have to agree with that. With Node, I mean, Node has many different classes of users. There are people that use Node directly to write their applications, but there are, there's a huge part of the community that, like in dev-ops and a variety of different areas that are using Node incidentally because it's just part of the tools that they're using. They're also part of the community and they're going to have input on how this thing works and how this project works and all the other projects that are used. You have to pay attention to their input, even though they're not, they themselves are not actually writing the code, right? Their input is just as valuable as anyone else's, and you have to pay attention to it. Way too often we completely ignore that and just say, "Well, you know, we're the ones writing the code, so we're the ones that get to make the decisions." No, that's not the way it works. It's not the way it should work.

KENT: Myles, did you have something you wanted to add?

MYLES: Yeah, I was gonna expand on a similar thing to what James was saying. I think we've spent a lot of time focusing on communities of contributors, but it's really easy to lose sight that the community is made of all sorts. The community's made up of contributors, it's made up of consumers, it's made up of professionals and hobbyists. I think one of the things that ends up being the most difficult is trying to build and support and do things in a way where you're being cognizant of everyone. So you end up in this interesting situation, especially when you have a mix of being a downstream and upstream consumer projects which means, you know, for Node, for example, where downstream to V8, but in a weird way both upstream and downstream to NPM because we ship NPM, but NPM needs Node to run. Then we have all of our consumers that are downstream to us who are using Node in production or are using Node for build tooling or are writing WordPress and may not even realize that they're using Node in the UI now. There's all these different places where it can be existing in various levels of awareness. So it becomes really interesting when you start thinking about changing things and how that affects the community and those changes can be technical changes such as adding a new internal variable to FS, which breaks Graceful FS, which breaks Gulp and then you follow this whole chain of things downstream and you can end up breaking all of these individuals who are part of our community but may not necessarily be aware of where it's breaking in their tool chain.

Alternatively, also, though, we have social constructs and things that we consider to be appropriate or not appropriate, so I mean, one could potentially argue that a code of conduct or changes to moderation guidelines or a semver major change to your community. How do we work on crating spaces that make everyone welcome? Or even more so, I mean, let's not even talk technically. We have people from different cultures, different belief systems, different philosophies, and we constantly do these things as humans where we other. Even when we're talking about a community, it's like this community versus that community. We're not talking about everyone on spaceship earth here. We're talking about this subset. And as we keep doing that, how do we have a community that serves all these subsets? How do we create an environment that's friendly and welcoming and opening for one group without excluding another group? One people may say we very well should exclude certain groups if they're toxic. One other that I'm more than happy to see not in a community that I'm involved in are bad actors or people who just do not have good intentions in what they're doing. But how do you define that? And things get really odd. I'd love to see us maybe spend some time focusing on the greater community. I know this is something that Hoodie's worked on. I know Tracy is heavily involved in this, and I think you're pretty active in the React community. Is that correct?

KENT: Yeah.

MYLES: I think React is a great example because I would say, yeah, there's tons of people creating all these different plug-ins and stuff, but I would say React is an extremely vibrant community of people who are mostly using React and using all these different tools. And I don't think that makes them any less a part of the community. I want to explicitly state that I'm not trying to speak down or ill of anyone, I'm just mostly trying to broaden the focus.

KENT: I think that a lot of the things you just said are fantastic. I hope that if people didn't catch that, they rewind a little bit and listen again because that was great stuff. One thing that you made me think about, and I wish that we had a little bit more time, we're kinda coming down on our time, and I wanna talk about how to we even community. How do you do this thing? One thing, this is kinda related to that, maybe a segue, is for the small communities that I'm working on, something that I started doing, is I kind of have a problem with how our tools right now show contributors to a project as only the people who have committed code and that code's been to master, right? So you have GitHub, you go to the contributors and it's like, okay, yeah, these are not the only people in this community. You can contribute, even answering questions on Stack Overflow or in the chat or IRC or whatever, or even filing issues and filing a good bug is such a huge contribution.

For big projects it might be difficult to do something like this, but for my little projects that I'm trying to build small communities around I have this specification called All Contributors, and I'll post a link to it in the show notes, but basically what it is is it's a table of all the people who have contributed in some way, just their avatar and what contributions they've made in their name. And you stick that table in the ReadMe of your project or at some prominent place. It needs to be in a prominent place, otherwise it's not as valuable. At some part in your, for your project for the documentation on the website or whatever to recognize these people who've made contributions. Whether it's like even reviewing pull requests or writing tools around it or plug-ins or working on infrastructure to help the project, any of those things I think are really valuable contributions that don't necessarily give you commits into the project. I think that's one way that's really helped me build a good community, is when people see their face on the ReadMe for the project, it makes them feel like they've done something valuable, and they have. It's great to recognize them for that. What are some other ways that we can, or like James, sorry, did you have something to say?

JAMES: I was just gonna comment. You actually make a fantastic point. Even within Node, I recently just updated the author's file that only recognizes people who actually have commit. You're absolutely right. There is a huge group that never actually gets that commit and they go unrecognized. I think within Node, I'm taking that away as that's something we have to do better, and I appreciate you bringing that up. I'm making myself a note right now to actually follow up on that and see if we can do that better within Node. So, thank you.

KENT: Yeah, that's great. It's harder to do something like this in a big project where that table would wind up being hundreds, thousands of names, so you may have to adjust it. But actually, Gregor has some interesting research about how the (mumbles) Wikipedia did something similar to this.

GREGOR: I would, for a sec, say in general this is not a topic of retention, so we are talking about how to get more people into a project and now we're talking about retention which is at least equally important. Once people are coming to you, you want to keep them. And one important aspect how you do it is to generally, publicly appreciate their contributions and do it in a smart way. Maybe I have an unfair advantage because my wife is an economist and she's now working here as an assistant professor at UCLA and teaching strategy. She did a lot of research on volunteer environments and she proved with a large field experiment with the Wikipedia that just by giving a symbolic award to your editors, it increased the retention by over 20%. The affect was there for over a year. It was significant for one year. Just by adding, you know, a graphic to their discussion page and saying thank you for your contribution. Here is this award for you. We really appreciate your work. There is a lot of other things I learned from her and I applied to Hoodie, so this is probably also a reason why I do so much and enjoy so much myself.

But yes, I think what Kent does, what works for smaller projects is a perfect implementation of this. We have shout outs at Hoodie in general, but I have found out that our tooling is just not good enough for this kind of work. It's very, very bad. It's a lot of manual labor at this point, and what I think is happening right now, GitHub is visibly more interested into community tools. We need to invest into our tooling and how do we actually find meaningful contributions beyond just code and how do we show this appreciation. And I think the best way to do it is actually to have best prefaces by providing new tooling because this worked for code very well and it think we can create tools for community management as well. This is happening right now. And I think there will be a lot more coming over the next years.

KENT: Cool, so we are really coming down on our time. I really wish that we'd had more time to talk about the do we even open source, or how do we even community? But we have five minutes. We generally go over, so if there are other things that you wanna say. We have three questions in Twitter. Anything else that anybody wants to bring up before we go to Twitter questions?

JAMES: I would say, you know, how do we even community? I'd have to say probably the number one thing is just patience, personal patience. Too often we just kinda jump on our initial reaction to something and post that angry Twitter sub-tweet, or post that angry response to the pull request based on that initial reaction. I've had to force myself to do this on many occasions. I'll read it, I'm gonna wait a few hours before I respond or wait a day before I respond to this just to make sure that I'm thinking it through properly. Above anything else, just having that check and just being a little more patient in how you respond is probably the single most important best practice.

KENT: That's great. Thank you very much for adding that little bit. That's a good thing to end off with. Let's move to our Twitter questions. We have three questions from our biggest fan for the show, it's Tierney Coren. I hope that I got the name sort of right. But the first question is, I think Tracy, you were the one who talked about community capacity and the question is, "Community capacity is an interesting idea. Non code contributions is one that seems successful. What do you think of it?"

TRACY: Yeah, I think that's, exactly where we have, you know, the CTC has been working really hard for a while to try and expand their contributor set, sorry, the core technical committee for Node. And I think that there's so much that we can do with the other working groups and things like documentation or community, just being a mentor and teaching someone Node. There are these different types of things you can do that allow for the community to grow and evolve and those people who are contributing need to understand how much value that they're contributing by doing that. I think that the last conversation we had, you know, around giving people recognition for that, I think that's absolutely a part of it. Community capacity is so much more than the ability to commit code. Even then, the code is also important, but we have to make sure that people understand, even people who are contributing to Core in the code sense, that their perspectives are really vital into growing the community and moving forward. So that means in the community that you want to see. The community norms that you wanna see. Sort of codifying those sorts of things.

GREGOR: Just really quick, I would like to add to this that something that we learned ourselves over time is we try to not say non coding at all anymore. We also, we say coders and non-coders, or non coding contributions, and often times, that by itself, sounds already excluding, or you have like primary and secondary contributions. I know you can't always avoid it, but try to internalize it and try to avoid it and instead say code, documentation, design, community work, just list all the things and make them really equally important in your language. It works.

KENT: Yeah, I like that, that's great. The next question, same friend here. "What was the NodeJS experience like before the commit access policy giving commit access to non-trivial contributions?"

JAMES: A mess. (laughs) The history with Node, everyone knows that we have the whole io.js fork. The reason for that was that the people that wanted to contribute to Node were, had an increasing number of roadblocks or actually doing that. A number of the developers just kinda decided that they'd kind of had enough. They wanted a more liberal process for who would be able to commit, how those commit bits were gonna be given out, how decisions were going to be made. That was the group that went off and formed io.js.

The contributions to Node, if you look at the actual graphs, fell off significantly in 2014 while all of this was going on. And like I said, when I got involved, there were 14 people, that was it. I think maybe five or six of those were actively contributing. But if you look over at io.js there was a huge amount of activity, huge amount of effort going on because they had opened up this contribution process. So when we were looking at the foundation, we were like, the choice here is pretty obvious. Rather than trying to be overly restrictive, rather than trying to limit this to a small contained, you know, small limited group of people, what we really need to do is encourage anybody that wants to contribute, come contribute. We need to enable them to do that. Then if you are willing to contribute, you know what? We're gonna get out of your way, here's a commit bit. Now obviously we wanna make sure that those people have the project and the community's best interest at heart, so we wanna make sure there's several commits, that they're not just gonna drop one and then leave. There's some factors there, but it really does, the change really is now that we just wanna get out of your way. If you wanna contribute, we're gonna get out of your way and let you contribute. And that's the real difference that it is now than what it was before.

KENT: Cool, it sounds like, kind of my favorite managers are the ones who kinda got out of my way and were supportive, supported me in the ways that I needed to, made sure that I understood the mind of the customer and that kind of thing. But yeah, let me have the autonomy that I need to do the things that I want to do to make the product better. I think that's, yeah, that's a pretty good analogy. So one last question from Tierney. So adding ReadMe.MD faces, avatars from GitHub as a table should be an automated tool. How can we make that happen?

Actually it is an automated tool, woo-hoo! So normally there's an all contributors cli that was contributed by Jeroen Engels. I can't pronounce his name, but he's great, you'll find him on the all contributors project as a contributor of tooling. It's great. My workflow is normally, if somebody makes a pull request, I ask them to add themselves and all they have to do is say npm run add contributor, they enter their GitHub username and what contributions they've made, and boom. It's automatic and it gets merged with their pull request. It's a very frictionless process. People are normally pretty excited about doing that process themselves.

GREGOR: I would like to try to add one thing is that it's tempting to try to automate community work, but I don't think this will work. It's not code and we cannot automate creating a safe space and a healthy space. We will need people, but we definitely can create better tools who have the role of managing communities.

KENT: That's a great point and I'm glad you brought it up. You can't automate being nice in chat, (laughs) you know, one really important part of community, but there's so much more than that. Yeah, sometimes it just takes some time, but ultimately you buy yourself so much more. Great, so that is it for our Twitter questions.

Let's go ahead and move ourselves into tips and picks. I'll go ahead and go first and then I'll ask each of you to give us yours. I do have a couple of links in here. You'll find those in the show notes. Like the all contributors thing and stuff. For my tips, I'll just make up a tip right now. I got nothin', so we're gonna go to picks for me. (laughs) Actually, here's a tip, no, I gave that tip last week. Basically if you feel like you're really steeped into something and you just really, really know it well, don't close your mind off to the possibility that you might be wrong or there might be something better that you could learn. That kind of goes in with my pick. This weekend, picking Jest, the testing framework. I tried Jest out a year and a half ago and I was like, "yeah, this is dog-slow, I'm never using this, this is kinda garbage." and I was convinced otherwise in recent weeks, and now it's like one of my favorite things ever. It's an amazing tool. I recommend you check out Jest, the testing framework from Facebook. And if you need help getting going, I have a free, a couple free lessons on Egghead.io about Jest. So I'll have a link to that in the show notes. Cool, Tracy, do you wanna go next?

TRACY: Sure. I'd say my tip of the week, but it is always helpful, is I do this with Twitter, but I think it helps everywhere, is when you feel something that you're really emotionally invested in, or you have a strong reaction to, it can be in person or online, write a draft, take a second before you send. (laughs) I find that I end up having a lot of drafts that never go anywhere and that's perfectly okay because it still allows me to vent.

And then for my pick, I would love to let people know about this really cool organization called Operation Code. It's an organization that is teaching veterans and their family members how to code when they're moving to the point when they're transitioning out of their service. They teach many languages. It's operationcode.org. They're looking for mentors. They're looking for help. I'm going to be talking to them as well to see how we can help from the foundation side, but they're a really cool group of people doing some really awesome work and I'm sure that they need help with that.

KENT: Thanks. Gregor.

GREGOR: My first tip is to really much always in life, but specifically in open source, to put yourself first at all times. You are not, you do not owe anyone anything. It's very easy to forget when people ask and are aggressive and feel entitled. Second, you put your community, and then, eventually, you put the people demanding things of you on the top and trying to push for agendas and so on. This is very, very helpful and just reminding myself of that helps. It's very frustrating how slow things go for us, but this is the only way we can stay sane and keep it fun, and after all, fun is what it's all about, I think. The second tip is surround yourself with people that are good to you, especially when you're working remote like me, I had this discussion yesterday. People think I work from home, which I do right now, but usually I try to leave, and I have the benefit I can go somewhere, so I try to go to companies where I can just work, or co-working spaces and go to the places where there are nice people around me and that are good for me.

Third tip to me is invest into mentoring. This is for both companies and open source. I think for companies who see this big influx of people who're coming from boot camps right now. There's a lot of people who apply for tech jobs right now where the companies, they are not ready for it and they say I can't take this. I think what we really have to do is to invest into mentoring now. Into the transition of getting people and hire them and then invest into growing them. There was a great episode by JavaScript Air on how to be a good mentor and there are even like people in general you can hire to help you with the process. So instead of looking for that unicorn, hire junior developer, hire someone who you think is not good enough, but who might bring something else and invest into mentoring. These are my tips.

Oh, my picks is, my most favorite podcast right now is Request for Commit Nadia Eghbal and Mikeal Rodgers. They pretty much talk about why open source communities fail or why they succeed and it's just amazing. It's like putting exactly this topic and making and entire podcast around it and it's great.

KENT: I'm not even mad, that's a great podcast! (laughs)

GREGOR: I know, I really like JS Air as well. I listen to all the episodes. I'm a big fan. And I would like to give a shout out to Offline Camp which is an event that we do early November in Santa Margarita in California. So if you care at all about offline (mumbles), especially if you are a designer or product person, we do this conference kind of event. And it's just limited to 30 people. It's very nice and intensive and personal and you can check the Offline First community with us, so come, we have a great place.

KENT: Alright, awesome, thanks. James.

JAMES: Number one tip, take time for yourself. Take vacation, put the laptop down, pull requests can wait. Even if it's just through the weekend or you're lucky enough to get a week or two off. Definitely take the time. Open source burnout is very, very real. Lots of people end up coming up against, hittin' that wall and just taking just a few, even just a couple days just to kind of relax is very, very important, so I encourage everyone to just do that. Second tip, like I said earlier, be patient. This echoes with what Tracy was sayin'. Write that draft, wait to send it, go back and read it a few more times. (laughs) Just relax, it doesn't have to get sent right now.

Picks, we actually have Node developers in Fresno. Fresno, California is not considered a technical mecca, right? It's not some place you really think of as real high-tech, but we managed to find several hundred Node developers here in the area. We have a monthly meet up called FresNode. We're lookin' for speakers to come, so anyone who's interested in comin' down. It's a fantastic group. There's a lot of really cool things going on. Another thing is it's a very, Fresno overall is a very underserved community. It's extremely high poverty levels. Something like over 80% of the school kids here in the area are below poverty level. If reaching out to those underserved communities is something that you're passionate about, then absolutely I would love to talk to you about comin' in, having you speak, and just see what we could do in this community to get some things going.

KENT: Alright, sweet. Myles.

MYLES: Okay, some tips. (coughs) I think one thing that generally happens when you work with lots of other people is you are gonna make a mistake and you're gonna upset people. It's inevitable. A lot of us are concerned about that and concerned of the ramifications of our actions in general. I have seen that if you are not a bad actor, and if you apologize and mean it, and then move on, and don't double-down and disengage, that generally things will be okay. That's one big tip for working in communities, especially, you know, Kent, you were talking earlier about some of those individuals who may not want to engage with people a lot and may not have the skills to really navigate these situations. If you make a mistake, if someone thinks you made a mistake, apologize and move on and don't engage. It's when you engage and double-down that things get really bad.

Then building on that, the biggest thing I can say is empathy and empathize. Show empathy for those you make things for, for those you make things with and, most importantly, yourself. James touched on that a little bit in his tips. I have some talks that I've given, recently I gave a keynote at JS (mumbles) on this topic. The videos aren't available yet, but a talk from last year that I did on empathy is available. It's a learnt skill, we're wired for it, but it's something that you do have to learn. Be cognizant of that and try to show empathy even when it's hard.

As far as my picks. I'm gonna be hopping on a plane on Friday and heading to Berlin and I'm gonna be speaking at Viewsource Conf Berlin on Tuesday. If people are gonna be around in the Berlin area, we should hang out. Then on Wednesday I'm gonna hop on a plane again and head to Amsterdam for Node Interactive EU, which is going on Thursday and Friday. And then there's also gonna be a collaborator summit on Saturday and Sunday. And I believe, and Tracy feel free to chime in here if I'm wrong, but I believe on the Wednesday, the 14th, prior to the event, there's gonna be some community related events. I can't remember if it's a code and learn or if it's a onboarding new collaborators. Let's put it this way, if you're in Amsterdam between the 14th and the 19th and you wanna work on Node, my DMs are open and I am more than happy, as long as this cough hasn't turned into full blown flu, to spend time with you and help onboard you onto the project.

KENT: That's awesome, that's very nice too. Cool, alright, let's wrap things up here. Just a couple closing announcements. Super grateful for all of you being on the show. This has been a great show. I think it's something the community needs to hear. I like having those kinds of shows. Just give a quick shout out to our silver sponsors who also help make this show what it is. ReactJS program, master the ReactJS ecosystem. I think you might still have time to get on a 24-hour sale they have going on right now. Tyler just released a whole course on React Native, so go check that out. Then Sentry is cross-platform crash reporting, so check them out too.

Then I've got a couple links for you. Jsair.io/suggest will take you to a suggestion forum where you can suggest guests or topics. Jsair.io/feedback will take you to another forum where you can submit feedback about the show if you have any suggestions in that vein or just wanna say hi and thank you or something. I appreciate those too. Then jsair.io/email will take you to a forum where you can, or not a forum, but our email newsletter and you can sign up for the newsletter there, or review highlights from the show and stuff like that. Fun stuff. Remember we are not doing the same time, same place next week. It's actually going to be onsite at the Strange Loop, so check us out there on Saturday. Just subscribe to the calendar, jsair.io/calendar and you won't need to worry about timing again.

That's it, that's our show. Thanks so much everyone for coming, this has been a blast. We'll see you all on the Twitter!