My brief readout is a guided reflection using questions shared by Matt Germonprez. This reflects my review of our work as a team to date and also shares some of my hopeful outlooks for what our amazing team can accomplish together. This readout will cover (1) our accomplishments as a team, (2) what was expected and surprising, and (3) what we could change in the next year.

CHAOSS accomplishments & learnings 🔗

Three achievements and aspirations stand out over the past year:

1. Established process management and a team workflow.
2. Created a small but active Community of Practice (CoP).
3. Sharing our results with CHAOSS and the Open ecosystem.

Processes & workflow 🔗

For direct participants of the team, the Ford Foundation funding did not come with strict requirements or success metrics. As we assembled our team, we were given the discretion of how to conduct a D.E.I. review for the project and determine the best course of doing that. This allowed for creative freedom to figure out what would work best for CHAOSS. Additionally, I could not identify a straightforward way to discover other Open communities and projects doing our kind of work. Since there were also not many other known successful models to follow, we combined our shared experiences across multiple Open communities to build our team, identify main areas of focus, and engage the community around our efforts.

This is an achievement because we collectively created an active group that makes incremental, positive changes to CHAOSS. This is a model we could share with other projects so that others can learn from our experiences.

Community of Practice 🔗

Our team is a small but engaged group of D.E.I. practitioners. We share a connection through our ongoing review of the CHAOSS Project, but we also give and take from our own personal experiences outside of CHAOSS. Our group regularly meets and discusses complex, difficult issues that are both (a) not easy to discuss openly and (b) applicable to many communities beyond only CHAOSS. Our team meetings are a safe space that promotes honest and constructive discussion centered on diversity, equity, and inclusion. In addition to our recommendations and direct efforts with CHAOSS, I often reflect on our conversations as a team when working with other Open communities. An example of this is how we built a list of questions to get a “pulse” from the community on their feelings about CHAOSS.

Sharing results with CHAOSS and beyond 🔗

This is aspirational and not yet fully realized. Our team has collected a solid portfolio of stories and experiences that other communities would stand to benefit learning from. I consider this a current achievement because while our work does specifically look at CHAOSS, we also often reflect from a general perspective and how a topic of interest might look in other communities. When the time comes to package our findings, I believe we are setting ourselves up for easier messaging and outreach opportunities in the future.

According to expectations 🔗

While I have worked in Open Source D.E.I. communities since 2015, I have never conducted an applied research review for community D.E.I. before. I did not come into this with strong immediate expectations because it would inevitably reflect the backgrounds and strengths of the team we would assemble. However, I did have specific hopes or things I hoped would be realized by this work.

As expected 🔗

• Data-driven approach: We began this work without a strong representation of the state of CHAOSS. What do contributors think about the project? While data is not a universal panacea, we gravitated to a community survey early on because we needed to understand the community experience better first before making serious suggestions.
• Time zones are hard: Our team was spread out across North America, Africa, LATAM, and Europe. Additionally, the work with CHAOSS was also a part-time venture for most of us, in addition to primary employment. Calendars and schedules are hard to get right. Since our team’s organization was ad-hoc, momentum would occasionally slow for some periods.
• We have an amazing team! I expected great things once we identified our roster. We have also had more amazing people join us over time and add new passion and insight to our focus as a group.

Surprises 🔗

• Documenting our impact is not always intuitive: While we have done internal storytelling work within the CHAOSS Project, we do not have a good record of our achievements to date. Our linear progression does not lend itself easily to self-reflection and recalibration. Although much of our focus is on the CHAOSS community survey and CHAOSS Africa, we also facilitated several other notable achievements in the project in the last year. See the following examples:
  • Supporting the establishment of a Code of Conduct Committee.
  • Community office hours for newcomers.
  • Improved, peer-to-peer onboarding experience in CHAOSS.
  • Increased efforts in CHAOSS mentored projects (e.g. Outreachy and GSoC).
  • Recommending changes to the project and community, like broader localization to Chinese & Spanish and establishing a D.E.I. council.
• Losing and regaining steam on the survey: Although the community pulse survey was one of the earliest tasks identified in our work, launching a first survey proved to take a lot of resources from the team. We briefly stalled out on the survey effort while focused on other areas (like listed above). While our team was able to achieve many smaller victories for CHAOSS with low-hanging fruits, it took a sustained focus and slowdown on new topics to achieve larger contributions like the community pulse survey.

Changes for the CHAOSS team next year 🔗

Looking ahead to 2023, I hope to strengthen our efforts as a team in these areas:

1. Packaging our work
2. Dissemination of our work

Packaging 🔗

Our work stream was linearly ordered and we took a forward-looking approach. Now is a good time to look back and reflect on our results to date. What are our key findings and observations? What suggestions will we make to CHAOSS? How could other communities learn from our experience running this review? One task for us as a team is to identify key messages and themes so that dissemination into broader domains is possible.

Dissemination 🔗

Once we package our work, notes, and reflections, we should take an active approach to disseminating and sharing our work. This includes both the CHAOSS Project and a more general audience. For the CHAOSS Project, this could be a written report, presentations to the CHAOSS board, speaking at CHAOSScon, and outreach to the multiple Working Groups. For a general audience, this could include speaking at industry conferences, sharing our work with other Communities of Practice, social media, or other ways of promoting our deliverables.

Accommodations move us closer to equality but not equity. The presence of accommodations implies a belief in an “us” and a “them”. One group benefits from default inclusion, while another group either raises a collective voice, or is de-facto excluded. Instead of designing our world for others different than ourselves, we must design our world together. It is a quicker way to achieve a more just world.

The “abled” community needs to challenge our perspectives and do our share of the learning required to see things from another perspective.

An example I saw from Twitter that made an impression on me was how someone explained the idea of combinations and permutations of the five human senses: sight, hearing, smell, taste, and touch. The commonly-held belief is that lacking one (or more) of these senses leaves you deprived. Without one of these senses, your potential is limited and you deserve to be pitied.

Multi-sensing > accommodations 🔗

So, what does it mean to be multi-sensing? Most of us see our five senses (sight, hearing, smell, taste, touch) as a fixed state of sensory stability. These senses and basic mental stability are socially-assumed as always present. They define how we individually experience life.

Often those lacking one or more of these senses are seen as deprived. They are perceived as missing something or to have lost something they can never fully regain. The absence of a human sense comes with the added psychological burden of living in a world where you are often the afterthought, the “new use case”, the countless trials of countless beta versions of any kind of software that might help overcome the disadvantage of “missing” a sense or mental disability.

I suggest an alternative way to design for accessibility and inclusivity. A personal deviation is not written off as “missing” something, but instead as a new combination of senses gained. Designers should assume an expected and guaranteed variable of this new combination. Accessible design must be a first-class citizen in early project management planning.

To put it another way, observe the presence and lack of senses among us as a matrix of combinations, instead of large swathes of characteristics assumed to always be present. We unlock the best of our design knowledge to think in the pursuit of access to the greatest many instead of “what ticks off the box”.

Before, we saw an accommodation as when a specific feature is added to software for someone lacking one or many senses. But we must shift from accommodations to full inclusion. Accommodations are acknowledgements of disability. It assumes a fixed state where a set of critical features to guarantee usability will always lag behind for a subset of people. True equality is seeing access for those with disabilities as equal to the design of features for those with five active senses.

Featured image photo by Matthew T Rader on Unsplash.
Modified by Justin Wheeler.

Use alt tags for Markdown images 🔗

Often an embedded picture in Markdown looks something like this:

![Screenshot_2019-06-14.jpg](https://example.com/Screenshot_2019-06-14.jpg)

When you render the Markdown, you see your picture. However, you don’t see the Screenshot_2019-06-14.jpg string. You might wonder what its purpose is or why bother changing it at all. But imagine for a moment if instead of seeing your picture when you rendered your Markdown, you only saw Screenshot_2019-06-14.jpg where your picture should be. Screen reader users often encounter this problem.

So instead, describe your Markdown image so a person that uses a screen reader can also follow the conversation:

![A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers](https://example.com/Screenshot_2019-06-14.jpg "A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers")

It takes an extra few seconds of your time, but it is one small way you can help make a better Internet for everyone.

P.S. – The text wrapped in quotation marks between the parentheses adds the title HTML attribute to your image, so the text appears as a tooltip when you mouse over the image. The more you know!

Photo by Roman Kraft on Unsplash