Building an Inclusive Codebase
Our playbook for driving down non-inclusive terminology
By: Michael Bachand, Amanda Vawter, Dan Federman, Jake Silver, Julia Wang, Mark Tai
Code is our craft. At Airbnb, we view our code and product as a reflection of our values. Each developer imbues their work with a piece of themselves. We want all engineers to be proud of the codebase in which they work and the systems that they use every day.
We want to share with you some of the work that we are doing at Airbnb to build an inclusive engineering culture. We hope that sharing our story may energize and bolster similar efforts to eliminate non-inclusive terminology throughout the industry.
Bootstrapping Change
Airbnb’s mission is to create a world where anyone can belong anywhere. Continued violence and prejudice against under-represented groups threaten belonging and equality. Increased diversity in Airbnb Engineering will allow our team to better empower Airbnb hosts to serve Airbnb guests. It is imperative that Airbnb engineers from all backgrounds feel like they belong when contributing to Airbnb.
In the summer of 2020, we identified terms in Airbnb’s technical stack that undermine our core value of belonging. Team members proactively organized a volunteer effort in a Slack channel, working with employees from affected communities to operationalize change. Together we co-authored a proposal to address non-inclusive terminology in our codebase. Within a month, we presented the proposal to our CTO. He then prioritized this work by staffing dedicated engineer hours to make our code and systems more inclusive.
Acknowledgement and resourcing from the highest levels of management legitimized this effort. The legitimacy of the effort was further reinforced by smaller actions undertaken by individuals. Every task, pull request comment, and Slack reaction sent a signal that this work is valued by the business.
Building New Habits
We consider non-inclusive terminology to be a legacy style of programming that we want to eliminate. To that end, we began by measuring the usage of non-inclusive terminology in our code. We then broke the problem into two pieces: preventing new additions of these terms and driving down existing instances of these terms.
To address the first problem, we rolled out a linter to flag pull requests that introduce terms that Airbnb has deemed non-inclusive. We considered building our own linter, although ultimately we were impressed by an open source tool authored by an external engineer, Caitlin Elfring. The linter comments on each pull request that adds lines containing one or more of these terms. The pull request comment suggests alternative terms.
In order to build trust with engineers, we focused on making the linter actionable. We want the author to be able to resolve the linter’s comment in their existing pull request, without needing to edit code in another repository. Accordingly, we tend to exclude third-party code and code that is pulled in from upstream repositories when linting pull requests.
We began by introducing the linter to individual repositories, one at a time. We asked developers who were well-known in that codebase to drive the initial rollouts. These local experts were able to make judgements about which directories should be excluded from the linter and also had the trust of other developers in that codebase.
We have found success in raising awareness and limiting the addition of new terms with a non-blocking linter. We do not prevent an engineer from merging their pull request. Our belief is that with proper communication engineers will become aware that this is a business priority.
We now run the linter on all internal repositories at Airbnb. We have shifted our attention to driving down existing violations.
Strengthening Our Approach
For these initial terms, members of Employee Resource Groups (ERGs), such as Black@ and Able@, were involved in sourcing offensive word lists and implementing these improvements. For context, ERGs provide dedicated space for employees to join together around shared characteristics, interests, and life experiences. Black@ represents African-American and Black employees, and 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 documentation and Twitter’s post on inclusive language. We focused on an initial list of terms that was large enough to drive meaningful impact and small enough to avoid overwhelming engineers.
The motivation for this effort is for everyone to feel like they belong when working on Airbnb code and systems. To that end, we created an anonymous feedback form which gives any engineer a chance to surface their thoughts.
The anonymous feedback has led to concrete improvements, most notably in our list of terms. As an example, we originally suggested that engineers replace “grandfathered” with “legacy status.” Anonymous feedback informed us that “legacy status” was not an alternative that worked in many contexts, so we’ve changed the suggested alternative to “exempted.”
Anonymous feedback also highlighted that it was not clear why we linted for each term. Specifically, some employees wondered why “dummy” was on our list. For each non-inclusive term, we now document our reasoning and the history of the term. We link to these resources in each pull request comment posted by our linter. We feel responsible for making it easy for engineers to understand why we are asking them to change their code.
We view this project as a long-term initiative that will never be complete. As the world evolves, we will need to update our list of non-inclusive terminology, and update our code to reflect our current values. We are establishing a transparent process for expanding our list of non-inclusive terms. A diverse group of individuals that includes representation from the impacted community will consider each proposed term individually in close contact with all stakeholders. The process considers the impact of the term on individuals and communities, alignment with company values, and the scope of the work required to replace the term across our codebase.
Looking Ahead
We cannot run away from history, but we can inform the future. Driving down non-inclusive terminology is a piece of a larger effort that we will undertake at Airbnb and in the technology community at large to make engineers from all backgrounds feel heard, welcome, and valued.
Eliminating language that does not reflect our values shows engineers at Airbnb that we care for them, that they do belong, and that they are seen and respected.
Sharing Our Work
Thank you for your interest in promoting inclusion within technology. We are optimistic about the impact that this work can have within Airbnb and as part of a larger effort among our peer companies.
In order to support similar efforts across the industry we have made public the list of terms that we consider non-inclusive. We are publishing these terms as a simple data file that can be integrated with tools and systems at other companies, or forked and evolved based on varying contexts. We power our internal linter with this same data file.
