loader

Updates

Generating audio...

arxiv

Paper 2503.05470

The Software Diversity Card: A Framework for Reporting Diversity in Software Projects

Authors: Joan Giner-Miguelez, Sergio Morales, Sergio Cobos, Javier Luis Canovas Izquierdo, Robert Clariso, Jordi Cabot

Published: 2025-03-07

Abstract:

The interest and concerns about diversity in software development have soared in recent years. Reporting diversity-related aspects of software projects can increase user trust and help regulators evaluate potential adoption. Furthermore, recent directives around AI are beginning to require diversity information in the development of AI products, indicating the growing interest of public regulators in it. Despite this importance, current documentation assets in software development processes frequently overlook diversity in favor of technical features, partly due to a lack of tools for describing and annotating diversity. This work introduces the Software Diversity Card, a comprehensive framework for reporting diversity-related aspects of software projects. The card is designed to profile the different types of teams involved in developing and governing software projects (including the final user groups involved in testing), and the software adaptations for specific social groups. To encourage its adoption, we provide a diversity modeling language, a toolkit for generating the cards using such language, and a collection of real-world examples from active software projects. Our proposal can enhance diversity practices in software development e.g., through open-source projects like the CONTRIBUTING.md file), support public administrations in software assessment, and help businesses promote diversity as a key asset.

Paper Content:
Page 1: The Software Diversity Card: A Framework for Reporting Diversity in Software Projects Joan Giner-Migueleza, Sergio Moralesb, Sergio Cobosb, Javier Luis C´ anovas Izquierdob, Robert Claris´ ob, Jordi Cabotc,d aBarcelona Supercomputing Center, BSC-CNS, Barcelona, Spain, bUniversitat Oberta de Catalunya, Barcelona, Spain, cLuxembourg Institute of Science and Technology, Esch-sur-Alzette, Luxembourg, dUniversity of Luxembourg, Esch-sur-Alzette, Luxembourg, Abstract The interest and concerns about diversity in software development have soared in recent years. Reporting diversity-related aspects of software projects can increase user trust and help regulators evaluate potential adoption. Furthermore, recent di- rectives around AI are beginning to require diversity information in the development of AI products, indicating the growing interest of public regulators in it. Despite this importance, current documentation assets in software development processes frequently overlook diversity in favor of technical features, partly due to a lack of tools for describing and annotating diversity. This work introduces the Software Diversity Card, a comprehensive framework for reporting diversity-related aspects of software projects. The card is designed to profile the different types of teams involved in developing and governing soft- ware projects (including the final user groups involved in testing), and the software adaptations for specific social groups. To encourage its adoption, we provide a di- versity modeling language, a toolkit for generating the cards using such language, and a collection of real-world examples from active software projects. Our proposal can enhance diversity practices in software development ( e.g., through open-source projects like the CONTRIBUTING.md file), support public administrations in software assessment, and help businesses promote diversity as a key asset. Keywords: diversity, inclusion, ethics, documentation, domain-specific language Preprint submitted to Elsevier March 10, 2025arXiv:2503.05470v1 [cs.SE] 7 Mar 2025 Page 2: 1. Introduction The diversity aspects around software projects have been a growing concern in the last years [1, 2]. Recent research has proven, among others, that diverse and inclu- sive teams can produce better software [3], benefit open-source communities [4], and facilitate understanding of the human factor involved in the development process [5]. As a result, many efforts have been made to create diverse and inclusive software development teams [6, 7, 8]. However, the impact of diversity is not limited to devel- opment teams; it has also been shown to benefit software end users. Assessing the diversity of testers or user feedback may be critical for software projects to meet the needs of their target users [9]. Learning about the people engaged in software product creation can help users better understand the software they use, thereby increasing trust. For example, a period tracker app designed for women may inspire greater user confidence if the de- velopers and testers include women sharing similar experiences and needs. Similarly, when developing software for specific social groups, it is essential to consider their context and unique characteristics. For example, Bangladeshi fisherfolk [10] faced significant barriers in adopting new software technologies due to factors such as low digital literacy, varying language styles, and their community’s traditional knowledge transmission methods. These kinds of barriers can be mitigated by gaining a better understanding of the social group’s context and specific needs. Concerns about sharing diversity information are also increasing in other domains, impacting public regulatory bodies worldwide. For instance, influential documenta- tion frameworks in the Machine Learning (ML) field stress the need to document the diversity of actors involved in the data creation processes [11, 12, 13]. These recommendations have been incorporated into recent regulations on artificial intelli- gence, such as the European AI Act1and the US Bill of Rights2, and are expected to become a fundamental practice in developing future responsible AI applications. This increasing interest in transparency and diversity illustrates the utility of this information for public regulators. For example, regulations requiring gender balance in software development can encourage more women to enter the field, or policy- makers might promote economic growth in particular areas by requiring developers to come from specific regions. Furthermore, similar to the Bangladeshi fisherfolk’s example, an administration might ensure that the app’s beta tests [14] are carried out across a specific population to ensure that the app is properly designed for them. 1AI Act required documentation - Annex IV: https://www.euaiact.com/annex/4 2BoR homepage: https://bidenwhitehouse.archives.gov/ostp/ai-bill-of-rights 2 Page 3: Despite the undeniable benefits of reporting diversity-related aspects of software projects, there is neither current standard documentation practices nor concrete reporting technique for this purpose. Current documentation assets in software en- gineering focus on the technical features of software, often overlooking the social and diversity aspects. To fill this gap, and inspired by recent ML data documentation frameworks, we propose the Software Diversity Card as a comprehensive approach to documenting and reporting diversity information in software projects. The card allows the profil- ing of the various types of teams involved in the development process, including the development team, non-coding contributors to the project [15] ( e.g., issue reporters, translators), final users involved in testing ( e.g., crowd testers [14]), and those in- volved in the software governance. Also, the card aims to capture the software usage context by profiling the intended target users and the software adaptations for spe- cific social groups, such as accessibility features to particular disabilities [16]. Our reporting framework could benefit the open-source (OS) community diver- sity practices by being integrated along with other project documentation, such as the contributing guidelines [17], the codes of conduct [18] or governance files [19] in public repositories. It may also benefit the research community by being included in the submission guidelines for scientific journals that publish original software publi- cations [20]. Furthermore, our framework can assist businesses in viewing diversity as a valuable asset and help public administrations by incorporating diversity into their software assessment criteria. In the remainder of this document, Section 2 presents the background and re- lated work on diversity and human aspects in software development, while Section 3 empirically evaluates the current reporting diversity practices in open-source com- munities motivating the need for our proposal. Then, Section 4 presents the main concepts and structure of the card. Section 5 describes the development of the pro- posal, introducing a diveristy domain-specific language and a toolkit (including a language plugin3and a form-based web editor4) that supports developers in creating diversity cards for their projects. In Section 6, we present two running examples of real-world software projects described using our proposal. Finally, in Section 7, we discuss the challenges and open research lines on reporting diversity information in software projects. 3Language plugin repository: https://github.com/SOM-Research/SoftwareDiversityCard 4Online demo of the web editor: https://huggingface.co/spaces/JoanGiner/ SoftwareDiversityCard-Generator 3 Page 4: 2. State of the art This section reviews previous research on diversity and inclusion in software de- velopment, identifying the dimensions and teams where diversity plays an important role in software projects. This will serve as the foundation for our work. To that end, we begin by reviewing works that focus on the development team, then on other types of participants in software projects (i.e., non-coding roles), and finally on the importance of diversity for the end users and the project adaptations for specific populations. Finally, we conduct a brief review of ML documentation frameworks, assessing the value of profiling those involved in project governance. 2.1. Software developers diversity and inclusion The intersection of politics and economics is fundamental in discussions of eq- uity and inclusion in computer science, as technological advancements and software projects are influenced by social, economic, and political factors. Relevant works [1, 2] in Software Developers’ Diversity and Inclusion (SDDI) have pointed out that the economic structures influence those who have access to technology, whose perspec- tives are prioritized in software development and whose biases become embedded in digital systems. As a relevant aspect of our proposal, these works have defined a set of essential dimensions such as gender, ethnicity/race, and disabilities, among others, that will serve as the foundation for our profiles. Moreover, another relevant research [21] has conducted an empirical study on diversity awareness in the software engineering research community, identifying similar dimensions. In terms of gender diversity, a recent study [22] shows that lack of gender diversity remains an issue, since they observed less than 10% of female-gender developers in the open-source projects analyzed. In response to this situation, Oliveira et al. [7] have studied the path of women in software engineering, detecting persistent challenges in their career development. In the same line, Gila et al. [23] described the effects of gender diversity on team performance based on personality types that show that female-gender developers looked uneasy in male-dominant teams. In contrast to this, and motivating the field of research, recent findings [24] show the clear benefits of gender-diversity in developing software products in other scientific fields [3]. Also, regarding the race/ethnicity of the development team, Nadri et al. [25] presents a novel qualitative analysis of non-merged pull requests and classifies the rea- sons why the pull requests were not merged based on four perceived racial identities: Asian/Pacific Islander, Black, Hispanic, and White. The authors found that percepti- bly Black and Asian/Pacific developers had pull requests rejected at higher rates than those of perceptibly White developers. Other works as [26] examine how geographic location associates with pull request submission and acceptance rates in open source 4 Page 5: projects. The authors found that most closed pull requests came from developers in the United States, the United Kingdom, and Germany, countries with a high HDI5. Disabilities have also been a focus of interest. For instance, recent research in the field has focused on creating more inclusive and diverse teams and integrating socially protected groups such as neurodivergent people. For example, Silva et al. [27] identifies the main techniques in Agile Methodologies to promote the inclusion of people with disabilities in development teams, and Liebel et al. [28] has proposed a set of recommendations to the industry to include developers suffering from ADHD (Attention-Deficit/Hyperactivity Disorder). Furthermore, answering the need for intersectional analysis of diversity, Prana et al. [29] have analyzed the intersection of gender and region origin in the research community. This study considered the consistency of gender inequalities across different regions. 2.2. Diversity comprises a wider definition of participants However, a wider range of profiles often participate in software projects. Re- cent research has highlighted the relevant role of these profiles in software commu- nities [15]: individuals commenting and reacting in open-source communities, pull request reviewers, bug reporters, translators, or developer advocates. In addition, recent studies about open-source communities [30] have highlighted the toxicity in these communities, motivating the need to profile communities if we want to avoid toxic behaviors. In this sense, Paul et al. [31] looked at code reviews, detecting that male reviewers were more likely to provide negative comments to female contributors. In contrast, Zolduoarrati et al. [32] analyzed Stack Overflow archival data over 11 years, showing that female contributions tend to be more cooperative, supportive and collective and that women are more willing to share knowledge than their male counterparts. Another profile that has raised concerns in terms of diversity is that of modelers, and recent works [33] in the model-driven community also focused on the human aspects of modelers, emphasizing the modelers’ diversity and highlighting the relevance of their background in modeling decisions. 2.3. Diversity and human aspects impacting software end-users Diversity and the human aspects of end-users play a critical role in software projects, as they directly impact usability, accessibility, and overall user satisfaction. Research has increasingly highlighted the importance of inclusiveness in software 5The Human Development Index (HDI) is a measure of health, education, income and living conditions in a each country, compiled by the United Nations Development Programme. 5 Page 6: development, emphasizing that neglecting diverse user characteristics, limitations, and abilities can lead to dissatisfaction and exclusion. Studies such as those by [34] and [35] propose taxonomies and analytical frameworks to better understand human-centric issues in software engineering. A key challenge is that inclusiveness is often overlooked during the development process, resulting in software that fails to accommodate the full range of human diversity [36, 37]. For instance, by integrating user feedback throughout the life-cycle, developers can ensure that applications serve a broader audience while minimizing the risk of bias and accessibility barriers [38]. Efforts to adapt software to specific populations have already been made in the research community. The concept of Adaptive User Interfaces (AUIs) has gained traction in research [39, 40], offering solutions that personalize interfaces for different user groups, including individuals with chronic conditions [41]. Similarly, crowd- testing has emerged as a valuable approach in software development, enabling diverse users to participate in the testing phase and provide real-world insights into software usability. Studies on crowd testers, such as those by [42, 9], emphasize the importance of selecting an appropriate tester community to ensure a representative evaluation of software. 2.4. Diversity in machine learning documentation frameworks Recent documentation and reporting frameworks in the Machine Learning (ML) field, such as Datasheets for Datasets [11], Data Statements [43], and Data Cards [12], have become crucial to ensuring transparency, accountability, and fairness of these systems. These frameworks aim to capture the various aspects of data collection, model development, and evaluation while explicitly addressing biases, ethical con- siderations, and the societal impact of ML technologies. By incorporating diversity- related metadata into documentation, stakeholders can better assess whether ML systems fairly represent different demographic groups, mitigate potential biases, and adhere to inclusive algorithmic decision-making principles. Public regulatory initia- tives such as the European AI Act6and the AI Bill of Rights7have started to adopt them, showing the increasing interest of public administrations in diversity. One of the relevant points of these frameworks is the wider definition of partici- pants behind an ML system, beyond the development team. Such frameworks aim to profile those individuals involved in gathering and annotating the data used to train the ML algorithms, as well as those in charge of governing the project, showing the relevance of these groups in decisions that may affect the final behavior of the ML 6AI Act required documentation - Annex IV: https://www.euaiact.com/annex/4 7Bill’s official website: https://www.whitehouse.gov/ostp/ai-bill-of-rights 6 Page 7: models. In relation to our work, ML systems are, in fact, software systems. There is a path to study the integration of this ML-specific diversity needs (such as profiling data labellers) with broader software documentation proposals as we propose in this work. On the other hand, these works show the relevance of assessing also those who govern the projects, a case specially relevant for open-source communities, with examples of relevant open-source communities as Drupal8or Vue.js9who disclose publicly their governing participants and policies. 3. Current practices on reporting diversity in open-source software After analyzing the current state of the art on documenting diversity aspects in the previous section, we gathered insights into whether these aspects are present in Open-Source Software (OSS), a key field where they could and should be applied. OSS leverages the collaborative work of contributors to develop and evolve software projects. Transparency and openness are, therefore, key to keeping the project and the community alive, vibrant, and successful. Several works have emphasized the need to include the contributing guidelines [17], the code of conduct [18] of these contributors, or explicitly define the governance of a project [44], but no indications or techniques address diversity information. To evaluate the current practices, we conducted a study to analyze the presence of diversity information regarding the relevant groups identified in the previous section across OSS projects on GitHub . 3.1. Study method We studied the 200 top-starred repositories10inGitHub for the top 5 program- ming languages11, namely: C#, Java, JavaScript, Python, and Typescript. We there- fore analyzed a total of 1,000 repositories. To create the dataset of our study, we first retrieved the list of the top repositories for each selected programming language using theGitHub API on January 22nd, 2025, and collected the first 200 repositories that had recent activity in the form of commits within the last 30 days. Then, for each repository, we recovered all non-coding files aimed at documenting how the project was developed, specifically: readme, contributing, code of conduct, governance, code owners, community, support, security, release and funding. For each file, we searched for different variations of their name, e.g., for codes of conduct we looked for files with 8Drupal’s published board association profiles. 9Vue.js published governance wiki: https://github.com/vuejs/governance 10In this section we use the terms project and repository as synonyms. 11According to the ranking of top programming languages in GitHub in 2024. 7 Page 8: Listing 1: Excerpt of the prompt used for searching evidence for A1 ( i.e., Development Team). Analyze the following text and respond in JSON format : 1. Does the text mention the development team explicitly ? 2. Are any specific aspects of the development team mentioned (e.g., team size , geographic diversity , gender diversity , roles , expertise , etc .)? If yes , list the aspects mentioned . Output format : { " mention_to_dev_team ": "yes/no", " profile_aspects ": { " mentioned ": "yes/no", " aspects ": [" list of aspects if mentioned , otherwise empty "] } } names such as coc.md ,code ofconduct.txt orCODE-OF-CONDUCT.adoc . Finally, we analyzed the extracted files to search for diversity documentation. The search for diversity documentation evidence has focused on five main groups extracted from the review of the previous section, and further presented in Section 4. Specifically: (A1) the development team, and whether they mention profile aspects about the developers; (A2) non-coding contributors, and whether they explain non- coding roles; (A3) tests with potential users, and whether they mention labor force or report platforms; (A4) usage context, including the target population and possible specific adaptations; and (A5) governance, including information on funders. Areas A1 and A2 are motivated by the works on diversity for developers and non-coding roles (cf. Sections 2.1 and 2.2), while A3 and A4 are inspired by the need for specifying human aspects (cf. Section 2.3). The works on ML documentation (cf. Section 2.4) prompted A5. For each area, we reported whether the OSS project included (or not) such information. To perform the analysis and search for diversity documentation, we built a tool based on Large Language Models (LLMs)12. In particular, we relied on GPT-4o- mini. The use of LLMs for analyzing text has demonstrated their effectiveness, for instance, for sentiment analysis [45, 46], text classification [47, 48], studying social interactions [49], and detecting ethical deviations [50]. In our context, the use of 12Tool’s repository: https://github.com/SOM-Research/Analyzer-Diversity-Card 8 Page 9: Area C# Java JS Python TS Avg A1 – Refer to development team 28.0% 31.5% 28.0% 27.5% 33.0% 29.6% ...and mention profile aspects 22.0% 20.5% 22.0% 21.5% 26.0% 22.4% A2 – Describe non-coding contributors 30.5% 27.0% 32.0% 27.5% 31.5% 29.7% ...and explain non-coding roles 24.0% 20.5% 26.0% 18.5% 24.4% 22.7% A3 – Tests with Users 3.5% 3.5% 1.5% 5.0% 4.0% 3.5% ...and mention labor force 0.0% 0.5% 0.0% 0.5% 0.5% 0.3% ...and report platforms 0.2% 0.2% 0.0% 0.3% 0.1% 0.2% A4 – Define specific use case 84.0% 74.5% 78.5% 83.0% 68.0% 77.6% Specify target population 34.0% 28.5% 32.0% 36.5% 30.0% 32.2% Describe specific adaptation 15.0% 13.5% 17.0% 21.5% 15.5% 16.5% A5 – Define governance participants 28.5% 31.5% 27.0% 27.0% 30.0% 28.8% Indicate funders 27.0% 15.0% 32.0% 19.5% 30.0% 24.7% Table 1: Presence of diversity documentation in 1,000 OSS projects. LLMs eliminates the need for extensive preprocessing, enabling a more streamlined and direct analysis of the text. Our tool receives the extracted files as input and performs a prompt-driven search of diversity information for each area. Each prompt instructs the LLM to look for evidence in a specific area and includes some examples (i.e., few-shot prompting). Listing 1 shows an excerpt of one of the five prompts used, in particular, the one addressing A113. To validate the tool, we manually checked the evidence found for each area for a sample of 50 random projects from our dataset, obtaining a 92.54% agreement between our assessment and the tool output. 3.2. Study results Table 1 shows the results of our study. The first column shows the area under analysis, while the rest of the columns indicate the percentage of projects including evidence for such areas. Columns 2 to 6 show the percentage for the subset of projects of a specific programming language, while the last column shows the average value. Rows show the results per area. Note that A1, A2 and A3 include subareas, for instance, A1 seeks evidence referring to the development team ( e.g., 28.0% of the C# projects), and then, for those projects including information about developers, it searches for mentions to profile aspects ( e.g., 22.0% of the C# projects referring to the development team). As can be seen, the highest values are found for A4 ( i.e., 13The complete list of prompts used in the study can be found at https://doi.org/10.5281/ zenodo.14981689 9 Page 10: definition of specific use cases) but, in general, the presence of diversity information for all areas is low. In the following, we analyze the results per area. Information about the development team and non-coding contributors has been found in less than a third of the analyzed projects ( i.e., 29.6% and 29.7% of the projects, respectively). However, when this information is available, it generally also includes additional details on development profiles or non-coding roles ( i.e., 22.4% and 22.7% of the projects reporting information on the development team and non- coding contributors, respectively). Further analysis on what development profiles are reported revealed that the main information facilitated is related to development roles and team size, while geographic and gender diversity are rarely commented. Regarding non-coding roles, the three most used roles are reporters, translators, anddocumenters . Information about governance and funders shows results similar to those obtained for the development team and non-coding contributors, with less than a third of the analyzed projects covering this area. Evidence of references on user testing activities are the lowest ones, averaging 3.5% across projects. When this information is reported, details on the use of labor force and reporting platforms are nearly absent ( i.e., 0.3% and 0.2% of the projects reporting information on testing, respectively). The presence of information related to usage context (A4) is the highest compared to other areas, with specific use cases being the most documented, averaging 77.6% across projects. A detailed analysis revealed that the most common terms associated with use cases include concepts such as software creation, data handling, application development, tool building, and web solutions. These results highlight a strong focus on general-purpose applications. Regarding target populations, the information is limited and present in only 32.2% of projects. Among these, developers are by far the most frequently mentioned group, followed to a lesser extent by other technical profiles ( i.e., engineers, scientists). Data on specific adaptations is the most scarce, and is mentioned in only 16.5% of projects, where most references are related to language localization. We believe these findings reveal a general lack of documentation on diversity, thus confirming our initial hypothesis and motivating the need for providing mecha- nisms facilitating their explicit definition. We also acknowledge that our results are subjected to a number of threats to validity. Regarding the internal validity, which refers to the inferences we have made, we relied on the data provided by the GitHub API. These data may not be complete and/or include toy projects ( e.g., projects addressing homework assignments). To minimize this threat, we analyzed the top repositories of each programming language. Regarding the external validity, our data was collected on January 22nd, 2025; and therefore our results should not be directly generalized to any project without proper comparison and validation. 10 Page 11: 4. Dimension of the diversity card This section provides a comprehensive overview of the various components of the Software Diversity Card, presenting a structured profile of the different groups iden- tified in Section 2. The card is organized into three main parts: the first part profiles the collection of teams involved in the software project, highlighting not only the developers but also non-coding contributors and testers; the second part outlines the usage context, detailing the intended target communities and any adaptations made for specific social groups; and finally, the last part describes the governance processes along with the relevant government bodies (such as funders and shareholders) that influence the project. Figure 1 provides an overview of the card’s structure. 4.1. Participants in software projects This part aims to profile the different types of participants behind developing and maintaining a software project. For each of these teams, and inspired by recent works in software diversity and inclusion [1, 2], the goal is to document a minimum set of demographic attributes such as age, perceived gender, ethnicity, location, and disabilities; and cultural characteristics of the team, such as the spoken language, the socio-economic status, the job title, the experience, and education level, among others. The clearest team behind a system is the development team . Several studies Software Diversity Card Participants Usage context Governance Development team Non-coding contributors Use cases Governance processes Testers and reporters Target communities Adaptations Bodies Figure 1: Overview of the Software Diversity Card. 11 Page 12: have studied how diverse teams are beneficial for the outcome of software systems, and this information would be valuable for end-users to trust in the software ( e.g., the case of the period tracker app), or for public regulators to ensure the app is developed in a certain region However, there are other types of teams involved in the development of soft- ware products that also play a pivotal role. Non-coding contributors have been recently noticed as relevant in the evolution and maintenance of open-source soft- ware projects [15]. For example, roles like the issue reporters are influential in the evolution of software projects. However, social groups less familiar with reporting issues may see their needs under-represented during the evolution of software sys- tems [37]. To this end, gathering diverse information about reporters could help companies avoid this kind of bias. On the other hand, translators, issue reporters anddocumenters are influential actors in creating the community around software projects and, in most cases, are in charge of reaching new layers of potential users. For instance, open-source commu- nities have been calling for translating contributions in order to make their software more accessible14 15. Besides, public reporting users or user feedback can also play a relevant role in evaluating a software product [37]. For example, in the video game in- dustry, public reporting users are a valuable asset for analyzing the success of a video game [51]. Despite this feedback being often considered the “voice of the users” [37], only a fraction of the software’s users indeed provide it. If the demographics of these users were not representative of the software target users, there may be a generated biased software evolution against these under-represented groups, similar to the case of issue reporters. On the other hand, public and controlled beta testing , along with crowd test- ing experiments , are frequently employed in software development to gather perti- nent feedback from potential users [14]. While in controlled public beta testing the users can be self-selected, in crowd-testing experiments groups of individuals are hired to test the software. The feedback gathered for these experiments will help product owners evaluate the software’s suitability. Still, it can also be helpful for end-users and public administration when assessing the adoption of new software. However, the quality of this feedback depends on many factors, such as the diver- sity of testers and specific instructions for the tasks to be performed. Other factors 14Drupal’s community call for documentation translators: https://www.drupal.org/ community/contributor-guide/contribution-areas/translations 15Open Stack’s community call for documentation translators: https://docs.openstack.org/ contributors/common/i18n.html 12 Page 13: include the time dedicated to test the software, the labour conditions, the app’s ma- turity level, and the number of iterations. These considerations have been identified in works in the machine learning field (such as Crowdworksheets [52]) and also in the Software Engineering field [53, 14]. 4.2. The usage context of the software To properly understand why a specific composition of actors is relevant, we need information about the social context where a system is intended to be used. Our proposal allows reporting the particular use cases the software is designed for and the social and cultural constraints that are applicable to these use cases. Following the example of the period tracker app, this app could be designed for young women living in Catalonia, a region of Spain with a specific co-official language (Catalan). This social context may generate the need to adapt the app’s user interface in Catalan and test the app on Catalan speakers to ensure it fits their needs. However, the usage context may vary depending on the app’s potential target users. For instance, a public administration or a product owner would require the app to be accessible for a particular social group ( e.g., people with disabilities, el- derly people, minority languages, neurodiverse people). In that sense, our proposal allows defining specific target populations (such as deaf people) and the particular adaptation of the app to reach those users ( e.g., videos with audio descriptions). Each adaptation could modify or require specific testing conditions, such as ensuring accessibility in the tester’s device. 4.3. The governance of the software project High-level information about the governance process and funders of the software products is also relevant for users to better understand the software such as the process followed to prioritize features or bug changes, or the criteria used to accept contributions. Moreover, this information is often hidden from the final users, and the recommendation to disclose it could help in creating a culture of better software practices. To this end, the goal of this part of the diversity card is to document infor- mation about the type of governance processes the project has ( e.g., private, corpo- ration, public, open community, research project), who are the main decision-makers and how decisions are made, the legal regulation the product is under, information about the funders of the project ( e.g., private, a public administration, or an NGO), and information about the shareholders. 13 Page 14: 5. Modeling diversity in software projects Our diversity card proposal aims to serve as a communication asset for software owners, end users, and public regulators. To promote its adoption and ensure con- sistent use, we need to provide structured resources and integrate them with existing process management tools in software development initiatives. In this section, we introduce a domain-specific language (DSL) designed for documenting software di- versity, along with a toolkit to assist in the creation of Software Diversity Cards for various user profiles. We believe that this formalization offers a common language that enables stakeholders involved in a software project to understand, communicate, and discuss diversity-related aspects effectively. In this section, we first present the abstract syntax of the DSL, which formalizes the concepts outlined in Section 4. Then, we introduce two different concrete syn- taxes, one tailored for users with coding skills, implemented as a language plugin for Visual Studio Code, and a second one oriented to non-coders based on a web-based tool that allows non-technical people to create cards easily. 5.1. Abstract syntax The metamodel is organized into packages that mimic the required dimensions of a Software Diversity Card (see Section 4). In the following, we present the elements of each package. 5.1.1. Participants In Figure 2, we show an excerpt of the metamodel that collects data about in- dividuals and the different groups engaged in a software development project. The main attributes collected in this model are inspired by recent works in software di- versity and inclusion [1, 2], as mentioned in previous sections. Individuals represent both team participants and other individual stakeholders in software projects. Individuals report their spokenLanguages (including their respective proficiency levels, based on the Common European Framework of Ref- erence for Languages16),ethnicity ,gender ,age,socioEconomicStatus (like the Kuppuswamy socioeconomic status class classification [54] and similar), skillLevel and tenure , among other information. On the other hand, Groups include homol- ogous data, but in aggregated format, i.e., a project reports an aggregated profile of the development team instead of the profile of each individual. In that sense, Groups represent the essential piece of our model, and Teams ,Organizations , and TargetCommunities are the specific types of Groups that compose the card. 16https://www.coe.int/en/web/common-european-framework-reference-languages 14 Page 15: Individual name: String age: Integer location: String workplaceType: WorkplaceType educationalLevel: EducationalLevel socioEconomicStatus: SESType skillLevel: SkillLevelType tenure: Double <<from ISO639>> Language name: String code: String Group name: String description: String startingAgeRange: Integer endingAgeRange: Integer locations: String[1..*] workplaceType: WorkplaceType educationalLevels: EducationalLevel[1..*] socioEconomicStati: SESType[1..*] skillLevels: SkillLevelType[1..*] averageTenure: Double Ethnicity name: String Gender name: String GroupSpokenLanguage proficiencies: LanguageLevel[1..*] SpokenLanguage proficiency: LanguageLevel Disability name: String SexualOrientation name: String Religion name: String <<from ISO3166>> Country shortName: String fullName: String alphaCode: String <<from ISO639>> Language name: String code: String 1..* * * * * * * * * * * * * * Team Organization * 1..* 0..1 * * * * * * * 0..1 * 0..1 * TargetCommunityFigure 2: Metamodel for collecting data about generic entities and individuals. In Figure 3, we can see an excerpt of the team hierarchies and its participants. As per their objectives and responsibilities, Teams are classified as: TesterTeams , PublicReporterTeams ,NonCodingContributorTeams , orDevelopmentTeams ; each of them containing specific information. Teams can be internal for the software project, or can be hired via a labour force. For instance, the TesterTeams can be hired via outsourcing services. In that case, Teams are classified as LabourForces . These include further details regarding contractual aspects, such as salary and labourRights (primarily according to the Country where the team is based in), and thecompany the team belongs to. Teams are integrated by Participants , who belong to a Team within a concrete date range, and exercise a particular role (e.g., reporter, developer or reviewer, among others). Those Participants who are affiliated to the organization responsi- ble for the development may inform their participantId (i.e., their internal business identifier; e.g., to enable them to access the organization’s owned systems). 15 Page 16: Team description: String startDate: DateTime endDate: DateTime[0..1] teamSize: Integer iterations: Integer * TesterTeam testType: TestType testersBackground: String testingGuidelines:String appMaturity: String PublicReporterTeam type: ReporterType reportingMethod: String reportingPlatform: String TeamParticipant role: RoleType endDate: DateTime[0..1] LabourForce salary: Double[0..1] labourRights: String[*] company: String Individual ... InternalParticipant participantId: String Date date: DateTime * * startDate <<from ISO3166>> Country shortName: String fullName: String alphaCode: String * 0..1 Participant NonCodingContributorTeam DevelopmentTeamFigure 3: Participants and teams hierarchies metamodel. 5.1.2. Usage context As mentioned in previous sections, software systems must consider its usage con- text, captured in Figure 4. In that sense, the SocialContext reflect the environment of social interactions, spokenLanguages , and culturalTraits where a software sys- tem is going to be exploited, in order to effectively address the users’ needs and nuances. The features of a system are built to respond to the different intended UseCases and their respective TargetCommunities or end users. For particular TargetCommunities who have specific needs or alternative, complementary require- ments, it may be necessary to make additional Adaptations delivered in a release . * * Adaptation description: String release: String Team ... SocialContext description: String culturalTraits: String[*] UseCase description: String * * * * * 0..1 * * spoken <<from ISO3166>> Country shortName: String fullName: String alphaCode: String <<from ISO639>> Language name: String code: String * * * * TargetCommunity 1 * Figure 4: Usage context metamodel. 16 Page 17: 5.1.3. Governance Governance is a key facet that influences diversity and inclusion in a project, mod- elled as in Figure 5. The Software Diversity Card may contain information in regard to the Bodies (e.g., the board of administrators) that govern the system construc- tion, which are composed of either individuals and/or organizations. Governance Rules in software development projects establish clear guidelines for collaboration between core and external contributors, ensuring they work effectively together to advance the project throughout its entire lifespan. Rules can be designed using the DSL from [55]. Governance projectType: ProjectType * * * * Individual ... * * * * Body type: BodyType * * Organization TargetCommunity <<from Governance>> Rule name: String appliedTo: CollaborationType stage: Stage queryFilter: String <<from Governance>> LeaderDriven <<from Governance>> PhasedRule <<from Governance>> Majority range: RangeType minVotes: Integer * 1 default * 1..* phases {ordered} Figure 5: Governance metamodel. 5.2. Tool support In this section, we lay out the details of a supporting toolkit that implements a concrete syntax of the DSL and provides transformations to JSON and Markdown formats. This allows any user to implement form-based or diagramming solutions to facilitate the design of software diversity cards, integrate such information within identity and management platforms, and document diversity aspects of a system in online platforms. 5.2.1. Textual concrete syntax We created a Visual Studio Code extension17that offers users an editor for completing software diversity cards. The concrete syntax is implemented using Langium18, an open-source tool for defining DSL grammars and enforcing well- formedness rules. The extension includes features such as syntax highlighting, syntax 17Extension home repository: https://github.com/SOM-Research/SoftwareDiversityCard 18Langium’s homepage: https://langium.org 17 Page 18: checking to ensure proper DSL instantiation, validation rules for model consistency, and autocomplete suggestions to simplify the association of entity instances. To fa- cilitate its accessibility, the extension has been published in the Visual Studio Code Marketplace19. Listing 2: Excerpt of the grammar implemented in Langium. 1grammar SoftwareDiversityCard 2 3entry Model : [...] 4 5SocialContext : ’ socialContext ’ name =ID 6 ’description :’ description = STRING 7 (’country :’ country = ISO3166 )? 8 (’ spokenLanguages :’ ’[’ ( spokenLanguages += ISO639 ) 9 (’,’ spokenLanguages += ISO639 )*’]’)? 10 (’useCases :’ ’[’ ( useCases +=[ UseCase :ID ]) 11 (’,’ useCases +=[ UseCase :ID ])*’]’)? 12 TeamsArray ; 13 14Adaptation : ’adaptation ’ name =ID 15 ’description :’ description = STRING 16 (’release :’ release = STRING )? 17 (’ targetCommunities :’ 18 ’[’( targetCommunities +=[ TargetCommunity :ID ]) 19 (’,’ targetCommunities +=[ TargetCommunity :ID ])*’]’)? 20 TeamsArray ; 21 22Participant : ’participant ’ name =ID 23 ’age :’ age = NUMBER 24 ’location :’ location =STRING , 25 [...] 26 (’ participantId :’ participantId = STRING )?; 27 28Team : ( TesterTeam | DevelopmentTeam | 29 NonCodingContributorTeam | PublicReporterTeam ); 30 31fragment TeamAttributes : name =ID Entity 32 ’description :’ description = STRING 33 ’startDate :’ startDate = DATE 34 (’teamSize :’ teamSize = NUMBER )? 35 [...] 19VSCode Marketplace page of the extension: https://marketplace.visualstudio.com/ items?itemName=SOMResearchGroup.SoftwareDiversityCard 18 Page 19: A snippet of the grammar is shown in Listing 2. For usability and maintainabil- ity reasons, we have designed all relationships as uni-directional. We have defined Langium “terminals” for all enumerations included in the DSL, as well as for the ISO codes of countries and languages ( i.e.,ISO3166 and ISO639 , respectively), to ease the introduction of such data. Inherited attributes from entities and teams are established as Langium “fragments” ( e.g.,TeamAttributes ), which allow a single definition of shared elements. An excerpt of a Software Diversity Card compiled using the extension is displayed in Figure 6 (left). Pair values are delimited by “(” and “)” ( e.g.,(English,c1) inorganization.spokenLanguages ); arrays are delimited by “[” and “]” ( e.g., organization.ethnicities ); and linked elements are referenced by their id. The Visual Studio Code extension provides capabilities for exporting software diversity cards to JSON and Markdown (MD) formats. The information contained in the JSON file could be processed to populate extended properties in directory services ( e.g., Active Directory, OpenLDAP and Google Cloud Identity) or identity and access management tools ( e.g., Azure AD and platforms compatible with SAML or OpenID Connect). On the other hand, the MD file could be included as part of the initiative documentation in online repositories such as GitHub. An example of JSON code is depicted in Figure 6 (right), following a typical block-based textual representation. Our plugin helps to simplify the creation of such a JSON description, and prevents manual errors such as introducing grammatical inconsistencies or missing required information. Figure 6: VSCode extension UI with a Software Diversity Card and the generated JSON output. 19 Page 20: 5.2.2. A form-based web tool for creating software diversity cards This section presents a web-based form tool to assist users in creating the cards, leveraging the previously introduced abstract syntax. Built with Streamlit20, the tool is open-source and published alongside the language plugin for Visual Studio. The tool is web-form-based, meaning that the concepts of the abstract syntax are translated into forms that the user should fill in to complete the tabs, and is focused on aiding non-technical users in card’s creation. Figure 7 shows an excerpt of the UI of the tool and an online demo has been published21. 20Streamlit project homepage: https://streamlit.io 21Online demo of the web editor: https://huggingface.co/spaces/JoanGiner/ SoftwareDiversityCard-Generator Figure 7: UI of the form-based web tool for creating software diversity cards. 20 Page 21: One of the main advantages of this form-based tool is that it guides the user about each of the fields available and their expected format. For instance, as we can see in the figure, in the governance part, the user can create as many bodies as they need, assign the type of body using an option selector, and define, if needed, basic demographic information for each body. Another advantage of this web-based tool, compared to the presented language plugin, is the smooth installation step, as this can be accessed directly from the web browser, which is ideally for non-coding users. However, although this tool should be the preferred one to start creating cards, it has some limitations that make using the language plugin more suitable for specific use cases. For instance, it is challenging to manage a large number of participants as the form could quickly get overwhelming for the users. The same happens with attributes with a lot of nested dimensions (such as defining the level of knowledge of a language of participants of the development team) that become difficult to manage using a web-based form. Finally, once the users have filled out the web form in the app, the tool generates an equivalent Markdown and JSON representation of the cards. So the users can download and share the generated files with the community or the relevant stakeholders of the project. 6. Examples In this section, we describe two mature open-source projects involving different groups of people using the proposed software diversity card. The two projects are Decidim [56], a participatory software used by over 400 administrations worldwide to allow citizens to participate in public decisions, and Besser [57], a low-code platform designed to enable non-coding profiles to develop software applications in various domains which one of the authors of this work is directly involved. Despite their distinct characteristics, such as target users, both projects are open-source, publicly funded, and part of a user community. As a first step in describing the projects, we reviewed the online documentation of each project and attempted to complete the cards as much as possible. Then, we interviewed the project’s development and product teams, presenting our proposal and asking about the card’s dimensions. This section summarizes the key points of each project’s card and discusses the challenges we and the software projects encountered in gathering the required card dimensions. The complete examples of the cards are available online22. 22The card’s examples are in the /examples folder of the tools repository: https://github.com/ SOM-Research/SoftwareDiversityCard 21 Page 22: 6.1. Decidim: an open-source participatory democracy platform Decidim is an open-source platform that fosters participatory democracy and involves different groups participants . The platform’s development team comprises maintainers, developers, and external contributor teams focused on specific features. Despite the extensive project documentation and clear commitment to transparency, we have found that the developers’ profiles were not publicly disclosed. During the interview with Decidim, we learned that Decidim is composed of internal and external developer teams. In that sense, they pointed out that the external teams change over time, making it difficult for them to publish a long-standing team’s profile information. The description of the current state of the Decidim development team can be seen in the online example of the Decidim Cards. Decidim has a community of non-coding contributors who report bugs, propose features, and translate the software via its own online social platform, Metadecidim23. However, following the approach of many open-source communities, they adopted the “anonymity first” principle, where any user contribution only needs to be associated with a user name. While this approach is intended to avoid bias and promote equal participation, it is hard for them to profile the community of non-coder contributors. In that sense, we have been able to profile the size, number of contributions, and its expertise in the reporting platforms of both teams, that can be seen in the complete example published online. Regarding testers and public reporters , they did several usability tests and pub- lic interviews with citizens in several participatory processes they drive. However, none of these studies have been made public or reported in the extensive project’s documentation. They noted that this is a path of improvement for the project, as disclosing this information may help, for instance, in the Decidim’s adoption by other institutions. However, they pointed to some limitations regarding this issue, such as the lack of UI/UX experts to build systematic tests and standard guidelines to disclose this information in open-source projects. Regarding the usage context , Decidim has been adapted to multiple linguistic and regional contexts, with translations into over 60 languages, accessibility features for people with disabilities, and initiatives to bridge the digital divide by integrating users with low digital skills. To support these users, the platform facilitates in-person events for public decisions and introduces “managed users”, enabling participation through volunteer assistance. In Listing 3 we can see en excerpt of the usage context of the Decidim diversity card, where we have been able to capture the two adaptation DigitalDivide andlanguageAdaptation and to profile the target community of the 23Metadecidim home page: https://meta.decidim.org 22 Page 23: Listing 3: Excerpt of the usage context part of the Decidim’s Card 1targetCommunity nonDigitalSkilled 2description: "Elder citizen or citizen with low digital skills..." 3ageRange: (60, 100) 4locations: ["Barcelona"] 5workplaceType: presential 6countries: [Spain] 7educationalLevels: [shortCycleTertiary, primary, earlyChildhood] 8spokenLanguages: [(Catalan-Valencian, b1), (Spanish-Castilian, b1)...] 9socioEconomicStati: [lowerClass, lowerMiddleClass] 10 skillLevels: [beginner] 11 12targetCommunity barcelonaCitizens [...] 13 14adaptation DigitalDivide 15description: "Training and Mediation Against the Digital Divide. Adaptations for bridging the gap of digital devices. Decidim has released..." 16targetCommunities: [nonDigitalSkilled] 17 18adaptation languageAdaptation 19description: "The cities where Decidim is deployed contain a broad variety of spoken languages. Along with a community of volunteers..." 20targetCommunities: [barcelonaCitizens] 21relatedTeams: [Translators] DigitalDivide adaptation defining the age range, location, educational and skill levels, and spoken languages. They have also conducted several accessibility audits to adapt the software for people with disabilities. However, while various governments have conducted these audits, the results remain unpublished. During the interview, they commented that one of the reasons this information is not published is the lack of resources and clear guidance on how to publish these results, which are sometimes hard for final users to understand as one of the reasons. However, they agree that pointing to the results of audits would be useful for other governments willing to adopt Decidim in their participatory processes. Thegovernance of Decidim is based on public and democratic processes, and the board-elected members can be consulted online. Facing issues similar to those of the non-coding platform, the information needed to generate aggregated profiles is scarce as the users only need to be linked to a username. The funding is based on a mix of public administrations and crowd-sourcing platforms where individuals and 23 Page 24: organizations make donations. The Decidim governance profile can be seen in the online Decidim card. 6.2. Besser: a low-code platform for smart software development Besser is a low-code platform that allows non-coding developers to develop domain- specific applications. It is maintained and developed by a community of participants ; for instance, the development team is composed of 15 developers from 9 nationalities, where French, English, and Spanish are the running languages, and the educational level is balanced between undergraduates and doctoral degree holders in computer science. While this information is partially public on the project website, one of the authors of this work is directly involved in developing this software, so we had direct access to the development team and the information required. Still, we needed to gather the geographic distribution, the running languages, and the education level from the interviews with the project managers. In Listing 4 we can see the different attributes captured in the Besser diversity card. The project has an emerging community of non-coding roles around those who report bugs. This community interacts around the project’s open repository via issues and pull requests and less frequently through direct contacts or social networks. When asking for an aggregated profile, they faced challenges similar to those faced by Decidim in profiling this community, as the contributions are just associated with a username. Another similar point to Decidim is that they conducted a set of usability studies as part of the framework, but these have not been published. They realized the relevance of publishing this data in our conversation and shared with us the aggregated profiles that can be viewed in the complete example of the card. Regarding the usage context , the adaptations are one of the key elements of Besser, as it is a low-code platform intended to help users develop domain-specific software. In that sense, the software presents a set of domain adaptations identifying a target user for each domain. For instance, they created an extension of Besser to allow public servants and researchers to create visualization panels for climate data; on the other hand, they adapted Besser for scholars, focusing on teachers and students in computer science, and an ongoing project involves adapting Besser to telecommunications engineers to model the deployment of 6G networks. Finally, regarding governance , Besser is a public-funded project funded by the FNR Pearl grant led by the Luxembourg Institute of Science and Technology. The principal investigator is the grant recipient and acts as a project director (unlike Decidim, which is governed by a board of directors). Besser’s governance profile can be seen in Besser’s online published card. 24 Page 25: Listing 4: Excerpt of the development team part of the Besser’s Card 1developmentTeam DevelopmentTeam 2 description: "The Besser development team is composed of 15 developers, based in Luxembourg, from 11 different ethnic groups." 3 startDate: 11-08-2022 4 teamSize: 15 5 ageRange: (25, 36) 6 locations: ["Luxembourg Institute of Technology, Luxembourg"] 7 workplaceType: presential 8 ethnicities: 9 ["Colombian", "Brasilian", "Argentinian", "French", "Spanish", 10 "Pakistani", "Serbian", "Iranian", "Moroccan", "Italian"] 11 genders: ["male 80%","female 20%","non-binary 0%"] 12 religiousBeliefs: ["Christianism","Islam"] 13 countries: [Luxembourg] 14 educationalLevels: [masterEquivalent, doctorateEquivalent] 15 spokenLanguages: [(English, c1)] 16 averageTenure: 3.3 7. Conclusions In this work, we reviewed the increasing concerns within the research field regard- ing diversity in software projects. These concerns pertain not only to the develop- ment team but also to a broader definition of participants, which includes non-coding roles, testers, and intended end-users. Despite the growing awareness of diversity in the research community, our analysis of 1,000 popular open-source software (OSS) projects revealed a significant lack of reported diversity information. To address this issue, we proposed the Software Diversity Card as an integrated approach to report diversity-related aspects within this broader definition of partic- ipation. Our proposal aims to serve as a communication tool for software owners, users, and public regulators. To facilitate its adoption, we have also formalized a domain-specific language (DSL) along with a toolkit to assist in creating the card. This formalization provides a common language that enables stakeholders involved in a software project to understand, communicate, and discuss diversity-related aspects effectively. Our proposal represents an initial effort to acknowledge diversity as a crucial element in software projects. However, there are still challenges to address and future directions to explore in this area. In the remainder of this section, we will outline some of the challenges we faced during the description of Decidim and Besser and propose future research avenues focused on reporting diversity-related aspects. 25 Page 26: 7.1. Challenges Anonymity : One of the main limitations we faced while creating the Decidim and Besser card was anonymity. While crucial for reducing biases, anonymity in open-source communities poses significant challenges in profiling contributors. In the case of Decidim, the ”anonymity first” principle helps prevent discrimination against specific groups but complicates the process of analyzing the non-coding contributor’s teams, such as the translators or the reporters of the software. This approach limits the ability to conduct a post-analysis of the community’s composition, making it harder to effectively understand and support the broader user base. Sensitive information : Related to anonymity, another clear challenge is the pres- ence, in the software diversity card, of sensitive information about a project’s devel- opers, contributors, and users, including details such as racial or ethnic background, age, gender, and sexual orientation. While this information is generally provided in aggregate form, in smaller software projects, even aggregate data can potentially be used to infer details about individuals. This raises several privacy concerns for the software diversity card. For instance, surveys that collect sensitive information from individuals must include informed consent , clearly stating what data is being collected and how it will be used. On the other hand, if the population size or characteristics of the data allow for individual attribution of traits, such information should not be included in the software diversity card. Authenticity: The software diversity card is a self-assessment report and, as such, it assumes goodwill on the part of the authors in terms of its authenticity. Nevertheless, the creators of a diversity card may have strong incentives to misrepresent the level of diversity in a software project, e.g., to attract more talent, to access funding from public organizations or specific communities, to gain publicity or public support, or to strengthen its participation in competitive calls. Thus, it is important to emphasize that the purpose of the software diversity card is to improve community diversity practices in software development. Such a goal can only be achieved if the information presented in diversity cards is accurate. Evolving nature of projects: One of the challenges during the creation of De- cidim’s card has been the evolving nature of the development team. The team com- prises internal and external teams, which could easily change shortly. They pointed out that this situation makes disclosing the team’s long-standing profile information difficult. The same problem could happen when new tests are done with users, or the evolution of the reporting community. So, the inherent evolving nature of the project forces us to frequently reanalyze the card, which can be helpful to determine whether the project is improving or worsening in terms of diversity and inclusion. 26 Page 27: 7.2. Future work In this section, we outline several directions for future research and development in reporting diversity-related aspects of software projects: Integrating diversity tracking to specific development process tasks: Right now we model the diversity of a project as a whole but we could follow a more fine- grained approach where diversity is also tracked at task level for deeper insights. For example, we could analyze whether a project has a diverse team but some tasks are only targeted by some team members, resulting in a low diverse approach for them (such as the project managers being mainly men). To generate these insights, it is essential to integrate Software Diversity Cards with software process definition tools and languages, such as SPEM24. Formally verifying software compliance with diversity requirements: Pub- lic administrations can utilize the Software Diversity Card to assess which software artefacts meet their mandatory diversity requirements. Since the Software Diversity Card is precisely specified, query languages like OCL [58] can be employed to assist and automate this compliance-checking process. Enhancing the diversity card with environmental information: Alongside diversity, there is a growing concern regarding the environmental aspects of software development. For instance, in the machine learning (ML) field, transparency about the environmental impact of AI training has become a significant topic. Initiatives like MyGreenLabel25provide insights into the carbon footprint of trained ML mod- els. Incorporating this environmental information into the Software Diversity Card framework could further contribute to the creation of ”Responsible Software.” Ex- ploring methods to integrate and balance these two types of information would be a fruitful avenue for research. Bridging the gap between diversity and Responsible AI documentation: Machine learning applications are software systems often integrated into larger tra- ditional software frameworks. Therefore, documentation assets for ML, such as Data Cards [12], can be viewed as a subset of the software diversity card. By documenting diversity factors related to the development team and beta testing population, we can also capture diversity aspects involved in designing and training ML models within these systems. In addition, several efforts have been made to translate these RAI data documentation frameworks to machine-readable formats, mainly to enhance their processing and discovery. Building mapping and translation between the soft- 24SPEM specification homepage: https://www.omg.org/spec/SPEM/2.0/About-SPEM 25MyGreenLabel homepage: https://act.mygreenlab.org 27 Page 28: ware diversity card to data machine-readable vocabularies, such as DescribeML [59] and Croissant [13] could also enhance the discoverability of diversity aspects on the web. AI agents as biased actors: AI agents are becoming increasingly important in software projects. It is essential to consider the biases present in these models, as they can impact the diversity of the entire software project. Several works in the software engineering (SE) and machine learning (ML) communities have started to identify and address these biases. Looking ahead, there is a need to incorporate this information into the software diversity card. Empirical evaluation of the software diversity card’s impact: While the software diversity card provides a structured approach to documenting diversity, its future impact on software projects will need to be systematically assessed. Future work should explore its influence on inclusion through case studies in open-source and private projects, analyzing metrics such as participation of underrepresented groups, diversity perceptions in OSS communities, and improvements in accessibility. These studies should point in two directions, whether the diversity card approach is adopted by OSS projects (for instance, by performing longitudinal studies on GitHub) and other institutions, like public administration in the call for tenders, and whether the projects that adopt it see some positive impact from it. Acknowledgements Joan Giner-Miguelez acknowledges his AI4S fellowship within the “Generaci´ on D” initiative by Red.es, Ministerio para la Transformaci´ on Digital y de la Funci´ on P´ ublica, for talent attraction (C005/24-ED CV1), funded by NextGenerationEU through PRTR. This work is part of the projects TED2021-130331B-I00 and PID2023- 147592OB-I00, and the research network RED2022-134647-T, all funded by MCIN/ AEI/10.13039/501100011033 and the Luxembourg National Research Fund (FNR) PEARL program, grant agreement 16544475. References [1] P. Bjørn, M. Menendez-Blanco, V. Borsotti, Diversity in computer science: De- sign artefacts for equity and inclusion, Springer Nature, 2023. [2] K. Albusays, P. Bjorn, L. Dabbish, D. Ford, E. Murphy-Hill, A. Serebrenik, M.- A. Storey, The diversity crisis in software development, IEEE Software 38 (2) (2021) 19–25. 28 Page 29: [3] Y. Yang, T. Y. Tian, T. K. Woodruff, B. F. Jones, B. Uzzi, Gender-diverse teams produce more novel and higher-impact scientific ideas, Proceedings of the National Academy of Sciences 119 (36) (2022) e2200841119. [4] B. Vasilescu, D. Posnett, B. Ray, M. G. van den Brand, A. Serebrenik, P. De- vanbu, V. Filkov, Gender and tenure diversity in github teams, in: Proceedings of the 33rd annual ACM conference on human factors in computing systems, 2015, pp. 3789–3798. [5] H. Gunatilake, J. Grundy, R. Hoda, I. Mueller, The impact of human aspects on the interactions between software developers and end-users in software engi- neering: A systematic literature review, Information and Software Technology 173 (2024) 107489. [6] S. M. Hyrynsalmi, S. Baltes, C. Brown, R. Prikladnicki, G. Rodriguez-Perez, A. Serebrenik, J. Simmonds, B. Trinkenreich, Y. Wang, G. Liebel, Making soft- ware development more diverse and inclusive: Key themes, challenges, and fu- ture directions, ACM Transactions on Software Engineering and Methodology (2024). [7] T. Oliveira, A. Barcomb, R. D. S. Santos, H. Barros, M. T. Baldassarre, C. Fran¸ ca, Navigating the path of women in software engineering: From academia to industry, in: Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society, 2024, pp. 154–165. [8] X. Zhao, N. Tsuboi, Early career software developers-are you sinking or swim- ming?, in: Proceedings of the 46th International Conference on Software Engi- neering: Software Engineering in Society, 2024, pp. 166–176. [9] J. Wang, Y. Yang, S. Wang, J. Hu, Q. Wang, Context-and fairness-aware in- process crowdworker recommendation, ACM Transactions on Software Engi- neering and Methodology (TOSEM) 31 (3) (2022) 1–31. [10] T. Kanij, M. Anwar, G. Oliver, M. K. Hossain, Developing software for low socio- economic end users: Lessons learned from a case study of fisherfolk communities in bangladesh, in: 2023 IEEE/ACM 45th International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS), IEEE, 2023, pp. 96–107. [11] T. Gebru, J. Morgenstern, B. Vecchione, J. W. Vaughan, H. Wallach, H. D. Iii, K. Crawford, Datasheets for datasets, Communications of the ACM 64 (12) (2021) 86–92. 29 Page 30: [12] M. Pushkarna, A. Zaldivar, O. Kjartansson, Data cards: Purposeful and trans- parent dataset documentation for responsible AI, in: Proceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency, 2022, pp. 1776–1826. [13] M. Akhtar, O. Benjelloun, C. Conforti, L. Foschini, J. Giner-Miguelez, P. Gijs- bers, S. Goswami, N. Jain, M. Karamousadakis, M. Kuchnik, et al., Croissant: A metadata format for ml-ready datasets, Advances in Neural Information Pro- cessing Systems 37 (2025) 82133–82148. [14] N. Leicht, I. Blohm, J. M. Leimeister, Leveraging the power of the crowd for software testing, IEEE Software 34 (2) (2017) 62–69. [15] J. L. C´ anovas Izquierdo, J. Cabot, On the analysis of non-coding roles in open source development: An empirical study of npm package projects, Empirical Software Engineering 27 (1) (2022) 18. [16] T. Bi, X. Xia, D. Lo, J. Grundy, T. Zimmermann, D. Ford, Accessibility in software practice: A practitioner’s perspective, ACM Transactions on Software Engineering and Methodology (TOSEM) 31 (4) (2022) 1–26. [17] O. Elazhary, M.-A. Storey, N. Ernst, A. Zaidman, Do as i do, not as i say: Do contribution guidelines match the github contribution process?, in: 2019 IEEE International Conference on Software Maintenance and Evolution (IC- SME), IEEE, 2019, pp. 286–290. [18] P. Tourani, B. Adams, A. Serebrenik, Code of conduct in open source projects, in: 2017 IEEE 24th international conference on software analysis, evolution and reengineering (SANER), IEEE, 2017, pp. 24–33. [19] J. Canovas Izquierdo, J. Cabot, For a more transparent governance of open source seeking the best governance models for foss projects, Communications of the ACM, 2023, 66 (8), 32-34. (2023). [20] A. M. Smith, D. S. Katz, K. E. Niemeyer, Software citation principles, PeerJ Computer Science 2 (2016) e86. [21] R. Dutta, D. E. Costa, E. Shihab, T. Tajmel, Diversity awareness in software engineering participant research, in: 2023 IEEE/ACM 45th International Con- ference on Software Engineering: Software Engineering in Society (ICSE-SEIS), IEEE, 2023, pp. 120–131. 30 Page 31: [22] A. Bosu, K. Z. Sultana, Diversity and inclusion in open source software (oss) projects: Where do we stand?, in: 2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), IEEE, 2019, pp. 1–11. [23] A. R. Gila, J. Jaafa, M. Omar, M. Z. Tunio, Impact of personality and gender diversity on software development teams’ performance, in: 2014 International Conference on Computer, Communications, and Control Technology (I4CT), 2014, pp. 261–265. [24] L. Dowler, Diverse teams can improve engineering outcomes-but recent affirmative action decision may hinder efforts to create diverse teams, The Con- versation. https://theconversation. com/diverse-teams-canimprove-engineering- outcomes-but-recent-affirmative-action-decision-may-hinder-efforts-to-create- diverseteams-209357 (2023). [25] R. Nadri, G. Rodriguez-Perez, M. Nagappan, Insights into nonmerged pull re- quests in github: Is there evidence of bias based on perceptible race?, IEEE Softw. 38 (2) (2021) 51–57. [26] L. B. Furtado, B. Cartaxo, C. Treude, G. Pinto, How successful are open source contributions from countries with different levels of human development?, IEEE Software 38 (2) (2020) 58–63. [27] A. M. d. Silva, S. C. B. Sampaio, M. L. Marinho, Using software engineering and agile methods to improve inclusion and team diversity, in: Proceedings of the XIX Brazilian Symposium on Software Quality, SBQS ’20, Association for Computing Machinery, New York, NY, USA, 2021. [28] G. Liebel, N. Langlois, K. Gama, Challenges, strengths, and strategies of soft- ware engineers with adhd: A case study, in: Proceedings of the 46th Interna- tional Conference on Software Engineering: Software Engineering in Society, 2024, pp. 57–68. [29] G. A. A. Prana, D. Ford, A. Rastogi, D. Lo, R. Purandare, N. Nagappan, Including everyone, everywhere: Understanding opportunities and challenges of geographic gender-inclusion in oss, IEEE Transactions on Software Engineering 48 (9) (2021) 3394–3409. 31 Page 32: [30] C. Miller, S. Cohen, D. Klug, B. Vasilescu, C. KaUstner, ” did you miss my comment or what?” understanding toxicity in open source discussions, in: Pro- ceedings of the 44th International Conference on Software Engineering, 2022, pp. 710–722. [31] R. Paul, A. Bosu, K. Z. Sultana, Expressions of sentiments during code reviews: Male vs. female, in: 2019 IEEE 26th International Conference on Software Anal- ysis, Evolution and Reengineering (SANER), IEEE, 2019, pp. 26–37. [32] E. Zolduoarrati, S. A. Licorish, On the value of encouraging gender tolerance and inclusiveness in software engineering communities, Information and Software Technology 139 (2021) 106667. [33] G. Liebel, J. Kl¨ under, R. Hebig, C. Lazik, I. Nunes, I. Graßl, J.-P. Stegh¨ ofer, J. Exelmans, J. Oertel, K. Marquardt, et al., Human factors in model-driven engineering: future research goals and initiatives for mde, Software and Systems Modeling 23 (4) (2024) 801–819. [34] J. Grundy, I. Mueller, A. Madugalla, H. Khalajzadeh, H. O. Obie, J. McIntosh, T. Kanij, Addressing the influence of end user human aspects on software en- gineering, in: International Conference on Evaluation of Novel Approaches to Software Engineering, Springer, 2021, pp. 241–264. [35] H. Khalajzadeh, M. Shahin, H. O. Obie, J. Grundy, How are diverse end- user human-centric issues discussed on github?, in: Proceedings of the 2022 ACM/IEEE 44th International Conference on Software Engineering: Software Engineering in Society, 2022, pp. 79–89. [36] H. Khalajzadeh, M. Shahin, H. O. Obie, P. Agrawal, J. Grundy, Supporting de- velopers in addressing human-centric issues in mobile apps, IEEE Transactions on Software Engineering 49 (4) (2022) 2149–2168. [37] J. Tizard, T. Rietz, K. Blincoe, Voice of the users: A demographic study of software feedback behaviour, in: 2020 IEEE 28th International Requirements Engineering Conference (RE), IEEE, 2020, pp. 55–65. [38] F. Hou, L. Feng, S. Farshidi, S. Jansen, Evaluating software quality through user reviews: The isoftsentiment tool, in: International Conference on Product- Focused Software Process Improvement, Springer, 2024, pp. 75–91. 32 Page 33: [39] M. H. Miraz, M. Ali, P. S. Excell, Adaptive user interfaces and universal usability through plasticity of user interface design, Computer Science Review 40 (2021) 100363. [40] W. Wang, H. Khalajzadeh, J. Grundy, A. Madugalla, H. O. Obie, Adaptive user interfaces for software supporting chronic disease, in: Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society, 2024, pp. 118–129. [41] W. Wang, H. Khalajzadeh, J. Grundy, A. Madugalla, H. O. Obie, Adaptive user interfaces for software supporting chronic disease, in: 2024 IEEE/ACM 46th International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS), 2024, pp. 118–129. [42] J. Wang, S. Wang, J. Chen, T. Menzies, Q. Cui, M. Xie, Q. Wang, Characteriz- ing crowds to better optimize worker recommendation in crowdsourced testing, IEEE Transactions on Software Engineering 47 (6) (2019) 1259–1276. [43] E. M. Bender, B. Friedman, Data statements for natural language processing: Toward mitigating system bias and enabling better science, Transactions of the Association for Computational Linguistics 6 (2018) 587–604. [44] J. C´ anovas Izquierdo, J. Cabot, For a more transparent governance of open source, Communications of the ACM 66 (8) (2023) 32–34. [45] D. Carneros-Prado, L. Villa, E. Johnson, C. C. Dobrescu, A. Barrag´ an, B. Garc´ ıa-Mart´ ınez, Comparative study of large language models as emotion and sentiment analysis systems: A case-specific analysis of GPT vs. IBM wat- son, in: Int. Conf. on Ubiquitous Computing & Ambient Intelligence, 2023, pp. 229–239. [46] V. Tran, T. Matsui, Improving LLM prompting with ensemble of instructions: A case study on sentiment analysis, in: Int. Symp. on New Frontiers in Artificial Intelligence, Vol. 14741, 2024, pp. 299–305. [47] J. Deng, F. Ren, A survey of textual emotion recognition and its challenges, IEEE Transactions on Affective Computing 14 (1) (2023) 49–67. [48] X. Sun, X. Li, J. Li, F. Wu, S. Guo, T. Zhang, G. Wang, Text classification via large language models, in: Findings of the Association for Computational Linguistics: EMNLP 2023, Association for Computational Linguistics, 2023, pp. 8990–9005. 33 Page 34: [49] F. Nadi, H. Naghavipour, T. Mehmood, A. B. Azman, J. A. Nagantheran, K. S. K. Ting, N. M. I. B. N. Adnan, R. A. Sivarajan, S. A. Veerah, R. F. Rahmat, Sentiment analysis using large language models: A case study of GPT- 3.5, in: Data Science and Emerging Technologies, 2023, pp. 161–168. [50] S. Cobos, J. C´ anovas Izquierdo, Sentiment analysis using large language models: A case study of GPT-3.5, in: Int. Conf. on Software Engineering, Software Engineering in Society track, 2025, p. to appear. [51] Y. Yu, D.-T. Dinh, B.-H. Nguyen, F. Yu, V.-N. Huynh, Mining insights from esports game reviews with an aspect-based sentiment analysis framework, IEEE Access 11 (2023) 61161–61172. [52] M. D´ ıaz, I. Kivlichan, R. Rosen, D. Baker, R. Amironesei, V. Prabhakaran, E. Denton, Crowdworksheets: Accounting for individual and collective identities underlying crowdsourced dataset annotation, in: Proceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency, 2022, pp. 2342–2351. [53] W.-T. Tsai, L. Zhang, S. Hu, Z. Fan, Q. Wang, Crowdtesting practices and mod- els: An empirical approach, Information and Software Technology 154 (2023) 107103. [54] R. Lakhumna, P. D. Pore, S. K. Wadhwa, Socio-economic status scales in india & globally: A review, Preventive Medicine: Research & Reviews 2 (1) (2025) 40–48. [55] J. C´ anovas Izquierdo, J. Cabot, Enabling the definition and enforcement of governance rules in open source systems, in: 2015 IEEE/ACM 37th IEEE In- ternational Conference on Software Engineering, Vol. 2, 2015, pp. 505–514. [56] P. Arag´ on, A. Kaltenbrunner, A. Calleja-L´ opez, A. Pereira, A. Monterde, X. E. Barandiaran, V. G´ omez, Deliberative platform design: The case study of the online discussions in decidim barcelona, in: Social Informatics: 9th International Conference, SocInfo 2017, Oxford, UK, September 13-15, 2017, Proceedings, Part II 9, Springer, 2017, pp. 277–287. [57] I. Alfonso, A. Conrardy, A. Sulejmani, A. Nirumand, F. Ul Haq, M. Gomez- Vazquez, J.-S. Sottet, J. Cabot, Building BESSER: an open-source low-code platform, in: International Conference on Business Process Modeling, Develop- ment and Support, Springer, 2024, pp. 203–212. 34 Page 35: [58] J. Cabot, M. Gogolla, Object constraint language (OCL): A definitive guide, in: M. Bernardo, V. Cortellessa, A. Pierantonio (Eds.), Formal Methods for Model-Driven Engineering - 12th International School on Formal Methods for the Design of Computer, Communication, and Software Systems, SFM 2012, Bertinoro, Italy, June 18-23, 2012. Advanced Lectures, Vol. 7320 of Lecture Notes in Computer Science, Springer, 2012, pp. 58–90. [59] J. Giner-Miguelez, A. G´ omez, J. Cabot, A domain-specific language for de- scribing machine learning datasets, Journal of Computer Languages 76 (2023) 101209. 35

Knowledge Feed

AI related knowledge resources

AI Agents

AI Agents

Symbolic Mixture-of-Experts: Adaptive Skill-bas...

Transformers without Normalization

Task Adaptation of Reinforcement Learning-based...

AI Agents
Large Language Models

Large Language Models

On Fairness of Unified Multimodal Large Languag...

Evaluating open-source Large Language Models fo...

Charting and Navigating Hugging Face's Model Atlas

LLM
Machine Learning

Machine Learning

Grassmannian Geometry Meets Dynamic Mode Decomp...

Adaptive Retrieval Without Self-Knowledge? Brin...

Unveiling the Mathematical Reasoning in DeepSee...

Machine Learning
AI Code

AI Code

"Silent Is Not Actually Silent": An Investigati...

KnowPath: Knowledge-enhanced Reasoning via LLM-...

Scalable Memory Recycling for Large Quantum Programs

AI Code
Prompt Engineering

Prompt Engineering

DynaCode: A Dynamic Complexity-Aware Code Bench...

Probing LLMs for Multilingual Discourse General...

Transformers without Normalization

Prompt Engineering

AI Feed

---

© 2025, Copyrights Open AGI Codes. All Rights Reserved, Built with Transforming Tomorrow, One Algorithm at a Time: The AI Revolution, on Pyramid by Pylons Project