Inclusive Language Updates

Inclusive Language Overview

The Sustaining Engineering team at Remind recently implemented changes that focus on using inclusive language within our codebases. We encourage other engineering teams to do the same, and hope these updates create a more inclusive space for everyone at Remind. Terms like master and slave have no place in a modern codebase. They don’t belong inside of our repositories, and they certainly do not belong on a repository’s default branch on GitHub.

At Remind, we have 59 distinct services that power our application. Each of these services has language that needs to be updated thoughtfully and intentionally to ensure that our systems remain available to the parents, teachers, and students that depend on them. We followed the lead of Indeed’s VP of Engineering Jack Humphrey to identify and replace problematic language with the help of this blog post. We also had a number of internal conversations between team members that helped us iterate on the language that we intended to change, which worked specifically for our teams at Remind. Hopefully, outlining the changes that we made can serve to help other organizations working to make their workplaces more inclusive.

Actions We’re Taking

We’ve committed ourselves to the following updates:

• Github default branch
  • master » main
• Database Terminology
  • Master/Slave -> Writer/Reader
• Permission Lists
  • Whitelist/Blacklist -> Allowlist/Blocklist

I began our updates within three of the services that my team – Sustaining Engineering – owns and operates within regularly. The steps that I took to update each of these repositories are as follows:

1. Checked the repo for hard coded references to master branch and changed to main locally
2. Checked across all repos at Remind for hard coded references to the master branch of the repo I was currently working to update
3. Checked the repo for master and slave terminology, generally related to databases and updated with writer and reader
   • This was updated from source and replica to be more consistent with our infrastructure configurations and dashboards
4. Checked the repo for exclusive terms like whitelist and blacklist and updated these terms to allowlist and blocklist
5. Ensured our SREs were involved in the review and implementation process to help address potential issues
6. Got an approval on my PR by a senior member of the engineering team
7. Tested the changes on staging if there was a staging environment for that application
8. Changed the default branch from master to main on GitHub
9. Merged the PR and deployed the updated version of the app
10. Did a quick QA check on the application to ensure that the software was still working as expected
11. Posted an update to notify the stakeholders of the changes

The evolution of inclusive language within our codebases requires the domain knowledge of many members of the engineering team. The process is filled with complexities, dependencies, build updates, deployment decisions, and unknowns. Nevertheless, it’s important we continue to take action and make these updates.

This process of using intentionally inclusive language is intended to be fluid and ongoing. As we continue to learn from our employees with varying lived-experiences, we will continue to make updates that strive towards psychological safety and inclusive language throughout the organization.