1. Home
  2.  → 
  3. About OIT
  4.  → 
  5. Inclusive IT Language Guide
  6.  → Inclusive IT Language Guide

Inclusive IT Language Guide

Version 1.0 | April 2021

UCI is committed to equity, diversity, and inclusion. Language used by the Office of Information Technology (OIT) must reflect these values.

Scope

This document is an Architecture Review Board (ARB) Standard to be followed by all OIT staff. OIT encourages everyone at UCI to be mindful of these issues and participate in making these decisions with respect and a broad viewpoint.

This document should guide your terminology choices in your documentation, codebase, and discussions. Where you control the choice of words, you should choose wisely. We encourage you to use terminology from this guide in areas you can but understand there may be times when words from outside systems, legacy technology, or existing standards constrain your options. In those cases, consider inclusive alternatives, such as providing a mapping from old to new terminology, with source attribution when necessary.

Principles

Favor gender-neutral terms whenever possible. Avoid constructions like “he or she”, “he/she” and “s/he”; singular “they” has been in use for centuries.

Use thisNot this
they, themhe, she
theirhis, her
folks, team, y’allguys, gals
chair, moderator, chairpersonchairman
humanity, people, humankindman, mankind
other UC campussister school, sister campus
legacy status, preexistinggrandfathered
counterpart, indispensableright-hand man
person hours or engineer hours or level of effort (hours)man hours, manpower
attacker-in-the-middleman-in-the-middle

When writing about a specific, real-world person, use the pronouns that person prefers. If possible, ask them which pronouns to use. Consider adding your preferred pronouns to your email signature or screen name to make this task easier on others.

Use inclusive names in examples. For people, pick names with origins in multiple cultures.

Don’t make generalizations about people, countries, regions, and cultures. Even if your intent is to cast them in a positive light.

Be mindful of the layers of meaning behind your word choices. The history of a term matters, but connotations gained since the coining of a term matter, too.

Use thisNot this
allowlist, safelistwhitelist
denylist, blocklistblacklist
glass box testing, clear box testingwhite box
functional testing, acceptance testingblack box
built-in featurenative feature
core concept, top-levelfirst-class citizen
maintenance, upkeephousekeeping tasks

Favor direct descriptions of the actions taken and roles played. Avoid metaphors, which can introduce unneeded baggage. Prefer verbs to nouns.

Use thisNot this
primary/replica, primary/standby, primary/secondarymaster/slave
main branchmaster branch
against the grain, counterproductiveoff the reservation

Focus on people and not disabilities or circumstances. Prefer “people-first language,” such as “people with disabilities” or “people experiencing homelessness.” Research the community you’re discussing, as there are exceptions: some individuals in the blind, deaf, and autistic communities prefer disability-first language. When referencing users with disabilities, avoid the use of “impairment”. The term Deaf with a capital D refers to people who identify as culturally Deaf– sharing a common culture and a signed language– while deaf with a lowercase d refers to a person who has the condition of hearing loss who does not necessarily identify with the culture.

Use thisNot this
screen reader/magnifier useruser with a visual impairment
D/deaf or hard of hearinghearing impaired

Avoid ableist language. It is easy to fall back on problematic idioms, especially when trying to be conversational. These terms can go unnoticed; make an effort to notice them.

Use thisNot this
smoke test, quick check, confidence check, coherence checksanity check
placeholder value or sample valuedummy value
hindercripple
ignoreblind to, deaf to
inconsiderate, thoughtless, carelesstone deaf

Avoid slang and idioms that can confuse or detract from your message. Do not rely on implicit contextual understandings that may not be shared by your audience, as they may be separated by time, distance, and culture.

Avoid violent language, as it will distract from your meaning.

Use thisNot this
perimeter networkdemilitarized zone (DMZ)
stop respondinghang
halt, stopkill (a process)
feed two birds with one sconekill two birds with one stone
deletenuke

Don’t use derogatory terms. There is no need.

Timeline

Wherever possible, start using better terms immediately. Set aside time in your schedule to make the changes where effort is required. Be forgiving to others as we all work to break old habits and form new ones.

If changes are to be postponed, work with your supervisors to set a reasonable deadline for making the change. Consider setting up a system with aliases or subclasses that allow new code to use better terminology. Add comments or other documentation to explain that you are aware the term is outmoded and that changes will be made when possible. For example:

/*
TODO The terminology used in this file will be replaced with “Primary” and “Secondary” within the year. The wording here reflects the underlying ISO standard.
*/

If your internal naming convention has to convert to an external naming convention that would run afoul of this standard, include a comment to note the limitation. For example:

/*
This terminology is part of the underlying ISO standard; we cannot update it at this time.
*/

References

This guide is heavily indebted to the following material found online, and compiles many of the same ideas and contextualizes them for our purposes.

In addition, many of our counterparts in the technology community are making similar changes:

Updated on
April 5, 2023