Guest blog post by Barathy Rangarajan, DreamWorks Animation
What does “inclusive language” mean?
Within technology, one of the ways to drive a more diverse, equitable, and inclusive culture is to replace “offensive” language in code bases and documentation. This involves assessing existing code bases and documentation, identifying potentially problematic language, and replacing terms with more acceptable language. By using more inclusive and intentioned language in code and documentation, we create an environment for developers where differences are welcomed and identified as strengths.
The effort to fix code and documentation to be inclusive can be tricky though. Implementing change across whole repositories may require a unified team or studio effort. What’s more, without a certain level of self-awareness, it may be hard for some people to recognize terms that others may find offensive or disrespectful. Language that may not stand out to some people at first glance could provide discomfort to others, such as the formerly-common naming convention of “master” and “slave” processes.
In order to help increase awareness and provide a base to start from, we have created this guide to identify examples of non-inclusive language, provide ideas for replacement language, and discuss inclusive strategies currently in development at some companies.
General Guidelines When Writing Code or Documentation
- Avoid using terms that have social history. Terms that can have historical significance or impact in regards to race, ethnicity, national origin, gender, age, mental and physical ability, sexual orientation, socioeconomic status, religion, and educational background.
- Avoid using idioms and jargons. These can exclude people who don’t have particular specialized knowledge, and many idioms don’t translate from country to country. Additionally, these sometimes have origins in negative stereotypes.
- Write inclusive examples. Try to avoid using examples in documentation that is culturally-specific to a particular country, and be sure to use diverse names.
- If you’re unsure, ask! Try to be conscious of language choice and ask around if unsure about if certain phrasing could cause discomfort.
List of Common Terms and Recommendations for Replacements
Socially-charged language: Language that has historical or social roots, often assuming one classification as dominant over another.
- Master, slave → primary/main, secondary/replica
- Owner, master → lead, manager, expert
- Blacklist → deny list, exclusion list, block list, banned list
- Whitelist → allow list, inclusion list, safe list
- Native feature → core feature, built-in feature
- Culture fit → values fit
- Housekeeping → cleanup, maintenance
Gendered language: Language that either assumes the gender of the users and developers, or that makes assumptions of a gender.
- Man hours → labor hours, work hours
- Manpower → labor, workforce
- Guys (referring to a group) → folks, people, engineers/artists
- Girl/Girls (referring to women age 18 and older) → woman/women
- Middleman → middle person, mediator, liaison
- Gendered pronouns (he/him/his, she/her/hers) → they, them, theirs
Ableist language: Language that assumes a certain state of body or mind as superior to others.
- Crazy, insane → unpredictable, unexpected
- Normal → typical
- Abnormal → atypical
Ageist language: Language that makes assumptions based on age or that reinforce an age-based stereotype.
- Grandfather, grandfathering, legacy → flagship, established, rollover, carryover
Violent language: Language that practices a degree of aggression or machismo.
- Crushing it, killing it → elevating, exceeding expectations, excelling
Examples from Companies Currently Trying to Address Non-Inclusive Language
Many companies have already begun implementing strategies to remove non-inclusive terminology from code repositories, documentation, and code comments.
Autodesk
Autodesk, for instance, has taken an assertive and immediate strategy to address insensitive terminology across all projects. Nancy Haj, Project Manager for Maya and Arnold, mentioned that Autodesk created a dedicated task force composed of employees across various roles to take charge of this full company initiative. The task force had to come up with an implementation strategy, including defining what they wanted to achieve and how far back to go into old code.
What ultimately resulted was a shared document to be referenced by all development teams across Autodesk. This document included a list of terms to change, a standardized alternative to use in place of that term, and examples of how this rewrite might look, for additional clarity. In order to enact this strategy across the company, the changes would be rolled out in multiple phases across several months. During each phase, a new subset of terms from that list would have to be addressed by each team. For accountability, the teams had to report back updates on their progress, and each team gave a time frame on when they thought they could deliver on making the changes in their code. This would allow for planning for teams to take adequate time needed to enact the changes.
Autodesk is currently in the second phase of this initiative.
DreamWorks Animation
DreamWorks Animation has taken a top-down approach to start its push for change. The technical leads for each of the R&D teams have been discussing strategies to address insensitive terminologies, and specifically have focused on the “master” branch naming that is used across the code repositories. With over 1,500 active Github branches across multiple departments that utilize the “master” naming, this is not as simple of a task as it first seemed. Github does not have a mechanism for renaming branches. This means teams need to create and adopt an alternative branch before eliminating the “master” branch. The leads are working with all the teams involved (including those in Production) to develop a migration strategy with minimal impact to code bases in active use.
In conjunction with broader company efforts to raise awareness around inclusive language and avoiding bias, there is also a grassroots effort across teams where the technical leadership is working to replace “offending terms” in new releases of software and stressing the importance of utilizing more inclusive language as part of the daily workings of the team. Setting an example and calling out where better language choices can be made (such as use of gender neutral language to refer to a group as “engineers” instead of “guys”), makes this front of mind for teams and encourages better language choices in code and documentation.
Having a diverse workforce is also critical to better recognize and change non-inclusive language. To this point, the studio as a whole has rolled out a massive diversity, equity, and inclusion initiative that additionally looks to improve diversity hiring. The studio has also promoted diversity employee resource groups and diverse technology-focused resource groups, such as TECHWomen, to better educate employees through events and increase social awareness in fixable areas like non-inclusive language.
Sony Pictures Imageworks
Like DreamWorks, Sony Pictures Imageworks is also in a top-down investigation phase in their push to implement more inclusive language across their code. To this end, Michael Ford, SVP Software Development and Systems Engineering, has described the evaluation strategy being used as a determination of the accessibility of the change relative to the impact of that change. The investigation team is constructing a priority list of terms to address as well as the time it would take to make the changes for that term. Once this investigation has concluded and a list of terms has been identified and prioritized, the team will look to roll out immediate action.
A big consideration during the investigation phase for the team is determining how to effectively communicate the necessity for the change to the developers. This includes anticipating any concerns and questions the developers may have, and constructing the narrative to provide perspective on how a lack of change would create more harm.
In Conclusion
For companies in the process of implementing their own inclusion strategy or in the starting stages, networking and learning from other companies with current initiatives may be helpful. Ultimately diversity, equity, and inclusion needs to be a whole industry effort, and we encourage technologists to collaborate and share their inclusive strategies. The effort to transition existing code to more inclusive language may not only require a full team or studio effort, but also may require more self-awareness and training for developers, in order to ensure future development continues to keep inclusive language as a code standard.
