Inclusive Language

Sentry is a product used and developed by many people from different cultural backgrounds and we try to avoid language that has been identified as hurtful or insensitive. This applies not only to the documentation but also to the product itself and internal APIs.

What constitutes as inclusive language will always be an evolving topic and because Sentry is a product with history it is likely, that we will always carry something in the codebase that is hard to get rid of.

As such this document largely determines what should be done for new code, but not necessarily for existing code.

Phased Out Terms

We have identified some terms that we no longer want to use going forward but that might still exist in parts of the codebase.

master/slave:

Generally, the terms to be used in the context of databases should be "primary"/"secondary" or "primary"/"replica".

whitelist/blacklist:

Generally should not be used. We try to avoid the word "list" now in general and try to be more descriptive in the UI. For instance, the use of "ip blacklist" has been changed to "ip filters" as part of the filter product. If you need a generic term "allowlist" and "denylist" or "blocklist" are good substitutions.

whitelisted/blacklisted:

Try to avoid generic verbs here and better describe directly what it is you're trying to do. For instance, we changed "whitelisted environment variables" to "safe environment variables".

grandfathered:

Try to avoid. If it can be replaced with "legacy" use that term, otherwise if you want to emphasize that functionality is only available because you used to use it in the past, be explicit. Change "available on grandfathered plans" to "available on old plans no longer available for sign-up".

Acceptable Terms

master:

Master in isolation is acceptable if the origin of the term can exclude the associated meaning of "slave". This for instance is the case when this is referred to as a "master copy", a "master degree" etc. For the git branch name please see below.

Git Branch Naming

We are okay keeping the term "master" for existing repositories but it is generally recommended to change the default branch name to "main" going forward on new repositories. The term "master" in isolation is acceptable in general however the history of the branch name in git comes from bitkeeper where this terminology referred to master and slave repositories. At present changing the default branch on existing repositories has negative consequences for users that have already cloned the repositories so these should not be changed.

To reconfigure git to use a different default repo for git init a template can be configured. Put the following into your ~/.gitconfig:

[init]
	templateDir = ~/.config/git/template/

And then create an appropriate template like this:

mkdir -p "$(git config --path --get init.templateDir)"
echo "ref: refs/heads/main" > "$(git config --path --get init.templateDir)/HEAD"

From this moment onwards future repositories will use the default branch name "main" instead.

Changing Code

If you identified code or comments that uses problematic language you are free to change it. However please be advised that some uses of problematic language haven't been phased out because they are backward-incompatible changes and require a lot more work. Specifically, for instance, the rate-limiting code in Sentry uses the terms "whitelist" for persisted data and for consistency the code that deals with this data structure, for now, retains these uses.