Inclusive Chromium code
Why this is important
Our Code of Conduct under «Be respectful and
constructive» says:
Each of us has the right to enjoy our experience and participate without
fear of harassment, discrimination, or condescension, whether blatant
or subtle.
Emphasis is added: unnecessarily exclusive code is discriminatory and
condescending, and reading biased code isn’t enjoyable.
Gender-Neutral
Some points in our code, documentation and comments contain needless assumptions
about the gender of a future reader, user, etc. Example: «When the user logs
into his profile.»
Suggestions on how to keep code gender-neutral
These are only suggestions. You make the call.
Things to avoid:
- Gendered pronouns: he / she / him / her / his / hers, etc.
- Instances of the phrases «he or she», «his/hers», «(s)he», etc. All of these
still exclude those who don’t identify with either gender, and implicitly
(slightly) favor one gender via listing it first.
- «Guys» as a gender-neutral term, which has male associations. Usually in
comments it implies anthropomorphism of inanimate objects and should be
replaced with a more precise technical term. If it does refer to people,
consider using «everyone», «folks», «people», «peeps», «y’all», etc.
- Other gendered words: «brother», «mother», «man», etc.
Cases that are likely fine to leave alone include:
- References to a specific person («Rachel is on leave; update this when she is
back.«).
- A name («Guy» and «He» are both valid names).
- A language code («he» is the ISO 639-1 language code for Hebrew).
- He as an abbreviation for «helium».
- The Spanish word «he».
- References to a specific fictional person (Alice, Bob, …).
- For new code/comments, consider using just ‘A’, ‘B’ as names.
- Quotations and content of things like public-domain books.
- Partner agreements and legal documents we can no longer edit.
- Occurrences in randomly generated strings or base-64 encodings.
- Content in a language other than English unless you are fluent in that
language.
How to change the remaining awkward intrusions of gender:
- Try rewording things to not involve a pronoun at all. In many cases this makes
the documentation clearer. Example: «I tell him when I am all done.» → «I tell
the owner when I am all done.» This saves the reader a tiny bit of mental
pointer-dereferencing.
- Try using singular they.
- Try making hypothetical people plural. «When the user is done he’ll
probably…»
→ «When users complete this step, they probably…».
- When referring to a non-person, «it» or «one» may be good alternatives (wikipedia link).
Example changelists
For a long list of changes, see this bug. Some
examples:
Tools
- Here
is a code search link prepopulated with a search that finds a lot of gendered
terms.
To search for files containing gendered terms, use this command (or a variant
of it):
git grep -wiEIl \ '(he)|(she)|(his)|(hers)|(him)|(her)|(guy)|(guys)'
To search in a file open in vim for gendered terms, use this command:
/\<he\>\|\<she\>\|\<his\>\|\<hers\>\|\<him\>\|\<her\>\|\<guy\>\|\<guys\>|\<man\>\c
There are presubmit checks available for this that are run for the infra and
v8 repos. They are not run for other repos as there are too many false
positives.
Racially neutral
Terms such as «blacklist» and «whitelist» reinforce the notion that black==bad
and white==good. That Word Black, by Langston
Hughes
illustrates this problem in a lighthearted, if somewhat pointed way.
These terms can usually be replaced by «blocklist» and «allowlist» without
changing their meanings, but particular instances may need other replacements.
Example changelists
For a long list of changes, see this bug. Some
examples:
Thanks
This document is based on an internal Google document by Rachel Grey and others,
which can be found here (sorry,
Googlers only).