 Okay, so I am Veronica Lopez from Mexico City, and today I'm going to talk about how to be more inclusive beyond the open source contributions and how, and I mean, I am the Latina, the Mexican talking about inclusion. It's like, time again, but no. So I'm a software engineer and a former scientist. I work with distributed systems, mostly in Go right now, a bit of Elixir. But I have extensive experience with diversity initiatives, and that's not even my job. It's like, every time I hear about someone setting up a diversity initiative, I'm always like, let's see if I can tell you. Like, okay, so is this initiative diversity enough? Does it cover just women or just people of color, or, you know, you name it. So everybody has very good intentions, but that doesn't mean that their intentions are really effective. And in order to foster more diversity, and this doesn't mean women or people of color or people from Mexico, it means all of us in every single place that we want to belong to or join. This has to be effective, so good intentions are not good enough. Okay, so, this is, my talk is just 10 minutes long, and I'm always ranting about this, so I would have love to have a bigger speaker's love, but okay, so I'm going to try to fit this in. So the four main points for today are the introduction that we're going to cover, the basic things that everybody knows, or I hope everybody knows. Something that I call the cookie cutter culture, the wrong ideas that we have, and how to solve this. Okay, so I'm literally going to read the introduction just to be super clear about this. Okay, so beginners and people trying to learn new stuff, which is not the same, are often told to contribute to open source as it means to get their career started. It's not that easy though. I mean, with this, I mean, I don't know, how many of you have been approached by a junior programmer or someone that is not a junior, but that wants to learn, let's say Ruby, or your gem? I don't know, so what's the first thing that a lot of people say is, oh, you should start with open source, right? To build your portfolio to, I don't know, to learn more things. It's not that easy for a lot of people, and I will tell you why. There are a number of setbacks, and the most popular are harsh environment, with codes of conduct, in case there are, and I mean, with this talk, I'm not inviting you or telling you that the only healthy communities have codes of conduct, it depends, but well, in case you have one, many of the codes of conduct that I have seen on the internet are a bit weak, or they avoid conflict solution because they want to believe that everybody is friendly and that everybody has good intentions, but unfortunately, it's not like that all the time. Poor documentation, time and time and again, things that might be super clear for us, might not be super clear for anyone else, and well, tons of assumptions, like, you know, biases, you know, like, okay, if this girl is talking about diversity, maybe it's because she didn't have anything technical to talk about, or maybe if this person is asking about this gem, we start assuming that probably that person is junior and that we should just talk condescendingly to him or her, which might not be the case. So the second point in my talk is a cookie cutter culture, which means that we keep inviting different people to join our project, our open source project, our community, because oh, it's so inclusive, it's so friendly, but we only want them to get in to teach them how to act like us, you know? So the diversity, the diverse thing in diversity is actually that, like, people from different backgrounds, it's not just about how we look, it's what can we bring to the table, right? So diversity means a diverse pool of people, diverse pool of workflows, diverse everything, you know? And, well, people and companies tend to consider only people that might look differently, but that end up fitting into this mall, you know? Like, let's say, time and time and again, I have seen people, I don't know, saying that they don't know how to use Git or that they have never used Git in their workflows, you might say like, how, right? But besides the horror of not using any version control, well, it's a reality. And this doesn't mean that people that don't use Git, for example, aren't necessarily ignorant or junior. It's just that their workflows, maybe they don't have the time, maybe they don't have the resources, maybe they don't have anything, anyone more technical than them above them to tell them about those things, you know? So we just assume that everybody is just like us and if they're not at the same level or they don't use our same tools, they don't use even our same language, then they are ignorant or they don't know the same things that we do. So then this is a very cliche case, right? Like, quotes, I met this girl or man or person who started doing basic grammar contributions to any project and now she writes kernels, right? So that's like the ideal open source career situation, right? Like, from any beginner, from a hacker school or independently learning, you might say like, okay, so my example from the beginning, right? So if you want to start coding and start having a portfolio, well, maybe you should start contributing to any open source projects, right? So you can start just to feel familiar with the workflow or with the project itself. Why don't you start contributing to the grammar or to the documentation mistakes or stuff like that, right? And then there are many stories like this in which this sad person starts doing more significant contributions every time, right? Till the point that he or she make very important contributions and that's like a very, I don't know, example that everybody puts out there but it's not the case for everyone because everybody has their own story, everyone has their own journey and everybody has their own reasons to join software and it's not always your project, the reason we started coding, right? So what I said about the workflows, it's a wrong idea, right? When they are not familiar with, let's say, if they're working in a distributed environment and that that's what I work in, maybe someone has never heard about Cassandra database, right? But maybe they have heard about any other stuff but then if they haven't heard about Cassandra, then you immediately says, oh, she's underrepresented, she hasn't heard about Cassandra and then, okay, then she doesn't know. No, it's not like that. It's like, okay, so what do you know? What can you bring to the table then? The second wrong assumption is that everybody has the same amount of time to contribute. I'm not going to dive deep into this because this very cliche thing that it's all over the internet, but okay, not everybody has the time and then not everybody has the interest to contribute to your project and a lot of people said like, oh, if you don't have open source contributions it's because you're not good enough or you're lazy or you're not interested, okay, wrong. How to solve this? Stop assuming, listen, empathize. If you cannot empathize, be open to options. What are the options that we have? Okay, encourage people, of course, to contribute to your project if that's what they want, but also encourage them to give talks about your project or write blog posts about it even if they haven't contributed actual code or documentation or grammar mistakes. At Meetups, what my friends and I have done, for example, in the Go community is set up Meetups or special Meetups where we just put together at least a bunch of issues of different projects, let's say Kubernetes of the Go project or Docker or different projects and then we divide them into okay, these are easier, these are intermediate and these are hard so that everybody has the opportunity to contribute and we look for these issues for them and then we invite mentors, actual mentors that not only know a lot but they do want to contribute and help people because not everybody likes to be a mentor. Then have conflict solving mechanisms in your codes of conduct or whatever mechanism you have in your open source projects, ask for help. Time and time and again, other people and friends that are leading different open source projects, very important projects, they tell me like, okay, for my conference, I didn't get to find any female speakers or any people of color speakers and I was like, okay, did you ask for my help? No, and I was like, why didn't you ask? If you had asked me, I could have connected you with people that could, might help you. It's not like a 100% result but it might help. And well, spread the word. Value the people that contribute to your project, not only the code, not only the documentation and avoid the condescending tones like, for example. Oh, I thank a lot to all the contributors and okay, by the way, the documentation guys are awesome. So no, everybody has to get the recognition. Why is this? Not only because people feel better about it but also because when you have prominent positions in technology, people will follow suit. People will follow your example. So right now, employers are like, in your job descriptions, you would find, I want the candidates to have open source contributions because that's what's trendy. Also because it has a lot of benefits that we don't have the time to talk about right now. So just to wrap it up, when people in technology start listening to what other people say, it becomes a trend. So let's set the trend of saying that not only we need open source code contributions, right? We might contribute with other pieces of advice, of knowledge, of your time. Like in my case, for example, I haven't written a single open source line of code but I contribute a significant amount of my time to open source initiatives and to diversity initiatives. And that's what I tell my prospect future employers, when they ask me, at first I was frightened and I was like, no, I don't have any. And then one day I was like, wait, I come and give a talk about this issue and I help tons of other women and people to succeed, to do actual code contributions to open source. So everybody counts. So thanks a lot.