Inclusivity is central to Fuchsia's culture, and our values include treating each other with dignity. As such, it’s important that everyone can contribute without facing the harmful effects of bias and discrimination. However, terms in our codebase, UIs, and documentation can perpetuate that discrimination. This document sets forth guidance which aims to address disrespectful terminology in code and documentation.
Terminology that is derogatory, hurtful, or perpetuates discrimination, either directly or indirectly, should be avoided.
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 email@example.com.
These lists are NOT meant to be comprehensive. They contain a few examples that people have run into frequently.
|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|
|crazy||unexpected, catastrophic, incoherent|
|redline||priority line, limit, soft limit|
Prefer 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.
This circumstance has come up a few times, particularly for code implementing specifications. In these circumstances, differing from the language in the specification may interfere with the ability to understand the implementation. For these circumstances, we suggest one of the following, in order of decreasing preference: