Building an Inclusive Codebase

Michael Bachand
Jun 15, 2021 · 6 min read

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

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

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.

An example GitHub comment posted by the inclusive linter.

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

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.

Engineers can submit anonymous feedback via a Google Form.

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

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

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.

The Airbnb Tech Blog

Creative engineers and data scientists building a world…