Words have power

Thanks to the incredible conversations the United States and World are having right now about race and inclusion, it has come to our attention, as software developers, that some of the phrases we use are based on historically racist or classist terms and that our continued use of these terms is insensitive, unwelcoming, and exclusionary.

While insignificant in the giant list of things that need to be changed to bring about true equality and inclusiveness, we at Matador Jobs nevertheless feel we can begin to impact change by stopping our perpetuation of these negative language constructs in our software.

Our changes to exclusionary terms

Based on useful and interesting discussions with other developers around exclusionary language, we found that the items below are the biggest targets for adjustment. In many cases, these changes that can be made are actually more descriptive! Here are the key adjustments we are making in our upcoming releases:

  • Changing whitelist/blacklist to “allow list”/”deny list” to explain lists of explicitly allowed or disallowed items
  • Replacing master and master/slave to main and primary/secondary to explain relationships where one is an authority or primary source to a backup or secondary source.
  • Removing the use of “grandfather”/”grandfathered” to describe backwards compatibility or rights or access given automatically to a legacy user of a feature.
  • Instead of “whitespace” use “empty space”, “blank space”, or a more descriptive term to describe areas that are purposely empty, blank, or clear for readability or design, ie: a “line break” could describe space purposely used to improve readability of code or text.

First Up: “Whitelist”

Overall, to implement this effort, we have a relatively small to-do list, with a majority of the changes deep in the code where almost all of our users will never see it. There is one exception however, and it is all over our Bullhorn Connection Assistant wizard: the prevalence of the term “whitelist.”

In the case removing of this use of “whitelist,” we needed to first engage our partners at Bullhorn, as our use of the term was derived directly from their official API implementation documentation. Since we generate form emails in the Connection Assistant our users are encouraged to copy-and-paste and send to Bullhorn support, we needed to make sure that if we used alternate, inclusive language that it wouldn’t cause confusion when the email arrived at Bullhorn.

After very positive discussions with Bullhorn Support, they expressed full support of our removal of the term as they are undergoing a similar initiative to update documentation. We thank them for that incredible support!

On our next hotfix release 3.6.2 due out this week, we will replace the term whitelist in our Connection Assistant tool. Users will see the following impacts:

  • “Whitelist” or “Whitelisted” (used as a verb) will become “Register” or “Registered”
  • “[API Redirect] Whitelist” (used as a noun) will become “Allowed API Redirect List”

More on this Topic

As we do what we can to improve our code to root out insensitive language, we found the following resources helpful: