What is an Inclusive Minute

Briefly (more details later), inclusive practices are about making that extra effort to ensure everyone who wants to participate, can. Large, commercial organizations whose business depends on reach and growth (e.g. Google, Microsoft, IBM and NVIDIA) are fully committed to inclusive practices.

An inclusive minute (or inclusive moment or IM) is an inclusivity practice designed for teams to easily add to existing meeting agendas. The practice is intentionally kept small and informal to help minimize the potential for controversy as well as maximize the likelihood of uptake and adoption. The purpose is to raise awareness, inspire dialog and deeper thinking, and/or inform future action. Although rather modest in its aims, highlighting inclusivity regularly will sow seeds that can grow into larger cultural change.

While a minute is never enough time, we aim to characterize a practice other teams can easily follow and adopt into their existing agendas. While we are all impacted by inclusion issues, sometimes in deeply personal ways, we aim for a focus that relates primarily to a team’s existing work activities. While progress on inclusion is urgently needed, our modest aim here is simply to raise awareness and inspire further/deeper thought.

During regular meetings, a small portion (typically just a few minutes) of the agenda is set aside for a team member to share a factoid, event, resource, or experience at the nexus of inclusion and X. What is X?

  • If your team develops HPC software, X is HPC software development.
  • If your team develops online training content, X is online training content development.
  • If your team is an astrophysics team, X is astrophysics.

X is whatever topic your team comes together regularly to meet about. Whatever X is, it is likely there is no shortage of interesting content involving inclusion and X or inclusion and things with which X is closely associated. Keeping topics focused on the nexus of inclusion and X maximizes the relevance of the activity.

On the IDEAS-ECP team, we have found no end of interesting topics. We have shared inclusive minutes about:

Example inclusive minutes

Let’s suppose your team is an HPC/CSE software development team. In your case X is HPC/CSE software development. Examples of inclusive minute topics that are, by the terms offered here, within scope include…

  • A short description of the book Black Software and key take-aways you learned from reading it.
  • A reminder that color choices in UI design impact color-blind users.
  • Relaying a recent conversation with a colleague that feels Fortran programmers aren’t sufficiently supported in HPC/CSE.

Examples of inclusive minute topics that are, by the terms offered here, out of scope include…

  • Sharing a recent personal negative interaction with a security official at the airport.
    • Is it appropriate length? Probably. It certainly would not take more than a minute or two to share this experience.
    • Is it closely related to X? Unless X indeed involves airport security, it probably is not.
  • Playing the YouTube video Equality, Diversity and Inclusion
    • Is it appropriate length? No. Its 6 minutes. 2-3 minutes might work but 6 is a bit too long.
    • Is it closely related to X? Probably not. It is more of a general resource regarding inclusion and does not seem to tie inclusion into any specific X.
  • Going page-by-page through a resource such as Microsoft’s Inclusive Design for Cognition Guidebook.
    • Is it appropriate length? The resource, by itself, is 50+ pages and would take too long to go through. However, recommending and sharing a link to the article and two or three take-aways would be appropriate length.
    • Is it closely related to X? Even if X is software development, maybe not. The resource is extremely high level and general and really doesn’t tie inclusion topics with an X.

What is inclusion?

Inclusion is about ensuring people with diverse identities and experiences have equitable access to resources and opportunities and feel safe, welcomed, respected, valued, and encouraged to contribute as their full, authentic selves in any particular group or activity (quoted from Tony Baylis, Lawrence Livermore National Laboratory’s Director for the Office of Strategic Diversity and Inclusion Programs).

If diversity is being asked to the party, inclusion is being asked to dance. Inclusion is accessibility’s close cousin.

Inclusive practices can play a role in improving almost every aspect of a software project including documentation, user interface and user experience, customer support processes, collaborations, presentations and publications, communications (e.g. GitHub or email) and even the actual code we write. The benefits of inclusive practices include reducing barriers to adoption, attracting and retaining a wider talent pool, attracting more customers/users, increased productivity, increased innovation, improved job satisfaction.

For many, inclusion is inseparable from the broader and often institutionalized enterprise of Diversity, Equity, and Inclusion (DE&I). Viewed through a DE&I lens, inclusive practices can wind up being seen more as an exercise in achieving compliance rather than increasing participation or improving productivity. In turn, topics central to DE&I such as gender identity, sexual harassment, and racism can easily obscure our perception of the full landscape of inclusive practices. Although these topics tend to capture more of the news headlines or tend to be where a lot of the more serious work is needed, inclusion is actually much, much wider than just those topics.

There are many dimensions to inclusion

There are many other dimensions to inclusion such as neurodivergence (15-20% of people), mobility impaired (16% of people), handedness (10% of people are lefties), dyslexia/dyscalculia (3-7% of people), visually impaired (1%-40% of people, depending on how we count), hearing impaired (15% of people), speaking impaired (3-7% of people), prone to migraines (10% of people), color vision deficient (CVD) (5% of people), self-regulating glucose impaired (12% of people).

In addition, without trying too hard, it’s easy to think of many other ways in which large swaths of our population have a shared experience which is atypical including such things as English as a second language, immigration status, culturally or religiously relevant legal holidays, remote/hybrid work arrangement, and even time-zone, just to name a few.

People who have trouble empathizing with some dimensions of inclusion can often identify with other dimensions. When they do, that can lead to broadening their perspectives more generally.

We will all experience the impairment dimension

Towards that end, it is worth considering that we are all likely to experience the disability or impairment dimension of inclusion at some point in our lives. As a trivial example, when participating via an audio-only modality in a video teleconference where visual content is being shared, you will experience situational visual impairment. Because of the situation, you are not able to see information which may be critical for you to fully participate and contribute. Likewise, if you are just home from a tough visit with the dentist, you may experience temporary speaking impairment. If you are recovering from an accident and need to use a wheelchair, you will experience temporary mobility impairment. Examples involving situational and temporary impairments make it clear that inclusive practices benefit more than just those who live permamently with disabilities.

When preparing an inclusive minute (IM), there is no need for any formalism. In fact, the less formality, the better. It lowers the bar for anyone considering leading an inclusive minute. It’s best to even discourage the creation of slides, but if an IM leader wants to create a slide to share, they should be asked to keep it to a single slide. Leadership doesn’t require a lot. It’s useful to keep remarks brief, a minute or two at the most. The word “minute” in the title of the practice doesn’t necessarily mean it should be an actual minute, just a small amount of time so it’s easy to add to regular meeting agendas. Depending on a team’s enthusiasm for follow up discussion on any given topic, in reality, an IM will typically take a few minutes.

It’s useful to consider the appropriate cadence for the inclusive minute practice as well. If your team meets once a week, identifying new IM topics for every meeting may become a challenge. Doing an IM every other meeting or the first meeting of each month may be best. If your team meets monthly, having an inclusive minute with every meeting may make the most sense.

Some teams prefer to have an IM at the end of their meetings while others prefer the beginning. There are advantages and disadvantages to either. At the beginning, follow-up dialog can run longer than expected putting the meeting leader in the position of having to cut-off conversation to get to the rest of the agenda. Having the exercise at the beginning of the meeting, though, also ensures it actually happens. It shows commitment. At the end of the meeting, unless the team is committed to reserving time for the activity, it can feel rushed or like an afterthought. Having the activity at the end, though, does provide a natural way for any follow-up conversation to adjourn.

It works best if leadership of the practice can regularly rotate to various members of the team. That said, no team member should be required to lead an IM. It’s best if team members are encouraged (perhaps even by offering them assistance in preparing an IM) to consider leading one, but leadership should otherwise be voluntary.

It may be helpful, early on, to exercise some oversight by checking in with prospective IM leaders and ensuring their chosen topic and plans for sharing fit within scope and time constraints. Once the team gains some experience, oversight may become unnecessary. To help avoid repeats, it is worth maintaining a catalog of topics already shared as well as potential ideas for future inclusive minute topics.

Dealing with conflict

In spite of the fact that inclusion and inclusive practices are aimed at increasing access and participation for everyone, there will always be some who view it as primarily a gesture of political correctness or an imposition, off topic, and may even act against it by constantly playing a contrarian, or otherwise aiming to derail conversation. When such conflicts arise, what can a team leader do?

The first place team leaders can look is their own institution’s stated policies and procedures which often include valuing and furthering the goals of inclusion. See, for example, those of the Department of Energy (DOE) or Lawrence Livermore National Lab. When team members act in ways to derail conversation or are otherwise contrary to inclusive practices, they should be reminded that they are then acting against the stated values of their institution.

In some of the most challenging situations, it may be necessary to seek the help of human resources or an ombuds program, if available. If your institution is committed to its stated values, it should not be hard to find higher level managers willing to back you up.

We already invest heavily in inclusion…in our code

While a focus on inclusive practices may seem like a new idea, the truth is the code we’ve been writing has for decades exemplified all the best goals of inclusion. For example, our community desires interoperable libraries so that, for example, an application can easily swap one solver library (e.g. PETSc) for another (e.g. HYPRE). Interoperability is a manifestation of inclusion in the code we write.

We also value both API (e.g. compile-time) and ABI (link-time) compatibility in successive or related versions of the same library. This is yet another manifestation of inclusion in the code we write. Likewise, we want our applications used by people all over the world and as such, value having interfaces (e.g. GUIs, CLIs) as well as documentation available in multiple human languages. For example, the VisIt application GUI supports English, French, and Spanish and is designed to easily support other human languages.

We also desire widely used libraries to support multiple different programming language interface bindings such as C, C++, Fortran, Python, or Java. For example, the Conduit library can be used naturally within C, C++, Fortran, and Python programs.

The whole goal of performance portability is to enable HPC/CSE applications to operate efficiently on a wide variety of computational resources (e.g. CPUs, GPUs, co-processors, FPGAs, etc.). Performance portability is an extremely challenging design goal requiring substantial effort and resources to achieve. It and the effort we invest in it is yet another example of how the goals of inclusion (e.g. supporting a wide variety of computational resources) manifest in the actual code we design and write.

We value computational kernels and tools that operate on single, double, quad and even mixed or arbitrary precision. For example, the ZFP compression library supports single and double precision, and support for half and quad precision is on the “To Do” list.

The truth is, a substantial level of effort in the design, implementation, and support of the software our HPC/CSE community develops and maintains is all about inclusion (for our software). It only makes sense that we would be equally committed, if not more so, to inclusion for our people as well.