 Hello and good morning, good afternoon or good evening to you depending on where you are in the world at this time. My name is Joanna Lee and I'm here to speak with you about lowering barriers to inclusion and open source ecosystems. A few words about myself, I live in Portland, Oregon, my personal pronouns are she and her, and I am an attorney and partner at the law firm of Gassmer up to Grove where I serve as an advisor to technology companies to technology standards consortia and too many open source projects and foundations, including the Linux Foundation and many projects hosted by the Linux Foundation. Gassmer Grove as a firm has several decades of experience representing technology consortia open source projects and open source foundations. Today we're going to talk about the current state of diversity equity and inclusion open source, the barriers for participation by many underrepresented groups and how open source communities can lower these barriers. To make sure we have a common understanding around shared terminology. I just want to remind you that diversity is a number. Equity is an outcome and inclusion is a process. There are several underrepresented groups in open source, most notably women, although 18 to 30% of developers in the US and 27% 27.5% of developers in the world are women only 3% of open source contributors are women. Although 39 to 48% point 6% of developers in the US belong to ethnic or racial minority groups, only 16% of open source contributors do. Also note that 79% of open source contributors do not speak English as our first language, even though English is a primary language of many open source communities. Other groups that are underrepresented or disadvantaged in participating in open source include parents and other people who are caretakers for family members, because they have less free time to contribute. Individuals who are not cisgender, people who are not fluent in English, people with certain types of disabilities, people without access to high speed Internet. People with access to computing devices that have limited capabilities and may not support many popular developer tools and non technical contributors. Sometimes I get asked, well, open source is open to everybody. Everyone has an equal opportunity to contribute. Isn't that enough to say open source by its nature is inclusive and equitable. So equality and equity are not the same thing and equal access and equal opportunity does not always result in an equitable outcome. So, in these three pictures on the slide, the picture in the left, this is what equality looks like. So there is this barrier to being able to see the soccer game on the other side of the in the form of this fence. Each person is given an equal amount of support. And yet there's not an equitable outcome. Not everybody can see the game. And then in the middle picture we've achieved equity because a person who needs the most support has been given the most support. Now everybody can see and enjoy the game. And in the picture on the right. This is what justice looks like. This is when the systemic barrier to inclusion has been removed so that everybody can participate and be included without needing special support or accommodations. It's important to recognize that there are barriers to inclusion and open source and contributing to open source is a privilege that is not universally enjoyed by everybody equally. But is an open source a meritocracy. Well I'm going to share a quote with you from the founder of Drupal systemic issues like racial and gender wage gaps continue to plague underrepresented groups. And it's both unfair and impractical to assume that these groups of people have the same amount of free time to contribute to open source projects if if they have any at all. What this means that open source is not a meritocracy. It doesn't matter when contributing to open source privileges such as having ample free time being fluent in English, having access to reliable high speed Internet, and expensive computing devices, having a high degree of technical confidence and access to mentors in a support network that's already plugged into the open source community. These privileges make it easier for some groups of people to contribute than others. The barriers can intersect and stack up to exacerbate inequity. How can open source communities lower the barriers. We're going to do a deep dive into each of these practices in just a moment, but here's a list provide better documentation and tutorials, develop a welcoming and respectful culture. Code of conduct design your processes for inclusion. Use accessible communication methods and inclusive language, welcome and mentor newcomers and support developers from underrepresented groups. You made it notice that most of these inclusive practices. They are best practices for any healthy thriving open source community and aren't targeted just at underrepresented or historically disadvantaged groups. And that's very true. So, lowering barriers through inclusive practices does benefit everybody and this is known as the curb cut effect. In the 70s curb cuts were introduced at street corners to make it easier for people who use wheelchairs to get across the street. However, it's not just people using wheelchairs that benefited from curb cuts. It's also people with baby strollers, people with luggage, people using hand trucks, people on skateboards and scooters and roller skates. Similarly, an open source. When we lower barriers through inclusive practices, it does benefit everybody, not just disadvantaged groups. Documentation is so important to building inclusive communities. Having clear documentation that describes how to contribute is highly valued by developers. Many developers considered very important to deciding whether to contribute to an open source project and this is even more true for members of underrepresented groups, including women. There are updated documentation levels of playing field by making critical information about how to contribute and participate accessible and visible to everyone, including those who don't have pre existing access to the tribal knowledge. Unfortunately documentation in open source tends to be notoriously bad. What I think are confusing documentation is the is a top complaint about open source, according to GitHub's 2017 survey. Despite this, most contributors say that they rarely or never contribute to documentation, given that documentation is critical to inclusion. And to a documentation issue. Help out by contributing improvements and thank others when they contribute to documentation. Here are some resources for how to write great documentation. It's also important to develop and maintain a welcoming culture. A welcoming community is very important to many developers when deciding whether to contribute to a project. And it is especially important to members of several underrepresented groups. When asked what would make you likely to contribute to open source 26% of women in comparison to 16% of men responded if the open source community was more inclusive. How do you develop a welcoming culture. Well, first of all, it's important that project leadership models friendly and welcoming behavior. Don't penalize people for asking questions, create a welcoming environment where people feel safe enough to ask them questions. We're creating a community team that supports contributors by responding to newcomer questions and helping to select tasks for newcomers who are unsure where to start the Firefox debugger community team is a great example. Also consider developing one or more formal mentoring formal mentoring programs. It's also important to prevent and manage bad behavior in open source communities. This is a critical aspect of having a welcoming inclusive culture. Unfortunately, rudeness and unwelcoming language are very common in open source. And although more extreme forms of bad behavior such as overt harassment, stalking or unwanted sexual advances are less common. They don't occur they are highly visible. 45% of open source contributors have witnessed and 16% to have experienced rudeness. Negative experiences have real consequences for project health. 21% of people who have experienced or witnessed a negative behavior said that they stopped contributing to a project because of it. What the community can do to prevent and manage bad behavior is to adopt a code of conduct. This signals to the developer community that your project cares about respectful behavior. Codes of conduct are important to many developers, more than half in deciding whether to contribute to an open source project. It is even more valued by members of several underrepresented groups. You can't just adopt a code of conduct though you have to enforce it in a fair and transparent manner. If you don't have adequate transparency regarding processes. It's hard for community members to tell the code of conduct is being enforced at all, or whether it's being enforced fairly, and thus hard for them to know what extent to trust the code of conduct. Make sure you have very clear policies available to the whole community about how violations can be reported. What the consequences of violations are, who's staffing the committee that investigates and responds to violations, and what policies you have to protect the reporters anonymity. Be really mindful about anonymity and confidentiality. Unless you have both reporters and victims consent, don't publish information that could be used to identify them, or else you are increasing the risk of retaliation against them. Also make sure you have a truly anonymous mechanism for reporting email is not anonymous so consider having an online form that can be completed without personal information attached to it. And is sometimes received to be in the hands of the wrong people so be really thoughtful about who staffs your code of conduct committee. And also note that codes of conduct are often met with resistance by a small but extremely vocal minority of community members by choosing a code of conduct that's already recognized and widely adopted by other open source projects. It can really help because then you avoid the challenge of having to establish its legitimacy. And also give people tools to protect themselves whenever possible. Tools that allow people to block other users who are engaging in bad behavior is often more effective than enforcement from third parties design processes for inclusion, including designing around bias, if that is a concern. Any bias against underrepresented groups does still exist in our society and in many open source communities. A 2016 study of 50 GitHub repositories found that women's pull requests are just as likely or even more likely to be accepted than men's pull requests, when their gender is not easily identifiable. When gender, once gender is easily identifiable, the acceptance rates of women's pull requests drops significantly, indicating bias is present. A more recent study that's quite similar of 10 open source projects found that although bias does exist in some projects, it does not exist in all open source projects and so is not universal. The only project showing the most bias against women also had declining ratios of women contributors during the last several years. In 2018 Firefox released about browser extension designed to address this issue. This extension redacts authors information from review requests on GitHub to reduce the bias in code reviews. So bias can go the other way as well. Reviewers may be less critical of work done by their own friends and peers and colleagues. So hiding identities can lead to more thorough reviews, and thus better code overall. Give some thought to whether the communities and projects you to participate in can redesign processes similarly to either eliminate bias or otherwise level the playing field for underrepresented groups. Use inclusive and accessible communication whenever possible. Almost a quarter of the open source community reads and writes English less than very well. For people who are not fluent in English. It's easier to understand written English than understand spoken English. So whenever possible provide captioning or transcripts of videos presentations meetings and other key project communications and provide a variety of methods for communicating. This communication is preferable to spoken communication for those who have limited bandwidth, who identifies introverts, who are not fluent in English, or who have hearing impairments. When communicating on a project strive to use really clear language that can be understood even by people whose first language is not English. Whenever possible avoid technical jargon that can make newcomers and non technical contributors feel lost. Studies show that there is often a technical confidence gap between men and women and avoid jargon can help lessen this barrier. And note that confidence is not the same thing as competence to people can be equally skillful but one of them might have more confidence than the other. Also provide a glossary of commonly used acronyms and technical terms for your project. Also strive to use language that is inclusive. In recent months and years, open source communities have been replacing master slave terminology with alternatives such as leader follower primary replica active stand by and parent child. There is also a similar movement to replace the terms of black list white list with approve list denial list. These language updates are aimed at greater exclusivity. However, they have been heatedly debated within developer communities and criticize as being unnecessary or being mere political correctness. Another thing really important to understand is that inclusive language is not about political correctness. It's about communicating in a manner that helps everybody feel welcome and included. Words are powerful. They can be used to unite or divide people. They can be used to inspire or to cut people down. So don't underestimate the importance of language. Non inclusive language can alienate people and cause them to feel othered or unwelcome. The use of certain words makes some people feel uncomfortable. It's probably worth the effort to use different words. Let's talk about a few inclusive language principles. Put people first whenever possible. So strive to use language refers to the person and emphasizes their personhood before their identifying characteristics. For example, a sentence construction, referring to a person with a disability is preferred to referring to a disabled person. Also, if an identifying characteristic isn't relevant to the discussion at hand, don't mention it. So for example of gender is not relevant to the discussion. Instead of Jordan is an experienced female developer, just say Jordan is an experienced developer. There are exceptions to this guideline. For example, when identifying characteristic is really central to the point being made. For example, saying that the Cuban cosmonaut, Arnoldo Tamiya Mendez was the first black man to fly into space. Another principle of inclusive language is that you refer to people the way that they want to be referred to. Although the golden rule is to treat others the way you want to be treated, the platinum rule is to treat others the way that they want to be treated. And this also applies to what terms we use to describe people. So another possible exception to the put people first guideline is that some members of some communities do prefer identity first language. Research the ways the people in the communities you refer to prefer to be identified. However, sometimes individuals from a common community will prefer different terms. For example, one person might refer to themselves as African American, whereas somebody else with the same ethnic background might prefer the term black or person of color. So respect these individual preferences and also respect each person's personal pronouns. If you don't know somebody's personal pronoun default to the gender neutral they avoid us centric or culturally specific idioms and metaphors whenever possible, because these expressions will not be understood universally by all people, and could result in some people feeling left out embarrassed. For example, people who do not live in the US, and even many people who do live in the US aren't necessarily going to understand football analogies. This football is a very American sport. So instead of asking will you quarterback this effort ask, will you lead this project. Some other principles of inclusive language include avoid using socially charged terms and language that perpetuate stereotypes. This is an expression like man up perpetuates gender stereotypes, and is really offensive to everybody, regardless of gender. Be mindful of using any identifying characteristic in a way that's judgmental for some, for example, something that seemingly innocuous like saying, This is so ghetto, or we're really slumming it. This is somebody who grew up in an economically disadvantaged community to feel embarrassment about their background. When referring to illness and disabilities avoid ableist language and language that suggests the victimhood. So for example, it would be better to say that somebody is experiencing blindness, then that they are suffering from blindness. And by ableist language, I mean, don't use language that makes the assumption that some people are normal, because they don't have a disability. So rather than refer to non disabled persons as normal or healthy just refer to them as persons without disabilities. Also avoid gender language when gender is not relevant to the conversation. So for example using the term chairperson would be preferable to chairman. So avoid using language that assumes that there are only two genders male and female. So it would be better to address your community as valued community members or esteemed guests, rather than ladies and gentlemen. There are so many more inclusive language principles I would love to share with you but we unfortunately just don't have enough time today. So I would like to direct you to some other resources. One is inclusive prism inclusive language guidelines. So inclusive prism is a project that I founded. It includes resources on inclusive language best practices contains a list of terms to avoid, including some common technology localisms such as male and female connector, and suggested alternatives. So it's still being built at the time of this conference. So it's not up yet but check back in a couple of weeks and we'll be live and the guidelines and the resources will also be on GitHub so if you have any recommended changes, please consider contributing them language does change over time. And so it's important that these resources be living resources that evolve. I also recommend the responsible communication guide Barry compiler media and Google has some tips for writing inclusive documentation. I also recommend that if you feel inspired to do so participate volunteer donate to or other ways contribute to diversity equity inclusion initiatives for open source. So organizations and projects that during fantastic things really move the needle. In terms of supporting underrepresented groups in getting involved in open source. If you have any questions or if you'd like a copy of these slides. Feel free to contact me after this presentation by email and also feel free to connect on LinkedIn. Thank you so much.