In the summer of 2020, a cross-team, cross-division group of volunteers in the Office of Information Technology at the University of California, Irvine, came together to create an inclusive IT language guide.
Language is the core of communication. Since we want our higher education institutions, programs, and organizations to be inclusive and welcoming for everyone, we should integrate inclusive language at every opportunity. The information technology field, like any other domain of expertise, carries its own linguistic patterns and lexicons of use, built up over decades and layered with meanings. Inevitably, some terms convey or propagate outdated meanings or cultural assumptions. In pursuit of being welcoming to everyone, those of us working in information technology should revise our language moving forward.
At the University of California, Irvine, inclusive language was raised as a topic within the Architecture Review Board of the Office of Information Technology. Composed of senior technical contributors and managers, this board is charged with setting and reviewing IT standards and policies within the operations of the Office of Information Technology; by necessity, these standards impact the campus as a whole. In the summer of 2020, when a technical contributor to the board suggested that we write up some best practices, inclusive language was a rising tide throughout technology: large vendors had revised their developer style guides; framework leaders had revised their own terms and language; project members were rebasing trees with new names. Many board members shared recent experiences of making language changes to be more inclusive and of conducting team discussions on terminology choice. We quickly assembled volunteers for a cross-team, cross-division subgroup of the Architecture Review Board to come together and build a draft.
Our subgroup focused on making a document that is appealing to adopters; we wanted to emphasize thought and actionable recommendations. The draft began as a list of replacement terms, but we found this structure restrictive. Rather, we wanted the document to draw the reader through the reason behind each change, illustrating how inclusion informs decisions and fosters consideration of both technologies and audiences. We sorted the replacement terms into like groups and wrote accompanying topics discussing themes of inclusiveness. Within this structure, the terms serve as examples of the larger ideas; each term contributes to a broader understanding of inclusivity and serves the many axes of inclusion in our many-flavored world.
Anticipating that this exercise might attract attention, we sought feedback from campus groups with intersecting domains. The Office of Inclusive Excellence eagerly supported the effort and connected us to additional groups. The experience and expertise of these groups greatly helped our work: the Disability Services group taught us about person-first versus disability-first language; and the LGBTQ Resource Center highlighted and expanded our section on pronouns. Their support and contributions significantly improved the final product.
An unexpected surprise for us was that substitutes for legacy terms were often better technical terms. For example, legacy terms such as blacklist and whitelist rely on metaphors carrying their own cultural histories and biases. Conversely, their replacement terms—deny list and allow list—are rooted in verbs. These verbs directly reflect the desired technical behavior. Much as accessibility features make better products for everyone, inclusive terms deliver a more precise technical result.
The real test came with our initial publication. We positioned our document as a "guide" and always will consider it a work-in-progress. We were heartened that the guide was positively received. Many brought questions about terms that we had not considered, and others sought guidance for broader areas of inclusive language, including some areas that exposed thorny societal issues.
Inclusivity is a never-ending goal, changing language is an ongoing process, and some changes are more difficult than others. The process begins with asking the question: How can we do or be better?
See University of California, Irvine, Inclusive IT Language Guide, version 1.0 (April 2021).
Andrew Laurence is Systems Analyst at the University of California, Irvine.
Seth Roby is Senior Software Engineer at the University of California, Irvine.
Rachel Tam is Assistant Director, Enterprise Student Management Systems, at the University of California, Irvine.
© 2021 Andrew Laurence, Seth Roby, and Rachel Tam. The text of this work is licensed under a Creative Commons BY-NC 4.0 International License.