 So, I guess more thematic than I realized when I originally put this talk together and submitted it, this talk is about including people and it's also about working on open source and having empathy with people. So I guess this is the continuous block. So I'm going to talk about including people in projects and in open source, but before I do that, let me introduce myself, I'm Andre Arco, I'm also indirect on all the internet things that that's my, actually crap, that's my old avatar and I didn't update it. That was once my face on the internet. That's all right. I work at Cloud City Development where we do web and mobile development and I mostly do senior Rails consulting for teams that need a senior Rails person to join them. If that's up your alley, that's definitely something that we're good at. My coworker from Cloud City, Raine Hynerix will also be giving a talk later tomorrow, so it's pretty cool. I wrote a book, kind of wrote a book, half wrote a book. I coauthored the Ruby way of the third edition, helped update it for Ruby 2.2 and 2.3. I'm clearly biased, but I think it's a really good book about Ruby. I work on a thing you may have heard of called Bumler. I guess I'll just say that working on Bumler has been really great because it's meant that I end up getting to talk to everybody in the Rumi community because everybody ends up using Bumler and it's been really interesting and really educational to do. Related to that, I have Bumler stickers. I brought 100 just for you. I can get one later. As Jonan said, I started Ruby together. The pitch there is really just you work at a company that needs Ruby gems to work, but you probably can't afford to hire an entire person to make sure that that happens, so give us a fraction of a person worth of money and we will give you an entire person worth of work. Lots of companies that totally works out and everyone ends up with lots of work for a small amount of money. It's pretty cool. I also have Ruby together stickers. I brought 200 of those. You can come get one later. As you can probably tell at this point, I've realized that developers don't actually care about business cards. They only care about stickers. I'm going to oblige. You're going to get stickered. Back to the inclusion stuff. Right off the bat, I would like to point out that it's kind of weird for me to be talking about this, actually. I'm a stereotypical default programmer dude. I'm white. I'm a guy. I'm tall. People just assume that I know what I'm talking about when I tell them things. It's really convenient in some cases and really confusing and frustrating in other cases. So this talk is actually more the result of a lot of research and a lot of conversations with people who are not stereotypical default programmers. But the main reason that I'm giving this talk and not one of those people with more firsthand experience is that I am the only person who can give this talk and still be considered equally technically confident afterwards. Unfortunately, it seems like if you are an underrepresented person and you say, hey, this is not cool and a problem, afterwards, people are like, why are you so combative? Why are you bad at programming? Why are you not good? And so I don't have that problem. So I'm talking about this. Right. So this talk is about, this talk is derived largely from my work on open source projects, mostly including Bundler. But the things that I'm going to talk about are universally applicable to any time that you are working with another person. So if all you ever do is write software by yourself for yourself, maybe go get a drink and you can come back after my talk's over. But if you're like the rest of us and you actually work with people on software that will be used by people, I'm going to have some things to tell you. So, yeah. Everything I'm about to talk about is my experience of doing good things or not good things, doing things that turned out sometimes very badly and then not doing that later or doing things that seem to go well. But what worked for me may not work for you. Like I just said, people will listen to me and believe me in a totally unreasonable way. So me just telling them things sometimes works. Figure out what will work for you, figure out, like, pay attention, try things, experiment, but like have hypotheses, check to see if it works, change how you're acting, if what I'm suggesting is not working out for you. Keep experimenting until you get the results you want. So I'm going to give some background about diversity. Just want to make sure that those scare quotes are present. And I'm going to talk about some things that you can do to try and improve the situation that you're in or the projects that you're involved in. And the topic of diversity, again, scare quotes, has gotten a lot of press lately and unfortunately there's been enough history of sexism and harassment that when Bloomberg magazine published an article by Paul Ford called what is code that tried to explain exactly what programming is aimed at like the mainstream businessy world who thinks that coding is cool but doesn't really know what it's about. The only mention Ruby got in that entire article was that it was full of sexist dude bros. That is not a good reputation to have in the wider world, especially since based on the people that I'm looking at right now, Ruby is not in fact all sexist dude bros. So it's really a problem that we have, that reputation kind of like in the wider world. So over the last couple of years I've spent a lot of time doing a lot of research, talking to a lot of people who have encountered problematic experiences. And I'm going to try to summarize some of that and then talk about things that you can do to improve it. To start with diversity as you probably noticed is not actually the right word to use to talk about this. The reason that underrepresented people are underrepresented is not because they don't exist. Graduating computer science majors make up a significant minority of all of these groups that are wildly underrepresented in tech. The reason that these people are underrepresented in the actual workplaces where we all spend our time and make our money is not because they never got the education that was required to participate. It's because their opinions aren't listened to, their feedback isn't acted on, and their technical skills are suspect based entirely on things that have nothing to do with their actual experience or skills. So cheat sheet, here's the fastest way to start increasing diversity in tech is start talking about inclusion and including people don't talk about diversity because while that may be a like visible side effect of inclusion, the reason that we want to do this is so that people feel included not so that we can say, look at how nicely divided this pie chart is. That's not actually a good end in and of itself. So at this point in the conversation, a lot of people usually say, but I've felt so welcome and included, this can't be the reason for this problem. And unfortunately that position is demonstrably wrong. The underlying issue here is that people are being denied education, being denied jobs, and being denied promotions just because of bias against them. Co-workers, managers, and this goes all the way up, executives, VCs, people really in other words, right? Like no matter where they are, people have been shown to unreasonably overvalued work done by young white straight men and unreasonably undervalued work done by literally anyone else. It might be because their gender is different, it might be because their sexual orientation is different, it might be they have a disability, it might be age, it might be race, it might be weight, it might be there's a really long list of things that it possibly could be. But for example, just changing the name or race or gender on a resume is enough to consistently get it from yes, we'll hire this person to no, we would never hire this person, like without changing any of the other content. So like this is a very clear demonstrated repeatable problem in not just the Ruby community but like in tech in general, in the workforce in America in general, it's a problem. So even though there is a lot of repeatable research showing these biases, people disagree with me every single time I talk about this. They say, but tech is a meritocracy, everyone is valued based on their contributions. Unfortunately, that is also demonstratively false. In fact, research shows that counter to that claim of meritocracy, when you do performance evaluations and make hiring decisions in an organization that has publicly stated that they strive to be meritocratic, those decisions are more biased than in organizations where people know for a fact that it's not a meritocracy. Ultimately, people who get rewarded for their actions assume that their actions were intrinsically deserving of that reward, and then conclude that anyone who didn't get the same reward must have not done as good of a version of that, right? Like, oh, they didn't get paid as much, they must not be as good as me at programming. And that is unfortunately not true at all. Research shows that, as I was just saying, when it's a meritocracy, you're even more biased and you're even more wrong in your evaluations. So after I've said that, people are like, oh, but well, if that's not the problem, the problem is really the pipeline problem, right? There's not enough people coming in to programming who are in all of these underrepresented groups. And as I kind of alluded to earlier, not even close. There are actually a totally minority but reasonable number of people getting computer science educations and then not able to get computer science jobs. Even worse, when we first invented computers, programming was a 100% women's job, right? Computering used to be a job title and the computers used to do all of the calculations that the mechanical and electronic computers were having to do. And so they were the only people who knew what calculations needed to be made and so they had to tell the computer how to do it. As you can probably guess, as programming rose in prestige and compensation, it declined in women doing it and today, programming as a field is less than a quarter of women and last time we checked on a downward trend, right? Like this is not, oh, if we just had more women in the field, this would fix the problem. No, that wouldn't fix the problem. The field used to be all women and the problem is still here so that is clearly not actually the solution, we need to change how we act and how we include people in our communities. The last-ditch effort that people usually throw at me after this is businessmen say I really like the idea of including people but I run a company and so I will only hire diverse teams if it's financially beneficial to me. And I wrote a blog post specifically just about this in the past but the short version is really simple. Companies are so entrenched in their existing biases that they're willing to ignore research that shows that teams that are diverse are actually more productive and more financially rewarding but they would still rather take the easy way out and hire non-diverse teams because that doesn't require any effort even though the end result is worse. And the underlying problem there is even worse than that. Like there is no excuse for treating a group of people as inherently inferior. Like attempts to include underrepresented groups for the sole purpose of improving productivity is guaranteed to fail because you're not actually trying to include them, you're just trying to exploit them for their productivity enhancements. If the reason that you're interested in diversity is not to include people, you will never end up with diversity because you're not interested in including people and your discussion. So, since you're still here, I'm guessing that you're interested in including people. Including people is not just a checklist of things to say and do consistently, it's an attitude that you need to adopt during social interactions. That attitude needs to be not just present but you need to be acting in a way to counter the condescending hostile attitudes that are kind of just floating in the air around open source and around programming in general. So, working on any open source project or really any software project, there are usually three groups of people involved. There's the end users, the potential contributors and the existing team. It's easy to be inclusive towards one of those groups and still be hostile towards the other groups. So, in the Linux kernel, for example, end users are welcomed. Linux is for everyone. Anyone can use it. Contributors on the other hand are semi-regularly told that they're brainless imbeciles or much worse language, which is not super good at welcoming the actual team that works on it. Yeah, so you need to not just include the team, you need to include people who are willing to contribute to the project and you need to include the users who are actually gonna be the ones using the product in the end. So, let's start with end users. How can you be welcome and inclusive for people who actually use the software that you build? Whether this is an open source project or a closed source project, you're gonna have users even if this is like a completely internal tool and the user is yourself. But if the user is more than you, which chances are pretty high that it will be at some point, people will pay attention to the other people who work on software, people will pay attention to the other people using the software. They will pay attention to the fact that the documentation only ever says he. They will notice if your software encounters an error case and raises a message that says that's stupid, don't do that. So, here are some really straightforward ways to make sure that people who are end users and using the code that you write will feel included. Start with a code of conduct. At this point, there are a lot of examples of codes of conduct. Coraline Ata Emkey, who unfortunately wound up not able to come to this conference, has created a sort of template code of conduct called the contributor covenant and she's really active about updating it when necessary to make sure that it is as inclusive as we have currently managed to come up with. It makes it, a code of conduct makes it clear that the project intends to provide a safe space for people who are using it to talk about it without being harassed and without one, chances are that anyone in an underrepresented group is going to think twice about participating in your project because if you're in an underrepresented group, chances are good, you already get a ton of crap on the internet and why would you also want to give free work to a software project that you're going to get crap for having given free work to? Next up, documentation. Documentation is a thing. You probably don't have as much as you think you should, chances are high you're embarrassed about it, that is okay. I work on a lot of projects, none of them have as good of documentation as I would like. People are happy that those projects exist anyway. The ground rules for helpful inclusive documentation are pretty straightforward. Use she or they instead of he if you have to include pronouns in your documentation, write some documentation that is explicitly aimed at newcomers. The number of projects that exist that assume that you already know everything about the project when you start reading the documentation totally astounds me. How do you get people involved in your project when all the existing documentation is only for people who are already involved in your project? This may mean finding people who are not already involved in your project so that you can explain to them how your project works and they can write it down because you may have no idea what is actually unknown about your project at this point. If it's your project, chances are pretty high that you already know everything and what you write down is only gonna make sense to someone who already knows everything. For a really fantastic guide to writing genuinely helpful user facing documentation, Jacob Kaplan Moss did a talk called Writing Great Documentation and he outlines four kinds of documentation that your project needs to be useful to all of the people who will be looking at the documentation. The first thing is tutorials. Tutorials explain how to accomplish a specific task. This should be a thing that you can accomplish start to finish in 30 minutes. You should then find a link to the next tutorial or to other documentation about that particular topic. You should write topic guides. Topic guides explain a single topic in detail and so if you want to learn more about just that particular thing because that's what you're interacting with, you can read the topic guide. And then you should write an API reference because sometimes people will just wanna know like what every single possible thing that you can do with your project is or they'll remember vaguely that you can do a thing and they don't remember the method name or the exactly which parameters to pass and that's when an API documentation is invaluable. And API documentation is the most likely to already exist but they're also most likely to be useless for someone who doesn't already understand your project. And this is actually a great example of why Rails has both really extensive API documentation and a really extensive guides project that's full of topic guides because if you wanna know how to write a Rails routes file, opening the API documentation for the router is not helpful and I already know how the router works and it's not helpful to me. Finally, troubleshooting documentation. There will be problems that come up again and again and again. If you can fix those problems in your code, if you can come up with a way to write code that will say, hey, it looks like you're having problem X, this may mean that you need to solve thing Y and then this will work, like put that in your code and show that to the person. Don't say unexpected error, have a great life, right? Like that is not actually helpful. If you can't put it in your code, put it in your documentation and say, oh, you're having trouble, like here is the list of steps that I will tell you to do if you show up in GitHub issues. Here's, I just wrote it down, try that first. This, based on my experience with Bundler, that like list of here's things that you should try before you file a ticket that says I really think this is broken. By my best guess that solves maybe like 60 to 70% of people's problems. That is a huge time saver for me and a huge time saver for those people because they don't need me to be awake and responsive in a chat room somewhere to get their problem solved. Speaking of troubleshooting and issues, how your project handles issue reports is a huge indicator of how inclusive your project is. If you respond to a new issue with that doesn't even make sense, close. It's not very inclusive. If you respond to an issue with why on earth would you do that, right? Like this is not, I guess this is not rocket science but like this is a very normal attitude in open source. People are like, oh it didn't work, well you're doing it wrong, don't do that. People are like, oh I don't understand why this thing did a thing I don't expect and people are like, well read the fucking manual. Like this is not actually helpful if what you are aiming for is including people. Like maybe those people genuinely want anyone who is having trouble with their software to just go off somewhere and be unhappy. But that's not what I'm aiming for, right? Once, so start, when you're accepting an issue report, start with the idea that whatever the reporter is saying makes sense to them, right? Like it is, chances are very high that no one is showing up and going through the effort of opening an issue, showing like here is the problem that I had without having actually had a problem and if they're having a problem that means either something is broken in your code or something is broken in your documentation because it didn't work out the way that they expected it to. Try to figure out what context the reporter has that you don't, always thank them for taking the time to report the issue because if they're reporting an issue, this is a potential problem for you, right? Again, I guess a way that I have heard this put is there is no such thing as user error, right? If the user is having a problem, you either designed the error message badly or you designed their expectations via the documentation badly and one of those things probably needs to be fixed. And even if the report that they sent you is not a bug, let them know places that they can get help, let them know what they can try, like don't just say, this is not my problem, go away, right? Like that is unfortunately, absolutely the norm in open source projects and honestly from what I've seen inside companies, that is also the norm, right? Like there's some poor computer science, some poor customer support person saying to the engineer, well, this user did this thing and I feel like it's actually a really common response for the engineer to be like, well, the user's doing it wrong, tell them not to do that and that is actually unhelpful for everyone, right? The engineer feels misunderstood and put upon the customer support person feels useless and the end user feels like you don't actually care about them at all. Closely related to issue reports, chat channels, IRC, Slack, email, Twitter, follow the code of conduct in all of those places, make sure the code of conduct is being followed by other people in those places, especially when they're like actively representing your project, right? And anyone who is officially representing your project, right? Like if they're on the core team or if they're you as the owner of the project or whatever, harassment and condescension are like just not okay. Like maybe let's not do that ever, that would be awesome. And finally, this is true for every project but you have to enforce the code of conduct on everyone no matter how quote unquote invaluable to the project they are because that supposedly super productive giant jerk has driven away, God only knows how many super productive non-jerks who would have been happy to work on your project except for that jerk that you think you can't afford to lose. Now let's talk about welcoming contributors. So everything I said so far about welcoming users totally applies to contributors. Everything I said about issues totally applies to pull requests. A safe environment without harassment is absolutely a requirement for getting like including contributors to your project. Documentation helps but there's definitely more you can do to welcome contributors specifically as opposed to just users. The biggest thing you can do to encourage people to help is to ask them for help. I will do this at the end of the talk to give an example. Most people think that they need to be experts on something before they can help and that is almost universally not true. Especially if you're in a situation where you don't have a lot of interaction with people who are new to your project, you have no idea how confusing it is for a person who's new to your project to start using it and it would be super awesome. For me personally I have gained incredibly valuable things from talking to people who are new to a project to understand how I can be helpful to them as a project maintainer. I guess to make this incredibly clear I have never had any idea how anything worked when I started working on a project. I started working on Bundler and I spent I think two weeks just saying out loud, how does, what, what, why would you, what? And like and eventually after a couple weeks of persisting through that it started to make sense but it is not because I like had any idea what I was doing when I started it is just because I said I don't understand how this works and that makes me angry and determined to figure out how it works so I'm gonna keep sitting here frustrated until it makes more sense. When you ask for help, when you write documentation explaining how people can contribute make it clear that they don't need to be an expert and make it clear that you would really like their help based on whatever level of understanding that they have because that is really valuable. Another thing that I do that I found really helpful for getting people started on the project is scheduling times to pair with contributors so this ties in nicely to the last talk. I am also one of those open source project maintainers who says oh you'd like to help, that's awesome. Let's schedule an hour of pairing and at the end of that hour of pairing let's see if you feel like you can tackle the next thing yourself or if you wanna schedule another hour of pairing. Like this is a thing that makes it incredibly, this is an incredibly powerful way to get people to the point where they feel like they can maybe make changes without needing to be scared. Write development documentation, this is totally different than end user documentation. You need to write documentation that says so you wanna work on this project, here's how you check it out, here's how you set up the dependencies, here's how you make sure everything works, here's how you run the tests and here's who runs the project, here are the policies for contributors, here are the criteria for accepting pull requests, here's how you contact other people who are working on this project if you have questions. Don't stop there though, if there's anything that you have to do repeatedly as a developer put it in a document that explains the steps, write a release guide, write I guess write a list of every type of help that you would like to get. We have a list like this for Bundler and it says I would love to get pull requests that fix typos. You too can be an open source contributor, if you can find a typo in Bundler, send me a pull request, I will say thank you so much for fixing this and merge it and you'll have a commit in Bundler. I mean that's not the end, right? We're also totally happy to get help with triaging open issues, writing more documentation, refactoring code, writing more tests, fixing bugs, implementing new features, all of these things need to be done but my point is if you can find typos you are competent to work on the project and so we tell you that explicitly in the I'm interested in contributing to Bundler document. Pull requests are pretty close to issues actually. The person opening the pull request has context that means that what they are doing makes sense. Even if the code that they sent you makes no sense to you and even if the code that they sent you is code that you would never ever merge which sometimes happens. I feel like it's like maybe three quarters of the time I get a pull request and I'm like this is so great, you just like did my work for me, I'm just really jazzed right now and about a quarter of the time I'm like you just did a thing that's really great for you and is gonna make every other person who uses this sad. And so rather than saying you're a horrible person why did you send this, what I say is I really appreciate you taking the time to write this code and share it and I really want to understand your problem and see if there's a way that we can solve your problem that doesn't make everyone else who doesn't have this problem sad and that has actually produced some of the best features in Bundler eventually although it's taken a lot of work. Ultimately it's important to apply all of these principles to your team, right? Respond to code of conduct violations aimed at your team members, not just at you. Make it clear that you have the back of your entire team and tell them that you appreciate their help. Apply the same principles we just discussed for users and contributors to team members, assume that what they're doing makes sense to them, find the context that you're not sharing so that you can understand how to resolve whatever it is that you disagree about and give them positive feedback and ask them for help when you need it. In the end everything that I've suggested comes from the underlying principle of having respect and empathy for other people. Other people don't have the context that you do, they don't have the skills that you do, they have different skills and almost all of the time they're just trying to do their job. They can tell when you're trying to help them and they will react based on that. On the other hand, if you're not reacting well, they can tell and they will respond to that as well usually by taking their efforts and themselves somewhere where people won't treat them like crap. Treating others the way that you personally would like to be treated or that you personally are treated is not enough. You need to think about the context that other people are in and treat them in a way that is respectful and empathetic to them. Listen to people in underrepresented groups, pay attention to how tech as a field mistreats those people and actively work to fix it. Call out problems when you see it, let people know that what they're doing isn't okay. Tech as a field is biased and exclusive and the only way that it's gonna get better is if all of us act to change it. Last, let me finish by doing this myself. I run a popular open source project. We want to include many, many more people on the team than we currently have. If you have ever thought about contributing to open source that felt intimidated or excluded particularly, please talk to me because I would like to both improve that situation for Bundler and tell other people what they can do to make things better. I wanna change tech so that everyone feels capable, welcome and empowered to improve things. That's it.