HashiCorp’s mission statement for diversity and inclusion guides us to foster an inclusive culture where employees are inspired to do their best work and be an organization where we embrace differences to drive innovation and integrate inclusive practices into every aspect of the business to achieve our goals. As we reflect on systemic injustice and racism, we’ve been reviewing areas that we can improve. One area that has emerged is inclusive language. We found several examples where HashiCorp projects or documentation have used language that implies connotations counter to our principles. To quote from the section on kindness, “Long after we forget the details of an interaction, we remember how we felt.” In doing our bit to make a difference, we are identifying language that evokes unintended associations and replacing it with inclusive language.
Why are we making this change?
Inclusive language aims to create a welcoming environment for all by avoiding words that express or imply ideas that are biased or prejudiced to large groups of people. We believe changing the specific language we use to be more inclusive is the right thing to do, aligning with our principles of integrity and kindness. While we know that this is in no way a “cure all” for the social challenges we face in our world today, these changes represent a small, but positive and meaningful improvement.
What specifically is changing?
The following changes are what we have identified so far across our projects and products
- blacklist/whitelist will change to allowlist/denylist
- GitHub repository default branch name will change from “Master” to “main”
- “master” terminology used in HashiCorp Consul and Vault will be replaced
We are continuing to uncover other areas where our products and associated materials may contain non-inclusive language. In addition, we are putting best practices in place such that we don’t inadvertently use language or terminology that perpetuates this issue.
Commitment to our community
We will ensure that there is backwards-compatibility, detailed upgrade guides, and sufficient resourcing for changes that might alter existing workflows. Any changes to the CLI/API that are being phased out will come with a warning around the change and offer time to adjust your workflows to accommodate new naming conventions, commands, or other updates. We will also ensure the documentation details the changes and notifications will go out as appropriate.
Our teams will be rolling these changes out incrementally. With this post, we are communicating our intent and providing insight on our approach. We will communicate specific changes with the diligence described in our commitment to our community.