Inclusivity is central to Fuchsia's culture, and our values include treating each other with respect and dignity. Everyone should be able to contribute to Fuchsia without facing the harmful effects of bias and discrimination. This respectful code policy provides guidance to address language that can perpetuate discrimination or harm in the codebase, UIs, and documentation.
Terminology that is derogatory, hurtful, or perpetuates discrimination, either directly or indirectly, should be avoided and will be replaced.
Anything that a contributor would read while working on Fuchsia, including:
Apply the principles above. If you have any questions, you can reach out to fuchsia-community-managers@google.com.
These lists are NOT meant to be comprehensive. They contain common examples found in documentation. If you see disrespectful language, report it.
Specific terms
Term | Suggested alternatives |
---|---|
master | primary, controller, leader, host |
slave | replica, subordinate, secondary, follower, device, peripheral |
whitelist | allowlist, exception list, inclusion list |
blacklist | denylist, blocklist, exclusion list |
insane | unexpected, catastrophic, incoherent |
sane | expected, appropriate, sensible, valid |
sanity check | check |
crazy | unexpected, catastrophic, incoherent |
redline | priority line, limit, soft limit |
white glove | top tier service; meticulous, thorough support |
blackout | blocked out |
build cop | build gardener |
dummy | placeholder |
Idioms
Use descriptive and factual statements instead of idioms. Idioms can suffer from the same problems described above, and also they can be difficult to understand for people with a different cultural context than you.
When implementing code, differing from the language in the specification may interfere with the ability to understand the implementation. In these circumstances, we suggest one of the following, in order of decreasing preference: