How to debug inclusivity bugs?: a debugging process with information architecture

Although some previous research has found ways to find inclusivity bugs (biases in software that introduce inequities), little attention has been paid to how to go about fixing such bugs. Without a process to move from finding to fixing, acting upon such findings is an ad-hoc activity, at the mercy of the skills of each individual developer. To address this gap, we created Why/Where/Fix, a systematic inclusivity debugging process whose inclusivity fault localization harnesses Information Architecture(IA)---the way user-facing information is organized, structured and labeled. We then conducted a multi-stage qualitative empirical evaluation of the effectiveness of Why/Where/Fix, using an Open Source Software (OSS) project's infrastructure as our setting. In our study, the OSS project team used the Why/Where/Fix process to find inclusivity bugs, localize the IA faults behind them, and then fix the IA to remove the inclusivity bugs they had found. Our results showed that using Why/Where/Fix reduced the number of inclusivity bugs that OSS newcomer participants experienced by 90%.

Diverse teams have been shown to be more productive as well as more innovative. One form of diversity, cognitive diversity --- differences in cognitive styles --- helps generate diversity of thoughts. However, cognitive diversity is often not supported in software tools. This means that these tools are not inclusive of individuals with different cognitive styles (e.g., those who like to learn through process vs. those who learn by tinkering), which burdens these individuals with a cognitive "tax" each time they use the tool. In this work, we present an approach that enables software developers to: (1) evaluate their tools, especially those that are information-heavy, to find "inclusivity bugs" - cases where diverse cognitive styles are unsupported, (2) find where in the tool these bugs lurk, and (3) fix these bugs. Our evaluation in an open source project shows that by following this approach developers were able to reduce inclusivity bugs in their projects by 90%.