We choose words that help customers feel safe, supported, and informed about the health of their systems. A commitment to inclusive, bias-free language is an opportunity to extend that care, to be historically minded and compassionate in our word choice. This isn't an exhaustive list of do's and don'ts, but a starting point for content that embraces and empowers all users.
For a deeper dive on specific terms, see this list that Google maintains.
Topic | Recommendations |
---|---|
Addressing ableism biases | Do your research: If you don't already know the preferred way to refer to someone with a specific disability, we recommend a little research. Some communities prefer person-first language (e.g., saying John has a disability rather than John is disabled), while others do not. For example, the deaf and autistic communities prefer to use those terms rather than descriptors: âJohn is deafâ rather than âJohn is a person with deafness.â The take-away here is to treat people with the same level of complexity as you would want to be treated. Avoid language that has derogatory connotations: For example, crazy, cripple, lame, insane, dummy, blind, etc. The list can get very long and many terms are deeply woven into our everyday lexicon. If you aren't sure if a term has derogatory connotations, research it. This list that Google maintains is a good resource as well. |
Addressing gender biases | Use second person: In most cases, directly address the user as âyou.â This is part of our voice, is more engaging for users, and avoids confusion about who is supposed to do what. Use âtheyâ for a hypothetical singular person. And use plural verb tense to go with it. For example, âProvide a place for your user to save their New Relic license key.â Do not use a hypothetical âhe,â âshe,â âhe/she,â or âhe or she.â Or, make the hypothetical subject plural: âProvide a place for your users to save their New Relic license keys.â Use non-gendered pronouns unless referring to a specific person who has disclosed their pronouns: Bill Staples brings his passion for developers, technology and innovation to his role at New Relic. When writing about real people, always respect their pronouns and names. Avoid asking for gender in surveys unless it's required. If you must request gender:
|
Addressing military terms | Give thought to the military and battle terms that slip into your content. Would your writing be better served with more specific language? Terms like deploy (as in code) or execute are so ubiquitous in tech that the connection to the military has long been diluted. But terms still carry power, and can create an unnecessarily combative tone. For example, our marketing team recently replaced an instance of âblast radiusâ with âsplash zoneâ â it carries the same meaning, but with a more fun connotation. |
Addressing racial bias | Use title-style capitalization for Asian, Black and African American, Hispanic and Latinx, Native American, Alaska Native, Native Hawaiian, Pacific Islander, and Indigenous Peoples. Following Microsoft style, lowercase multiracial and white. Never use: master/slave unless you must refer to a third-party software use of these terms. Consider adding a note or callout if you must use master/slave for third-party software. Say something like, âthese terms are used by [NAME OF TECHNOLOGY] and do not align with New Relic guidelines.â Avoid âmasterâ whenever possible, for example, do not use master branch, master data, scrum master, entity master, master data management, etc. Some substitutions: main branch, scrum manager, agile coach. Do not use âblackâ to equate with âbadâ and âwhiteâ to equate with âgood.â For example, instead of âblack listâ or âwhite list,â use âblock listâ and âallow list.â Instead of âwhite-hat hackerâ or âblack hat hackerâ use âethical hackerâ and âunethical hackerâ or âmalicious hacker.â Avoid terms that may carry unconscious racial or cultural bias, even if you're making positive statements. For example, avoid terms like offshore, tribal knowledge, grandfathered. |
Addressing technical bias | Avoid assumptions around technical competence. For example, don't say, âGitHub is too complicated for non-coders.â Or, âThis feature is so easy, even your grandmother can use it.â Or, âExplain this feature like you're explaining it to your mom.â |