 Thanks for being here. My name is Geo Blink. I'm the director of sales at Biturgia. I'm also a co-founder of the Chaos Project and I am working together with Anita Sama towards writing a book on diversity equity inclusion in open source. And so what I'm going to show you today is a section of the book that we are working on and some insights from research. To motivate this let's take a step back and look at diversity equity and inclusion in open source. GitHub did a survey back in 2017 and found that there is a gender imbalance in open source. 95% of respondents identified as men, 3% as women and only 1% as non-binary. Mozilla had better results, 58% identified as male, 33% as female and 9% as other. A year later looking at OpenStack, the OpenStack community report found that 10% identified as women. It was even better when we looked at the leadership level where they found 20%. So there was this awareness that started to come about that okay this does not reflect the general population that we live in and open source seems to be different. And so a lot of recommendations were made on how we can start to address this and ideas are around having code of conduct and enforcing them to create welcoming environments and having clear guidelines on behavior because there was a sense that there was toxic behavior and the men were being assertive and pushing out anyone else who could not take the heat basically. And so there was work to enact structural change, create identity groups, safe spaces, give minorities or underrepresented groups a place where they can be amongst themselves and discuss their concerns or have a group where they feel they belong more so within open source. Maybe we can improve documentation and help anyone else to come on as well, provide spaces for newcomers, be super welcoming and say hey you know you are welcome here, come on in. You can also localize efforts, avoid jargon, this is around global diversity and people with not English as a primary language because of open source is in English. And yeah so anyway there's a lot of ideas on how we can start to address this issue and this was five years ago. Now looking at today where are we today? Did we make any progress? The Linux Foundation did a survey last year and still found that 82 percent of men identified as men. Numbers are starting to look better but still huge imbalance. The 82 percent shows up again in their question whether the respondents feel welcome in open source. Big surprise, 82 percent are men, 82 percent feel like they're welcome and then demographic segments there showed varieties. I didn't dig too much into the details, this is just to say here there's something going on. Now 81 percent happened to also be really good at English, showing that language barrier is another concern to look at and then turning it around to ask okay do equal opportunities exist? Now we had only 22 percent say yes, most people or no 22 percent said no, most people didn't see an issue, most respondents did not see an issue and said yeah of course. So one more, last one. When the respondents were asked you know do you think some aspect of your identity was a problem? 30 percent said yes. So we're starting to see a pattern here that there's something going on and what might be happening is that we have unconscious bias in our open source communities that there is a problem that we are not aware of if we are in the majority, we don't see it. Imagine for example that a project was writing all of its documentation so that the maintainers were understanding it because they had a certain way of thinking and they always flew with all of these gauges and dials and information and that's how they used to navigate. Now if someone comes along who prefers a way of you know having a map, looking at the landmarks, deciding where to go, not based on numbers and metrics and degrees on wherever, now you need different instructions, you need a different way of saying here is how you get certain things done. So there people have different approaches to how they solve problems and the program, the projects when they're written to only serve one certain way of solving problems, one certain way of thinking, everyone else is being left out and this is what research has found. When we look at the research and look at problem solving styles, there were five facets that have been validated time and time again by different research studies and we can construct a stereotypical man and a stereotypical woman and see that they approach problems differently. One facet is motivation. Men typically like to explore all the available functionality on their devices and really try to understand the technology and enjoy that and that's great. Women on average, stereotypically, use technology to accomplish a task but then they're okay. I've done that. I don't need to understand or really enjoy going into all of it. Again this is stereotypical. Not everyone is the same way and this is just on average. Another facet is computer self-efficacy. Men on average have a high confidence in their technical ability and if a problem exists and can't be fixed then it's the developer's fault or the manufacturer's fault. But I know my technology. I know how to do it. Women have a more self-blaming themselves if something doesn't work where they say, okay, I'm not understanding it. I'm not familiar. The technology probably works. I just don't know how. Different perspective. There's also an attitude towards risk where men on average don't mind pushing buttons and seeing what happens and if it breaks, they restart it and try to get to work again. Women are more careful. I don't know what this does. I'm going to ask for help maybe first or try to understand what is supposed to happen and that goes on to the next facet, the information processing style where men have a selective information processing approach where it's like, okay, so I see this. Okay, I'm going to do this and they get the information as they need it to do the next step and only look for that information and then they find that piece of information that they need to then move to the next step. Women like to have a complete understanding of what is supposed to happen from to end. What is the whole process and have a comprehensive information before starting to embark on the process of trying out things or clicking buttons or whatever and then the last one is learning by process versus tinkering where men like to tinker and explore and just see what happens. The women like to have a process and like to okay, I'm getting work done going back to that idea doing the steps needed but I know that process. I don't know what happens if I do something else along the way because that doesn't help me get my job done. So again, this is validated by research that there is this average tendency towards different ways of approaching problems and of course there are many different people who don't fall into these clear stereotypes. But maybe that's what's going on if you think about the way that documentation is written. If it is written for someone who likes to do the selective information processing it says go here do this, go here do that, go here do that and it might not describe the front end process all overall. So there might be different things that we want to or different ways that we need to present our projects and how they're built and documented. But how do we address that? If we are not aware of this ourselves, what tool do we have to combat this unconscious bias that we might have in our projects? So this is where we propose to use the idea of squashing diversity bugs. We are familiar with squashing bugs in open source where someone reports a bug or discovers it and we need to investigate and understand and triage and figure out okay what's causing it and how we can resolve it and then actually taking the steps to resolving it. And this is where I want to thank Anita Asama for introducing me to this idea and to this method because she's been doing research on this for a long time and so I credit her for that. So let's do one example what this could look like and then I'll give you the tools to actually do it yourself if you wanted to do it yourself later. And if you're looking for any more information along the way gendarmag.org that's where the example is from and that's where all the tools are so that you can do this. So to discover let's pretend to be walking in someone else's shoes. Let's take on their identity for a moment and look at our project. So let's say we are someone who comes to the project and wants to fix documentation. What do we see in our readme? How do we contribute back? There is yeah we like help with code and if you want to contribute there's simple steps you must follow. It takes about 30 minutes to get set up. For someone who wants to contribute to the source code that might be acceptable. Someone who just wants to fix a comma or typo does not see anything that says okay here's how I can do this. And so once we understand okay someone who has that intention with our project maybe they need a different description in the readme and we can add okay here work on documentation. We'll provide you with more information maybe you're not as familiar with the github workflow and we provide more you know the comprehensive information processing what all is involved. And so we don't just say okay go edit the readme file but we say step by step here's what the workflow to contribute to documentation actually looks like. So that's one example where we just put ourselves in shoes of someone who is not as familiar with the project who is coming from the outside. So what what can that look like? Well if we go and try to do this ourselves for our projects we first want to identify what intention is someone coming to our project with. What do they want to do? Someone who comes new might want to interact with the issue tracker to find a good first issue to start contributing to the project. How do they go about doing that? Or maybe they want to report a bug or request a new feature. We can look at other parts of the project around the code review system maybe the readme contributing installation guide tutorial website there the different things that people want to do in all of these places they're interacting with our project. So the approach is to pick one and start walking through the steps. So let's say we want to pick make changes to a readme as a goal then we need to identify okay what are actually the steps involved in doing this. We need to be clear ourselves how someone goes about doing this and we can write this down by okay this is my ultimate goal and then there are sub goals that we need to do. One is to edit the file but then another is to actually submit that for review. And then what are the actions? What needs to be done? What buttons need to be clicked? What information needs to be provided? How do I see that I'm following the process correctly? So at this stage we write down okay what needs to be done to contribute in this way and then we get to select okay in whose shoes do we want to be walking. So this is where we go back to the five facets and we say okay do we want to be someone who is enjoys it or who is more looking out to just accomplish something or someone who is processing information more comprehensively or selectively and we can mix and mix these however we want. We can build our own persona. We don't have to stick with the stereotypes that we came up with because we want to put ourselves in this in this person's shoe that we are constructing and then ideally we do this together with two others because we have different ways of putting ourselves in someone else's shoes and then we have better discussion about what we are seeing. So now that we are sitting down to look at our project with two others we can go through the sub goals and see okay would this person that we are pretending to be come up that yes I need to do this edit the written file create the pull request if yes good why would they say because they they like to tinker okay good or maybe not maybe they are create a pull request maybe they don't come up with that because they have never heard of a pull request because this person that we are pretending to be doesn't know that a pull request is a way to save a file in a project that which is their mental model that they have from working in work what they are more used to and then we can say okay their attitude towards risk that is the reason why they would not come up with this sub goal and we'll analyze this later right now it's just let's keep track of how someone would approach solving this and then the individual steps the individual actions similar form would someone take the action and also what they know after taking the action that they have done the right thing and on the right track to reaching their goal and again if any of these facets get in the way we mark it and quickly write down why not and then we sit down afterwards and discuss with our two others how how we did how many steps did we have issues with were those issues related to the personality to the problem solving facets that we identified and then how how would we go about solving this how can we alleviate this do we need to make changes in the user interface which they have been proposal to improve the github interface to help people who are not familiar with or do we need to add documentation or if we are looking at our software itself maybe there are things we can do within our software if that is part of reaching the goal and and we can analyze especially when an issue around arose from those facets that's when we have in di but if the issue was related to something else then that's okay too we can still fix it and improve it for everyone and the research that Anita and her team has done has showed that once we go through this process that the imbalance of people who have problems not only decreases they're on the same level but they're both at a higher level by fixing the issues in our project for the underrepresented groups improves it for everyone and everyone has has a easier time to contribute and then we just keep going through this process we do it for different personalities from different angles for different parts of the project and we go through these steps discover understand resolve and then we squash our d i bucks and that that's the idea in a nutshell there are resources at gender mac where you can look into the research you can get the kit and the forms and the personas there are flyers and information on on this process and i hope i hope you find this a useful tool i'd love to discuss this with you and thank you for coming any thoughts on what i just presented the facets of the problem solving styles thank you yeah so the the five facets of of problem solving styles i think are are really interesting um i am i'm wondering in general because if i take off the headings yeah right what i see there are systemic like societal structural issues not necessarily open source ones so i'm wondering if there's not really actually quite sure what i'm getting at but i'm wondering if if um squashing these d i bugs are almost just plain old barriers for different different types of systems people who grew up in different types of systems i don't know if that resonates at all but what comes to mind is i just did a dark Dublin tour the other day and the guide was telling us on a side note he was opening the door for someone else that chivalry was a symptom of women not being allowed to have their own money and so that's why men always paid for them and then that perpetuates the stereotype that women are not good at managing finances and so there are societal systems in place that i think we have started to breaking up over the last decades centuries that that might also be factoring in here but it's worth looking more into yes yeah no i like the i like the process especially with how um how similar it is to doing user stories which is a familiar concept of folks so yeah it's very cool thanks yeah and user stories you typically do before and then here's how you basically go back to the user stories and if we relate to that approach yeah i like that and i can help the mic just want to say thank you so much for the talk and yeah i've not heard of gender mag so that's interesting of something to look at what i was interested is um how many kind of examples of projects there using those this method and whether it's still majority like english speaking open source projects more kind of us and europe based whether you know or or not because that that that will be interesting actually to look at maybe repositories in other languages and whether they've used similar methods the approach should be generalizable and be available for anyone because i don't see why it would be english specific but the examples the research team is based in oregon in the united states and so yeah the project they have worked with and the companies they've done it in companies uh those have been english speaking so i don't know of any examples from outside because of that yeah so yeah we we have these these maybe systemic differences but but there are also personality differences and even if we were to eliminate the the bias at a systemic level we would still have just different kinds of people so it's good to approach open source look at it but yeah looking at the numbers from before there it just makes sense that if someone or a group of people is thinking a certain way that's the way they embed into everything that they create and then someone else who thinks in a different way just has a harder access it's like a cognitive tax that we are putting on people well thank you so much for coming i appreciate you coming out i know today is the last day of the conference so have safe travels back home and i hope to see you in the future