 This squashing diversity equity inclusion box in open source projects I Wanted to give this together with Anita sama who unfortunately is traveling to another conference and could not be here so but I want to Thank her very much for For all the work that she has done and I would not be presenting on this because I learned pretty much all of it from her So super excited the idea of Diversity equity inclusion bucks though I attribute to Emma Irvin introducing me to so I want to make sure that is I give credit there So one of the things that we know in open source is that we are having some challenges and And we know all specifically there's a gender imbalance and we have different surveys over the last Decade that have come out This one from github's open source survey six years ago found 95% of Respondents to their survey were men only 3% identified as women We had a survey from Mozilla that Was better or or more? I don't want to say better. It was more equal in representation with 58 percent male and 33 identifying as female and 9 percent as other the open stack community report from 2018 found that ten percent identified as female and At the code contributions level it was 7 to 8 percent, but then at the leadership and governance level it looked Again, I would say better because I'm biased and I have my own preferences 20% identified as female so over the Years there have been lots of recommendations. What do we do about this situation? How do we go into our communities and change this for the better for how we would like it to be and one that has taken off and been really Successful in the terms of adoption is to have a code of conduct that is pretty much expected although I just looked at the 100 most start projects on github and I thought everyone would have a code of conduct and I did not find that even under the top 20 I Was only 13 or so that had a code of conduct. So still a little bit of work to do here One is to identify and then counter toxic behavior Address structural changes in our communities that are leading to these pictures that we are seeing I Create identity groups provide support for the underrepresented Individuals in our community so that they have a place of belonging and they can talk about the specifics to their experience Improve documentation That's something I'll talk a bit more about here in a little bit how we can actually go about doing that provide space for newcomers and welcome them also localizing efforts providing support and Documentation and conversations in different language, but also avoiding jargon that Increases the burden of someone wanting to come in to have to learn this new new way of talking and what are you talking about? So acronyms are I try in my own work. I always try to avoid acronyms whenever I can And also, you know, we can take a data-driven approach to learning and improving There's many more things that we can do and Savos just asking me about Book that Anita and I are working on where we are collecting a lot of these things and creating Something that you can pick off the shelf. That's the idea pick it off the shelf and then you can see okay What do I do with my community? So anyway, that's a book writing a book is hard takes a lot of work. We're not there yet So anyway today so these were old surveys today This is the most recent survey that I know of the Linux Foundation did this release the two years ago And I don't know of anyone who has done a more recent study I see shaking heads. Yes. So and I was just talking with with the Linux Foundation director of research and We're not getting an updated version this year either Also, the rationale is let's give it some time for things for for these findings to disseminate for everyone to be aware and then For things to change before we assess again. Otherwise people get survey fatigue and so on so anyway in the Linux Foundation survey which Found 82% identified as men 82% fell welcome in open source now Isn't that odd that 82% for men and 82% felt welcome. I wonder I wonder We also know that 81% 81% that sounds familiar as well of people surveyed read and write English other experienced language barriers 22% disregard that equal opportunities exists. So we have some deniers amongst our Communities, which we know and we need to be mindful of Trying to change something we get pushed back. Those are the respondents here. We also See that 30% report that some aspect of their identity was a factor so we want to be mindful of everyone and their backgrounds and So knowing what the current state is and I Think I'm not Hearing anyone opposing that these numbers are bogus or anything. I want to propose a Specific lens a frame to think about this and one approach that we can take To make a change here and that is to think about unconscious bias as a problem There are other problems. This is just one that I propose we look at and If we are thinking about Navigating There are there different approaches that we can take to navigating One one one might be like I need to know exactly where north is and how many degrees off I am and where the wind is going and I very scientific very Numbers driven worse. The other one is like, oh, I see a church over there And that's the town hall So I think we have to go this way and the Sun is over here and I'll find my way at this way They're different approaches of going through life different approaches to observing a problem and solving it and We know this this is what Science has shown it has also shown that these biases in different approaches to life are clustered around the identities of male versus female or men and versus women Especially in the technology context When we look at the motivation and of course People land anywhere and this is a continuum. This is not extremes. This is just something that we have seen in the research and Where there were enough studies that we could say this is actually significant. It's not just one study This has been multiple studies that have found these things When we look at motivation for engaging with technology Men are more likely to want to learn and like it and They're they're engaged with it. Where's women typically are they want to accomplish something That's why they're engaging with it for computer self-efficacy Men tend to be higher confidence. I know technology. I know how to use it Women are less confident about it and And men are like, oh, it's not working. The technology is wrong Women are like, I think maybe I need to learn how to use this. Something is I don't understand it quite right So a different mindset is in here and then when it comes to attitude towards risk Men tend to be like well, I tried. Oh, it's broken. I'll try again. Oh, it's broken Women are more like well, I try this but I don't know this could break something. Maybe I shouldn't try it for information processing Men are like, oh, I found this tutorial first step second step. Oh, it failed. Okay. Let's go back. What did I miss? women are More, okay. I found this tutorial. Wait, but what I'm missing this how That they might not that they're like, oh, I want to know the full process before I try it I want to know what the outcome is going to be and Understand how the different parts are playing together before I start engaging with the technology and Then this is also goes into learning by process versus tinkering Similar example, so there are different approaches that seem to cluster around men and women and What happens When we have 83 percent or 95 percent Men who are writing all the documentation who are writing all the user interfaces who are building the open source projects they have their certain way of approaching problems and Documenting it building it for this particular way of working someone else comes in they need something different It's not providing what they need that's the unconscious bias We don't even know that we're building it into Open source and so what we want to do is address this as a diversity equity inclusion bug Just like we do with anything else that is broken and open source. We say it's a bug And we need to find it. We need to discover the bug Understand why it exists and then resolve it now ideally we have Everyone test it and give us a great feedback, but we can't always do that And so what we need to do for the discovering is put ourselves in the shoes of Someone who thinks different from us and I'll give you an example here how that works in a second Then we need to understand it so in this case here's an example we want to fix someone comes to the community and wants to fix documentation and The instructions in the read me read well if you want to contribute to the source code go over here set up The development environment takes you 30 minutes. I Just want to change documentation. I don't want to send up the dog the built environment This read me is not providing what I need to participate in this project So through this process of going through the exercise putting myself in the shoes of someone who wants to do other things with the project Maybe we add something to the read me resolve this D I book and add a section on how to engage in documentation so that is the at the very high level an example of what I'm what we are proposing here and the the approach It's called gender mag and there's a website with lots of great resources for doing this so Let's go through each step a little bit slower and talk about how to do this or If you want we can also have a conversation now. So this is a good good breaking point where I showed you the high level How this works? Do you want me to go into more detail step-by-step or do you want to have a conversation and then? Just foreshadowing so you know what else is coming I have a second part of this slide deck where we talk about common barriers or diversity with the DI bugs and How how to think about them where to find them? so lots of options What would you like to do? Continue or Have a conversation. Okay. I see nothing. Let's do that continue all right, so Going into these three steps discover understand and resolve Let's Think the first step is okay We need to put ourselves in the shoes of someone who's coming to the project who is not as familiar So especially if I'm the maintainer I Already know a lot of things about the project and I need to take that step back and think about okay Someone who comes to the project where might they engage and for what purposes so here is a table with some ideas For someone who wants to go to the issue tracker. What might they want to do? Well, maybe they want to find a good first issue to start contributing to Maybe they want to report it back with the software. Maybe they want to request a new feature So let's go through each of those steps and see how would that actually work? Someone who comes for to the code review system Might want to submit a software change for review or they might want to respond to a review and update the contribution So that this would be the second step after they already got the feedback I'll leave this table. I don't want to go through each point The idea is that think about the different parts in the project and how someone might want to what someone might want to do there Once we know what goal a newcomer or someone to the project has We need to describe what are the steps we expect them to take So if for the example of making a change to the read me Well, the first sub goal is to edit the read me file. That's what they want to do For that they need to click edit go through the read me. This is from github this workflow They need to edit the read me file and then they need to describe a commit change and save the commit Only to then have the second sub goal of creating a pull request Create a new branch and start a pull request and then they have to actually create the pull request Someone who just wants to go in and usually works on word they just Edit and save and they're done all this other stuff is Way out there like what is going on here? So we'll get there in a moment But but we need to now go now that we understand the process that we expect someone to go through Put ourselves in their shoes and they're different these five dimensions that we talked about earlier But we can say okay, we're going to take someone who has enjoyment Or we go who someone wants to accomplish something someone who is a comprehensive versus a selective information processing style and we can compile our personas in Different ways so that we can accommodate everyone based on how they approach problems and then Maybe we have a friend Maybe I have someone else we team up because then we can have a conversation about it. We can see more than We see ourselves Ideally we have a team of three that seems to have worked really well in the experiments that the research team was doing and This is the next step is okay. We have some templates some forms that the team now fills out they go through The the problem they describe the the scenario and the sub goal Okay, the first one is we want to edit the read me file and then Just does this make sense? That's what the person as with these five qualities actually think that this is the step that they need to do Yes, good. Okay, perfect Maybe or no, and then why do we think it's not the case? Is it because of the way that they approach problems in terms of being selective or comprehensive or is it because they are more careful? rather than trying things out and And we want to keep track of that because that helps us later as we try to figure out how to solve The bug So we do that for the sub goal and then we do that for the individual steps where we want to make sure that When it says save and I want to save then okay, it makes sense. I want to save but it says commit Now I'm confused And we want to be mindful and keep track of that and then This one is after the action if the feedback the system gave me Confirms that I've done the right thing I Love the forms where I click send and I go back to a different website and I don't even know that it submitted the form I have no confirmation. I hate that. So this is the kind of idea here Are we getting the right feedback to know that I'm making progress towards my goal? and then We have documented the steps and how someone would approach it and where they stop following the process We can count how many issues that they have How many issues were a reason because of the way they approach problems then that's where we call the DI book and then we can discuss the solutions and then we Take on a different persona and we we try it again and we take a different perspective. We try it again And we basically put ourselves in the shoes of many other different people It's okay to just do it with two Stereotypical people will cover most of the use cases. So you don't have to go really in depth with this But just taking a different perspective and going through the process and seeing hmm I would not have thought of that if this is the way I was thinking or approaching problems So this is discover understand resolve DI books with the gender mac process there are lots of research or resources on their website that are available and Now is a good spot where we can talk about this or I can continue on to Common DI bugs Again, the invitation is open for anyone who has something they want to share right now is a good spot Yes, so here one second. I'm gonna give you the microphone because we have wonderful people online Who also want to hear what you have to say? Okay, so this is great like this is technically how this works But what you're missing in all this is like the important part of the people, right? So like I Getting people to get over the technophobia of just making the first commit is hard Yes, but I do it because I'm really sick of dealing with like people in marketing in HR Who are like afraid of what we do for a living, right? I work in this field So once a year on like the inaugural day It's like February 7th like open source day no matter what company I'm at or with or any other ones that I can get to Engage I'm like everybody is gonna do like so I'll say it right if we there's like a women-owned empowerment thing like all of you Can go and put your resources out there do one commit just put your name down do an edit and then Two more things that are just things that always work PR parties so like literally I'll go out and reach out to a maintainer because I have that network depends bouncing someone into a process You literally like jump on a zoom and have them do a PR party like a bunch of people do their first commits Maintainers come on and have a video discussion or issue discussion and it's live Because there used to be a time in the olden days where we all were in the same rooms And you just have to re-replicate those like do extreme programming and open source but on that note you can only do a PR party correctly if you Use the salt and pepper song push it at the time when salt and pepper and everyone has to do it at the same time Which is actually I I will give the microphone back after after two more thoughts But when you do these PR parties, it's interesting because like I'll do them with people from all around the world You actually see that it takes differential time and lag because of the different CDNs So it's a really nice way of like you're it's a very cool thing to do that and then like lastly The coolest thing because people it's not about just like throwing something up and like high-fiving a project one time right it's about like having a dialogue a lexical discussion around logic and And So when people first use get hub for the first time and I teach them how to use it I'll get like six people in a room We'll set up the get hub account We will open up a read me and we will write poetry and you go in and you edit line by line because it's exactly the same way of Thinking you creative would go in and you edit over someone and you have that process of going on my dialogue If you do that as the first of the first entry you have fun That's your first read me on your get hub for the rest of your career. It's really cool There I'm back online. I Love the idea of doing poetry for editing. That is fantastic You take completely the the fear of coding or anything out just say hey, you know We do something that that you can do and we'll just use a different process. We'll use the get up process. I love that Takes it. Yeah one thing that that you said is the reaction to train and build that confidence and get people to use the the tools and I think those are all really good You know strategies and things that we need to do and they're complementary to to what I was talking about So yes, I was ignoring it I was coming at it from a different perspective an angle of saying hey, we have the project and It might not be ready for someone to come where it might be appalling Some projects are just appalling for people coming. So how do I fix that? I I've tried everything and so this is where I'm saying well think of being someone else Taking a look at the project for the first time and then we can still do all the other things with the Salt and pepper song was that I don't actually know that song Okay, it's the is the audio hooked up to the laptop if I play it because Not right now, okay Okay All right Can you use the microphone, please? Oh, yeah, I guess I I just had a really interesting experience because I committed to Creating a new repo for a friend of mine, but then I was also moving this weekend So I was busy and so I just chat to BT my contributor MD file. It was really good I was like, hey, what are your best and gave me a bunch of guidelines. So like yeah, there's a lot of like Yeah, I just like cheat-coded it and it gave me a really good MD file. So Interesting Did you want yeah, so in terms of like having your if you're a maintainer having your Project ready for a PR party and that first time contributor one thing that I have struggled with is Having that good roster of good first issues marked and identified I love the fact that github like that is like default label that is now in any project that you start up but having that list there and Making sure that those good first issues don't escape into like just head knowledge or just you Thinking We're only thinking about big features. We're not thinking about minor bugs or Something that was maybe there's even just something that's out there that a person reported and didn't even like triage And it might be good as someone else who is new who is just trying your thing for the first time Even for them to like reproduce it and like add a comment and say yeah I ran into the same thing that this person did and then because they are Concretely thinking about it providing that additional context That is also I think didn't equally if not more valuable contribution to a project than just code So that might be something else that's out there. It's not just about the code It's just the basics of understanding what it is that the project needs to do Yes, thank you I'll pass on the microphone Yeah, just plus one in what you were just saying that the tricky thing too is even if you identify things that you think would be good first issues because maybe they are Documentation oriented or it's a bug that requires just a flip in the logic switch or you know, whatever Often those are not all-size fits all or whatever one-size-fits-all because you know everybody's applying their own opinion as far as what is a good first issue and One might have like a one-liner There we go, you know But it implies that you know a whole bunch of context that you don't right and so you have to not only think about You know what technically even if you can foresee I yes the fix to this will be three lines of code or whatever You still have to put yourself do what you were just saying put yourself in the shoes of the person looking for that first issue What are they gonna know, you know, if it's their real first issue? They probably need a lot of stuff spelled out So you might need to think about Templatizing like links to your docs that talk about specific things or things of that nature. I Feel like you have a direct response Yeah, so I ran into this thing one time I was just like stocking someone's like private repo, but it was like semi-public private repo, right? It was just their own Project, but at the bottom of it they said in case anyone else sees this and it was like in narrative form Just a paragraph description of like and I went to this blog and then I did this thing And then it was just like a paragraph of everything they had done to get to that executional code understanding And so now when We're at the stage of like finalizing documentation before we go to product I always request that a like semi-technical like a technical writer, but not an engineer that has not ever seen that before Comes in and because everything executes what resources do they need to conceptually understand it write that paragraph at the bottom? It's so useful and you can interlock your docs that way Awesome. Thank you for sharing that Did you have a thought? Yeah, go for it. Happy to Yeah on the kind of on the kind of cross-discipline point about like Actually that the point around Replicating the good first issue. I think that's really good for Cross discipline engagement with open source because one thing that test engineers ask me all the time or QA engineers You might call them in your org is like how how can I contribute to open source? Like the there's this perception that it is just code and it's only for developers Identifying those other ways to contribute. I think is is really good for I guess discipline diversity But also on the point of Helping people that are completely new to to contributing there was something actually spotted in some of those examples And I think it could go either way It was the phrasing of the instructions were along the lines of here are five easy and simple steps to get set up Now on the one hand that might encourage people to try it because it's like oh don't be intimidated by it But then if people Find it difficult that might be really disheartening and most of the advice I've read around things like that is Actually try and avoid saying this is easy. This is simple or like Don't use the word obviously because it might be obvious to you But it's not someone new to the tech stack or yeah new to new to open source full stop Yes Yeah, go for it. I think it's a really great point I was just gonna add I teach computer science and so I work with students all the time and One alternative that I've used sometimes to some success is to instead of specifying like easy obvious etc To like give a time bound and say like hey Give this you know give this task a shot for 15 minutes And if then if you're stuck reach out for help because then it prompts people that like I mean I know I've definitely ended up in loops where I've spent three hours Trying to figure out something that actually wasn't that I was misunderstanding something It's that like the docs were bad or the thing was broken, right? And so I I think that's one way that we can try and catch people from falling into that those loops That's like I like that that switch that both of you were riffing off each other because if we say this is easy and There's an a great XK CT on their everyone There are 10,000 people who hear something for the first time each day if you make certain assumptions everyone there's so many people who don't have that background that experience who for whom it's new and so Implying that no you're dumb because this should be easy is really detrimental a good point I like that work around with give it 15 minutes So anyway, we are Three minutes two minutes away. I just wanted to give you another quick teaser or something to to think about when it comes to think about problems in our community just a framework I Don't want to go into depth given the time and this is based on on research with this amazing research team We've done with the Apache software foundation Sponsored by Google three years ago where we looked at okay. What's actually? preventing people from really contributing and based on the interviews that we were Doing we also did a survey and looked at some trace data the interviews based on 19 interviews We arrived at a framework to think about the barriers that people were facing and We were categorizing those based on agency Where it's a question of who can actually do something about this problem in our project and The type of challenge is it a process technical or social challenge? So at the foundation level project level and individual level Versus those what we found is their majority of challenges were at the foundation and project level Not the individual and then many of those were process related and once we understand that we can have some Some recommendations what to do about it and in this study all the 88 challenges that we discovered were grouped like this in the framework and There is as we were grouping those that you can go to the paper it's at the bottom and actually find it so from the Statements in the interviews like It's also not super clear how the idea of rough consensus works and how to proceed of rough consensus cannot be reached That's that's clearly a process question that is not clearly explained or or trained and so Knowing these kinds of things then we can say okay at the foundation level. We need to do something about this and maybe provide regular training or provide clear governance documentation or Something where we bring people into the fold what that actually means I'm at time that there are more examples and I'll upload these slides you can go through those And here's the process. So thank you so much for for coming today being part of this conversation It's been a pleasure and I always enjoy learning from you You