How enterprises are building inclusive language in code
Inclusive language in code is just one step towards a diverse community, but it's a good place to start. It's a conversation more and more open source enterprises are tackling.
As culture changes, companies need to update the language they use to be as inclusive as possible. But it can be a complicated process to get everyone on board with inclusive language in code. And if you're dealing with insensitive function names or API calls, it gets more complicated.
In late 2020, Red Hat, Akamai, Cisco, the Cloud Native Computing Foundation (CNCF), the Linux Foundation and others joined forces to form the Inclusive Naming Initiative. The group's goal is to assist developers in the removal of discriminatory language from projects and documentation.
Celeste Horgan, co-founder of the initiative and senior technical writer at CNCF, said she and her colleagues sought to provide a solid framework for evaluating language and recommending changes.
The Inclusive Naming Initiative identified three categories of what it considers harmful language:
- language that is directly harmful to individuals or identifiable groups of people;
- language that isn't directed at an individual but is harmful in a broader context; and
- language that is unclear.
The first two categories are the industry's biggest concerns, Horgan said, since they address terms such as "master/slave."
Changing non-inclusive terms not only promotes inclusion, but makes software easier to comprehend, she said.
"Non-inclusive language is often laden with metaphor and culturally specific ideas," she said. "Removing them can aid in understanding by people outside your cultural context, like teammates on different continents."
Inclusive language in code at Red Hat
Open source products developer Red Hat is in the process of trying to incorporate inclusive language into code. Red Hat is reexamining the words master, slave, whitelist and blacklist, said Rich Bowen, a principal program manager at Red Hat. While other problematic language exists within coding, these words are important starting points.
"Once the conversation has started and people begin to understand that this is about compassion, not policing language, communities tend to be proactive in finding other instances where the language that they use causes parts of our communities to feel unwelcome," Bowen said.
He added that terms like sanity check and lame also warrant review, as do racist and sexist references in code, comments and documentation.
That said, the name-changing process must be carefully thought out, Bowen said. Modifying a word that appears in documentation is relatively easy, but function names and API calls require deprecation cycles.
"It's important to evaluate the potential impact of changes, as well as just counting words, and then approach that in a way that is methodical, with a focus on not breaking your user's infrastructures," he said.
Again, it comes down to having a conversation.
"This whole process is about compassion and understanding, so it makes sense that it starts with talking, and understanding one another, rather than just with the technical implementation," he said.
Rich BowenPrincipal program manager, Red Hat
Of course, discussions don't always produce unanimous agreement. Some may view this process as an exercise in political correctness, or worse, as language policing, oppression and even Orwellian Newspeak, Bowen said. People can become defensive when they perceive that a rule is being forced upon them.
Oftentimes, this pushback comes from those who have never been victims of discrimination and therefore believe that their organizations are attempting to solve a problem that doesn't exist. And then there are those who declare that simply changing language won't solve the larger problems of racism and discrimination.
Relationships and credibility are key elements of successful open source projects. Swooping in with high demands isn't a wise approach.
"The biggest mistake that we've seen made is to arrive unannounced at an open source project with a massive patch and demand that it be accepted," Bowen said.
Once again, Bowen emphasized the importance of starting with a conversation -- one that covers what changes should be made and why -- before dropping the patch.
Word replacement list
On its website, the Inclusive Naming Initiative suggests organizations specifically evaluate and replace these terms.
- Control plane/control plane node
- control plane
Ways to work toward new language
To address discriminatory and offensive language in documentation, organizations should first construct a style guide, said Uwana Ikaiddi, manager of developer documentation at BigCommerce, an open SaaS developer for the retail market.
At BigCommerce, this guide is followed by the technical writers who report to her, but it also includes input from the company's marketing department, its external-facing community channels (Twitter, Facebook and the BigCommerce internal community forum) as well as its UI and UX teams. If the end result is to be successful, collaboration is necessary.
"Make sure that you're getting insight [from these different groups], because they're going to bring insight that you haven't even been thinking about, because the audience they're talking to is different from your own audience," Ikaiddi said.
In addition to this style guide, Ikaiddi's team built a linter to identify of potentially problematic language.
For Bowen, projects that welcome diversity of opinion, experience, personality and individuals in general stand to be more successful -- and likely more innovative.
"If you look around your team or your project and everyone looks like you, then you're denying yourself a whole range of ideas," he said. "Intentional language choices are, of course, just one small aspect of welcoming a diverse community. But they're a relatively easy place to start the conversation and often lead to more initiatives, specifically because you've made more people feel welcome and included."