Words matter: Examining our language to foster empathy and inclusion at work | Elastic Blog
Culture

Words matter: Examining our language to foster empathy and inclusion at work

We’re determined to improve the language we use both within our products and documentation, and throughout the development process itself. This is a necessary step to remain committed to our Source Code, where we place a high value on inclusive practices.

For us, inclusion means that we aim to speak to and engage everyone with our content. Words have a context and a history. To be truly inclusive, we must make a sincere effort to understand how our words might unintentionally reinforce systems of bias or otherwise affect those around us. It’s important for us to recognize that some of the terminology embedded in our products and our work environment is problematic so we can take steps to improve.

As our Source Code says: “We all come in different shapes with different interests and skills. We all have an accent. Celebrate it.” To truly honor the differences in our community and celebrate the things that make each Elastician unique, we’ve fostered conversations where Black Elasticians can share their experiences and have listened to the stories of Elasticians who are championing accessibility. These conversations have made it mandatory that we reflect on the language we use and ask ourselves: How can we create a more inclusive environment at Elastic through language?

To this end, we’ve identified a few areas where we’re committed to improve.

First, we’ll be changing the default branch in our Git repositories in GitHub from “master” to “main.”

Second, we are working on revising the role names for Elasticsearch nodes to move away from “master nodes,” and toward more inclusive and more technically accurate terminology.

Finally, we’ll be identifying terminology across our documentation and products — and even everyday expressions that we might use on Slack or GitHub — that can be made more inclusive, and we’ll take action to use more inclusive alternatives. For example, instead of a term like sanity check, we'll use final check or simply check.

We know there’s a lot of work ahead of us. We have a lot of infrastructure that expects a “master” branch, or a “master” node, and we’ll need to make changes right across the component products of the Elastic Stack. The changes are coming, however, and where possible there will be issues in our repositories that you can follow.

This isn’t the end of the story but rather the continuation of a conversation, both within Elastic and with our community as a whole. We will never stop looking at ourselves and asking how we can do better and make Elastic and our products more inclusive.

Be kind to each other, and choose your words carefully. They matter.