Si te dedicas al desarrollo de software, puede que todavía no hayas detectado inclusivity bugs en tu código. O quizás sí que los has visto, pero no sabes cómo solucionarlos. Este artículo está pensado para ti.
Un inclusivity bug es un error en el software que, sin romper la funcionalidad principal, perjudica de forma desproporcionada a un grupo concreto de personas usuarias. En este caso, hablamos de los que afectan a la perspectiva de género: desde etiquetas confusas, carencia de opciones claras o lenguaje no inclusivo, hasta flujos de trabajo pensados para un solo perfil de usuario.
Para saber lo que está pasando y qué hacen los desarrolladores OSS al respecto, un equipo internacional ha realizado un estudio con 266 desarrolladores experimentados de GitHub. Los resultados son claros: la mayoría no aplica ninguna práctica para evaluar inclusividad y casi todos carecen de recursos concretos -guías, herramientas o metodologías- para hacerlo. Y quienes intentan aplicarlo a menudo lo hacen de forma improvisada, sin un método claro.
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.
¿Qué investigó el estudio
Este trabajo forma parte del proyecto AID: An automated detector para gender-inclusivity bugs en OSS project pages. El equipo encuestó a desarrolladores OSS para conocer:
El estado actual de las prácticas de evaluación de inclusividad en proyectos de software libre.
Las dificultades que encuentran para su incorporación en su proceso de desarrollo.
Se contactó con 3.124 desarrolladores experimentados de GitHub, seleccionados por su número de seguidores, respondiendo a 266 de ellos.
Resultados clave
77% no incorpora ninguna práctica para evaluar inclusividad.
92% indica no disponer de recursos concretos (guías, herramientas) para hacerlo.
Sólo un 8% del total utiliza alguna técnica específica; muchas son prácticas ad hoc sin metodología formal.
Principales barreras detectadas
Falta de concienciación o interés
Parte de la comunidad no considera prioritaria la evaluación de inclusividad o no es consciente de su relevancia, dejando la decisión a la iniciativa individual.
“Inclusivity happens on an ad hoc basis and depends on the individual ingenier…” (P84)
Percepción de baja prioridad en el OSS
Algunos opinan que la comunidad de software libre nunca ha dado relevancia a este tema.
“Open source communities have never prioritized inclusivity.” (P145)
Carece de guías o referencias claras
A diferencia de la calidad del código o la seguridad, no existen estándares ampliamente aceptados para evaluar la inclusividad.
“…there are no su guidelinas or tools … Y hope that justo as we have guidelinas para code quality we [could] also have inclusivity principles…” (P60)
Escasez de recursos técnicos y herramientas
Sin herramientas específicas, los equipos improvisan soluciones, con menor eficacia y mayor coste.
“Lack of knowledge and tools makes developers reinventing the wheels all the time.” (P130)
Incluso quienes intentan aplicarlo lo hacen sin métodos formales.
“We don’t use specific techniques…” (P299)
AID: un paso para cubrir la carencia
El panorama está claro: la mayoría de desarrolladores OSS no dispone de medios para evaluar y corregir inclusivity bugs.
AID es una herramienta que automatiza parte del método GenderMag para detectar problemas que dificultan la participación de ciertos grupos de personas en proyectos OSS. En esta primera versión se centra en la persona “Abi” y en su estilo de procesamiento exhaustivo de información, identificando cuestiones como enlaces poco descriptivos, ausencia de etiquetas en incidencias o carencia de guías para principiantes.
Probada en 20 proyectos OSS, logró una precisión del 69% y un recorte del 92%, incluso detectando errores que pasaron inadvertidos a los evaluadores humanos.
Más información:
FemFrame: evitando las barreras desde el principio
Las barreras detectadas en este estudio —falta de guías, herramientas y metodologías claras— son el punto de partida de FemFrame. Ofrecemos itinerarios prácticos para que los equipos de desarrollo puedan integrar la perspectiva de género desde el inicio del proyecto.
El objetivo es que los equipos no se encuentren con los mismos obstáculos que revela la encuesta y dispongan de apoyo para incorporar esta perspectiva sin frenar el desarrollo ni aumentar de forma inasumible la carga de trabajo.