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.” |