TY - GEN
T1 - How to Debug Inclusivity Bugs? A Debugging Process with Information Architecture
AU - Guizani, Mariam
AU - Steinmacher, Igor
AU - Emard, Jillian
AU - Fallatah, Abrar
AU - Burnett, Margaret
AU - Sarma, Anita
N1 - Publisher Copyright:
© 2022 IEEE.
PY - 2022
Y1 - 2022
N2 - 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%.
AB - 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%.
KW - Diversity
KW - Inclusivity Bugs
KW - Information Architecture
KW - Open Source
UR - http://www.scopus.com/inward/record.url?scp=85133672763&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=85133672763&partnerID=8YFLogxK
U2 - 10.1109/ICSE-SEIS55304.2022.9794009
DO - 10.1109/ICSE-SEIS55304.2022.9794009
M3 - Conference contribution
AN - SCOPUS:85133672763
T3 - Proceedings - International Conference on Software Engineering
SP - 90
EP - 101
BT - Proceedings - 2022 ACM/IEEE 44th International Conference on Software Engineering
PB - IEEE Computer Society
T2 - 44th ACM/IEEE International Conference on Software Engineering: Software Engineering in Society, ICSE-SEIS 2022
Y2 - 22 May 2022 through 27 May 2022
ER -