Google has adopted a policy to use respectful terminology in our internal code and documentation, and the same should be true of our open source projects. We want our projects and communities to be welcoming to everyone, and part of creating an inclusive environment is being thoughtful in the language we use in our code and documentation.
Please take some time to see if these terms could be replaced with more respectful alternatives e.g.
blacklist, whitelist, graylist, greylist, black list, white list, gray list, grey list
Don't use blacklist, whitelist, and graylist (greylist). Instead, use more precise terms that are appropriate to your domain.
For blacklist, consider such replacements as denylist, excludelist, or blocklist.
For whitelist, consider such replacements as allowlist , trustlist, or safelist.
For graylist (greylist), consider such replacements as provisional list.
In all of these cases, consider that there may not actually be a list involved. When replacing problematic terms, be sure to be technically accurate for the specific context.
If the command or code you're documenting uses one of these words, then use these words only in direct reference to the code items (formatted as code), and make it clear what you're referring to.
master
Use with caution. Never use in conjunction with slave. Where possible, replace master with a specific term that is accurate for the context, such as primary, parent, initiator, driver, or leader. If the command or code that you're documenting uses the literal word master, then introduce the term to make it clear what you're referring to, and then use new term thereafter.
slave
Don't use slave. Use a replacement that best fits your product (for example, replica, secondary, or consumer). To replace master/slave, you can also use terms like parent/child, initiator/responder, leader/follower, primary/replica, or primary/standby.
Google has adopted a policy to use respectful terminology in our internal code and documentation, and the same should be true of our open source projects. We want our projects and communities to be welcoming to everyone, and part of creating an inclusive environment is being thoughtful in the language we use in our code and documentation.
In reviewing github.com/google/earthenterprise we found the following terms that should be avoided:
These were found in the following files:
Please take some time to see if these terms could be replaced with more respectful alternatives e.g.
blacklist, whitelist, graylist, greylist, black list, white list, gray list, grey list
Don't use blacklist, whitelist, and graylist (greylist). Instead, use more precise terms that are appropriate to your domain.
For blacklist, consider such replacements as denylist, excludelist, or blocklist.
For whitelist, consider such replacements as allowlist , trustlist, or safelist.
For graylist (greylist), consider such replacements as provisional list.
In all of these cases, consider that there may not actually be a list involved. When replacing problematic terms, be sure to be technically accurate for the specific context.
If the command or code you're documenting uses one of these words, then use these words only in direct reference to the code items (formatted as code), and make it clear what you're referring to.
master
Use with caution. Never use in conjunction with slave. Where possible, replace master with a specific term that is accurate for the context, such as primary, parent, initiator, driver, or leader. If the command or code that you're documenting uses the literal word master, then introduce the term to make it clear what you're referring to, and then use new term thereafter.
slave
Don't use slave. Use a replacement that best fits your product (for example, replica, secondary, or consumer). To replace master/slave, you can also use terms like parent/child, initiator/responder, leader/follower, primary/replica, or primary/standby.