Inclusion and Diversity in Writing and Oral Presentation

ACM Symposium on Cloud Computing (SoCC) brings a large scientific and technical community together and thus has a direct impact on many people from different backgrounds around the world. The goals of Diversity and Inclusion are explained by ACM as follows. Diversity is achieved when the individuals around the table are drawn from a variety of backgrounds and experience, leading to a breadth of viewpoints, reasoning, and approaches (also referred to as "the who"). Inclusion is achieved when the environment is characterized by behaviors that welcome and embrace diversity ("the how"). Both are important in our writing and other forms of communication such as posters and talks. Here we describe and point to ways to ensure SoCC’23 is diverse and inclusive in creating a welcoming environment for everyone attending the conference.


Be mindful of not using language or examples that further the marginalization, stereotyping, or erasure of any group of people, especially historically marginalized and/or under-represented groups (URGs) in computing. Of course, exclusionary or indifferent treatment can arise unintentionally. Be vigilant and actively guard against such issues in your writing. Reviewers will also be empowered to monitor and demand changes if such issues arise in your submissions.

Examples of exclusionary and other non-inclusive writing to avoid:

  • Implicit assumption: An example of database integrity constraints: "Every person has a mother and a father." This example is exclusionary and potentially hurtful to people from single-parent households and people with same-sex parents.

  • Oppressive terminology: Using the term "Master-Slave" to describe a distributed data system architecture. This can be hurtful to people whose families have suffered the inhumanity of enslavement. A good source of alternative terms to oppressive language often used in computer science can be found in this article. ACM also has enlisted terms that should be avoided in professional writing and presentations, and suggests alternatives to those terms here.

  • Marginalization of URGs: An example of attribute domains: "The Gender attribute is either Male or Female." This example is exclusionary and potentially hurtful to people who are intersex, transgender, third gender, two-spirit, agender, or have other non-binary gender identities.

  • Lack of accessibility: Using color alone to convey information in a plot when good alternative data visualization schemes exist. This can be exclusionary to people who are color-blind. Please consider using patterns, symbols and textures to emphasize and contrast visual elements in graphs and figures, rather than using colors alone. Use a color-blind friendly palette that is designed with accessibility for visually impaired people. Avoid bad color combinations such as green/red or blue/purple.

  • Stereotyping: Reinforcing gender stereotypes in names or examples of roles, e.g., using only feminine names or presentations for personal secretary or assistant roles.


Going further, please also consider actively raising the representation of URGs in your writing. Diversity of representation helps create an environment and community culture that could ultimately make our field more welcoming and attractive to people from URGs. This is a small but crucial step you can take towards celebrating and improving our community’s diversity.

Examples of infusing diversity into writing to consider adopting:

  • Embracing different cultures: Names of people are a visible way to enhance diversity of representation in writing. Instead of reusing overused names in computing such as Alice and Bob, consider using names from a variety of languages, cultures, and nationalities, e.g., Alvarez and Bano. Avail of the many online resources on this front for ideas, e.g., this article on names across different cultures.

  • Embracing differences in figures: Depictions of people or people-like icons in illustrations are also a good avenue to enhance diversity of representation. Consider depicting people of different gender presentations, skin colors, ability status, and other visible attributes of people.

  • Embracing gender diversity in pronouns: Consider using a variety of gender pronouns across your named examples consciously, including "he/him/his," "she/her/hers," and "they/them/theirs". Likewise, consider using gender-neutral nouns when referring to generic roles, e.g., "chairperson" or just "chair" instead of "chairman," and gender-neutral pronouns for such roles.


Finally, if your work involves data-driven techniques that make decisions about people, please consider explicitly discussing whether it may lead to disparate impact on different groups, especially URGs. Consider discussing the ethical and societal implications. For example, see this article discussing the potential for disparate impact of facial recognition in healthcare and strategies to avoid or reduce harm. This SIGMOD Blog article also gives a comprehensive overview of various dimensions and approaches for responsible application of data management ideas. We hope our community can help permeate this culture of responsibility and awareness about potentially harmful unintended negative consequences of our work within the larger computing landscape.

Further Reading

  • ACM Diversity and Inclusion: webpage
  • ACM SIGMOD Blog article on "Data, Responsibly": webpage
  • AMA Journal of Ethics article on "What Are Important Ethical Implications of Using Facial Recognition Technology in Health Care?": webpage
  • Article on "Inclusive CS Examples": webpage
  • Article on "Terminology, Power and Oppressive Language": webpage
  • Helpful materials from UCSD CSE Diversity, Equity, and Inclusion Committee: webpage
  • NeurIPS CFP on Broader Impact Statement: webpage
  • Wikipedia listing of names across cultures: webpage

Creating Inclusive Talks and Videos

This article explains some additional tips on inclusive practices when creating slide content for talks, as well as during speaking and recording videos.

Slide content

It helps improve readability if your font sizes are not too small and if you avoid packing too much content onto one slide. If possible, avoid embedding text into images if similarly effective alternatives exist for rendering your content. Images in slides are usually unreadable for screen readers, which are often used by people with visual impairments.

During speaking/recording videos

It helps improve legibility if you pause for a moment in between sections and also during slide transitions. If possible, avoid speaking too fast, since that can make comprehension harder for many non-native English speakers, as well as people with hearing impairments. If you plan to record your face while speaking, look directly at the camera while speaking so that lipreading is more feasible for people with hearing impairments.

Transcripts and captioning

Captions are widely known to be helpful in enabling better comprehension for people with auditory impairments and non-native English speakers (link). Captions also help many people who find different accents more difficult to comprehend. To improve accessibility of the talks, we plan to invite all authors who record their talk videos to contribute plaintext transcripts of their talk and also embed time-aligned captions/subtitles in their videos.

To create a plaintext transcript, you could write down what you speak ab initio. Alternatively, you could use a (free) automatic speech recognition (ASR) service to convert your recorded audio to an intermediate text file that you can then edit to correct ASR errors.

To create closed captioning for video, here is a suggested and hopefully easy-to-execute workflow based on Youtube's capabilities (link):

  • Record your video as usual, say, with Zoom. Obtain an MP4 file.
  • Use Youtube (or a similar service, e.g., to upload the video and obtain its closed captions as a timestamped transcript file in SRT file format (link).
  • Edit the SRT file to correct ASR errors and re-upload to the video. This allows viewers to retain the option of removing captions if they do not want to see them.
  • If you prefer to embed time-aligned captions into the video file itself, use the open source tool HandBrake to do so (link). This will create a self-contained MP4 file without the need for a separate SRT file.


This document is based on the D&I resources found here. We thank the “D&I in DB” group for sharing these resources.