We reduced the non-inclusive terms in the game manual
The author: Michael Bachand, Amanda Vawter, Dan Federman, Jake Silver, Julia Wang, Mark Tai Michael Bachand,Amanda Vawter,Dan Federman,Jake Silver,Julia Wang, Mark Tai
The code is our craft. At Airbnb, we believe that our code and our products are an expression of our values. Each developer injects his or her own piece into their work. We want all engineers to be proud of the code base they work with and the systems they use every day.
We wanted to share some of the work we’re doing at Airbnb to build an inclusive engineering culture. We hope that by sharing our story, we will inspire and support similar efforts to eliminate non-inclusive terminology across the industry.
Guide the change
Airbnb’s mission is to create a world where anyone can belong anywhere. Continued violence and prejudice against underrepresented groups threaten belonging and equality. Increasing the diversity of Airbnb’s engineering department will enable our team to better empower Airbnb hosts to serve Airbnb guests. Airbnb engineers from all backgrounds must feel like they belong when contributing to Airbnb.
In the summer of 2020, we found clauses in Airbnb’s tech stack that undermined our core value of belonging. Team members took the initiative to organize a volunteer event in a Slack channel, working with employees from the affected communities to implement the changes. We co-wrote a proposal to address non-inclusive terminology in our code base. Within a month, we submitted the proposal to our CHIEF technology officer. He then made it a priority to put in dedicated engineer time to make our code and systems more inclusive.
The endorsement and allocation of resources from top management legitimizes the effort. Small actions by individuals further enhance the legitimacy of the work. Each task, the comment pulling the request, and Slack’s response sends a signal that the work is taken seriously by the organization.
Create new habits
We consider non-inclusive terminology to be a traditional programming style that we want to eliminate. To do this, we first measured the use of non-inclusive terms in our code. We then split the problem into two parts: preventing new additions to these terms and reducing existing instances of these terms.
To address the first issue, we introduced a linker to flag pull requests that introduce terms that Airbnb considers not inclusive. Linter comments on each additional pull request that contains one or more of these terms. Comments that pull requests suggest alternative terms.
Example GitHub comment posted by Inclusion Liner.
To build trust with engineers, we focused on making Linter operational. We want authors to be able to resolve Linter’s comments in their existing pull requests without having to edit code in other repositories. Therefore, when we polish pull requests, we tend to exclude third-party code and code pulled from upstream repositories.
We started by introducing Linters into warehouses, one at a time. We asked well-known developers in the codebase to drive the initial push. These local experts are able to determine which directories should be excluded from Linter and are trusted by other developers in the code base.
We have found that non-blocking sinters have been successful in raising awareness and limiting the addition of new terms. We do not prevent engineers from merging their pull requests. Our belief is that with proper communication, engineers will realise this is a business priority.
We now have Linter running in all of Airbnb’s internal repositories. We have turned our attention to reducing existing violations.
Strengthen our approach
For these initial words, members of the Employee Resource Group (ERG), such as Black@ and Able@, were involved in procuring lists of offending words and implementing these improvements. In terms of background, ERG provides dedicated Spaces for employees to gather around common traits, interests and life experiences. While Black@ stands for African Americans and Black employees, Able@ supports those with disabilities, chronic conditions or mental health conditions. At Airbnb, we have 19 employee resource groups.
We also reviewed similar initiatives across the industry for inspiration, including Google’s guide on writing inclusive documents and Twitter’s post on inclusive language. We focused on a preliminary list of terms that were large enough to drive meaningful impact but small enough not to overwhelm engineers.
The motivation for this work is to give everyone a sense of belonging when working on the Airbnb code and systems. To that end, we created an anonymous feedback form to give any engineer a chance to float their ideas.
Engineers can submit anonymous feedback via A Google form.
Anonymous feedback has led to concrete improvements, most notably in our list of terms. For example, we initially advised engineers to replace “grandfather” with “legacy”. Anonymous feedback told us that “legacy” was not a viable alternative in many cases, so we changed the suggested alternative to “exemption.”
The anonymous feedback also emphasized that it was not clear why each term was tagged. Specifically, some employees wanted to know why “dummies” were on our list. For each non-inclusive term, we now document our rationale and the history of that term. We link to these resources in every pull request comment the Linters post. We felt it was our responsibility to make it easy for engineers to understand why we were asking them to change the code.
We see this project as a long-term initiative that will never be completed. As the world evolves, we will need to update our list of non-inclusive terms and update our code to reflect our current values. We are establishing a transparent process to expand our list of non-inclusive terms. A diverse team, including representatives of the affected communities, will work closely with all stakeholders to consider each proposed term on a case-by-case basis. This process will consider the term’s impact on individuals and communities, its alignment with company values, and the scope of work needed to replace the term in our code base.
Looking to the future
We cannot escape history, but we can inform the future. Eliminating non-inclusive terminology is part of our larger effort at Airbnb and the tech community at large to make engineers from all backgrounds feel heard, welcomed and valued.
Eliminating language that doesn’t reflect our values shows Airbnb engineers that we care about them, that they do belong to us, and that they are seen and respected.
Share our work
Thank you for your interest in promoting inclusion in the field of technology. We are optimistic about the impact this work can have both internally at Airbnb and as part of a larger effort at our peer companies.
To support similar efforts across the industry, we have made public a list of terms that we believe are not inclusive. We distribute these terms as a simple data file that can be integrated with other companies’ tools and systems, or forked and evolved for different situations. We use this data file to power our internal linter.
Building an Inclusive Codebase was originally published on Airbnb Tech Blog, and people continued the conversation on Medium by highlighting and responding to the story.