If you’re a software developer, you may not have yet detected inclusivity bugs in your code. Or maybe you have seen them, but don’t know how to fix them. This article is for you.
An inclusivity bug is a software error that, without breaking the main functionality, disproportionately harms a specific group of users. In this case, we are talking about those that affect the gender perspective: from confusing labels, lack of clear options or non-inclusive language, to workflows designed for a single user profile.
To find out what is happening and what OSS developers are doing about it, an international team conducted a study with 266 experienced GitHub developers. The results are clear: most do not apply any practices to assess inclusivity and almost all lack specific resources—guidelines, tools, or methodologies—to do so. And those who try to apply them often do so in an improvised manner, without a clear method.
Un equip de recerca format per Amreeta Chatterjee, Mariam Guizani, Catherine Stevens, Jillian Emard, Mary Evelyn May, Margaret Burnett, Iftekhar Ahmed i Anita Sarma ha investigat fins a quin punt els desenvolupadors de programari lliure incorporen la perspectiva de gènere en els seus projectes.
Ho han fet a través d’una enquesta a 266 desenvolupadors experimentats de GitHub, analitzant les seves pràctiques i les barreres que troben per prevenir i corregir inclusivity bugs. Aquesta recerca ha servit per dissenyar AID, una eina que automatitza part del mètode GenderMag i ajuda els equips a detectar aquests errors de manera ràpida i sistemàtica, amb l’objectiu de millorar la qualitat i l’accessibilitat del programari que desenvolupen.
What did the study investigate?
This work is part of the AID project: An automated detector for gender-inclusivity bugs in OSS project pages. The team surveyed OSS developers to find out:
The current state of inclusivity assessment practices in free software projects.
The difficulties they encounter in incorporating them into their development process.
3,124 experienced GitHub developers were contacted, selected by their number of followers, and 266 of them responded.
Key results
77% do not incorporate any practices to assess inclusivity.
92% indicate that they do not have specific resources (guides, tools) to do so.
Only 8% of the total use any specific technique; many are ad-hoc practices without formal methodology.
Main barriers detected
Lack of awareness or interest
Part of the community does not consider the inclusivity assessment a priority or is not aware of its relevance, leaving the decision to individual initiative.
“Inclusivity happens on an ad-hoc basis and depends on the individual engineer…” (P84)
Perception of low priority in OSS
Some believe that the free software community has never given relevance to this issue.
“Open source communities have never prioritized inclusivity.” (P145)
Lack of clear guides or references
Unlike code quality or security, there are no widely accepted standards for assessing inclusivity.
“…there are no such guidelines or tools … I hope that just as we have guidelines for code quality we [could] also have inclusivity principles…” (P60)
Shortage of technical resources and tools
Without specific tools, teams improvise solutions, with less efficiency and greater cost.
“Lack of knowledge and tools makes developers reinventing the wheels all the time.” (P130)
Even those who try to apply it do so without formal methods.
“We don’t use specific techniques…” (P299)
AID: a step to cover the gap
The picture is clear: most OSS developers do not have the means to evaluate and fix inclusivity bugs.
AID is a tool that automates part of the GenderMag method to detect problems that hinder the participation of certain groups of people in OSS projects. In this first version, it focuses on the person “Abi” and his style of exhaustive information processing, identifying issues such as poorly descriptive links, absence of tags in incidents or lack of guides for beginners.
Tested in 20 OSS projects, it achieved a precision of 69% and a recall of 92%, even detecting errors that went unnoticed by human evaluators.
More information:
FemFrame: avoiding barriers from the start
The barriers detected in this study—lack of clear guides, tools, and methodologies—are the starting point of FemFrame. We offer practical itineraries so that development teams can integrate the gender perspective from the beginning of the project.
The goal is that teams do not encounter the same obstacles that the survey reveals and have support to incorporate this perspective without slowing down development or unacceptably increasing the workload.