Responsible AI (RAI) tools—checklists, templates, and governance processes—often engage RAI champions, individuals intrinsically motivated to advocate ethical practices, but fail to reach non-champions, who frequently dismiss them as bureaucratic tasks. To explore this gap, we shadowed meetings and interviewed data scientists at an organization, finding that practitioners perceived RAI as irrelevant to their work. Building on these insights and theoretical foundations, we derived design principles for engaging non-champions, and introduced sticky stories—narratives of unexpected ML harms designed to be concrete, severe, surprising, diverse, and relevant, unlike widely circulated media to which practitioners are desensitized. Using a compound AI system, we generated and evaluated sticky stories through human and LLM assessments at scale, confirming they embodied the intended qualities. In a study with 29 practitioners, we found that, compared to regular stories, sticky stories significantly increased the engagement time on harm identification, broadened the range of harms recognized, and fostered deeper reflection.

Machine learning (ML) components are increasingly incorporated into software products for end-users, but developers face challenges in transitioning from ML prototypes to products. Academics have limited access to the source of commercial ML products, hindering research progress to address these challenges. In this study, first and foremost, we contribute a dataset of 262 open-source ML products for end users (not just models), identified among more than half a million ML-related projects on GitHub. Then, we qualitatively and quantitatively analyze 30 open-source ML products to answer six broad research questions about development practices and system architecture. We find that the majority of the ML products in our sample represent more startup-style development than reported in past interview studies. We report 21 findings, including limited involvement of data scientists in many open-source ML products, unusually low modularity between ML and non-ML code, diverse architectural choices on incorporating models into products, and limited prevalence of industry best practices such as model testing, pipeline automation, and monitoring. Additionally, we discuss seven implications of this study on research, development, and education, including the need for tools to assist teams without data scientists, education opportunities, and open-source-specific research for privacy-preserving telemetry.

One of the major challenges in the use of opaque, complex AI models is the need or desire to provide an explanation to the end-user (and other stakeholders) as to how the system arrived at the answer it did. While there is significant research in the development of explainability techniques for AI, the question remains as to who needs an explanation, what an explanation consists of, and how to communicate this to a lay user who lacks direct expertise in the area. In this position paper, an interdisciplinary team of researchers argue that the example of clinical communications offers lessons to those interested in improving the transparency and interpretability of AI systems. We identify five lessons from clinical communications: (1) offering explanations for AI systems and disclosure of their use recognizes the dignity of those using and impacted by it; (2) AI explanations can be productively targeted rather than totally comprehensive; (3) AI explanations can be enforced through codified rules but also norms, guided by core values; (4) what constitutes a “good” AI explanation will require repeated updating due to changes in technology and social expectations; 5) AI explanations will have impacts beyond defining any one AI system, shaping and being shaped by broader perceptions of AI. We review the history, debates and consequences surrounding the institutionalization of one type of clinical communication, informed consent, in order to illustrate the challenges and opportunities that may await attempts to offer explanations of opaque AI models. We highlight takeaways and implications for computer scientists and policymakers in the context of growing concerns and moves toward AI governance.

Incorporating machine learning (ML) components into software products raises new software-engineering challenges and exacerbates existing ones. Many researchers have invested significant effort in understanding the challenges of industry practitioners working on building products with ML components, through interviews and surveys with practitioners. With the intention to aggregate and present their collective findings, we conduct a meta-summary study: We collect 50 relevant papers that together interacted with over 4758 practitioners using guidelines for systematic literature reviews. We then collected, grouped, and organized the over 500 mentions of challenges within those papers. We highlight the most commonly reported challenges and hope this meta-summary will be a useful resource for the research community to prioritize research and education in this field.

The documentation practice for machine-learned (ML) models often falls short of established practices for traditional software, which impedes model accountability and inadvertently abets inappropriate or misuse of models. Recently, model cards, a proposal for model documentation, have attracted notable attention, but their impact on the actual practice is unclear. In this work, we systematically study the model documentation in the field and investigate how to encourage more responsible and accountable documentation practice. Our analysis of publicly available model cards reveals a substantial gap between the proposal and the practice. We then design a tool named DocML aiming to (1) nudge the data scientists to comply with the model cards proposal during the model development, especially the sections related to ethics, and (2) assess and manage the documentation quality. A lab study reveals the benefit of our tool towards long-term documentation quality and accountability.

The introduction of machine learning (ML) components in software projects has created the need for software engineers to collaborate with data scientists and other specialists. While collaboration can always be challenging, ML introduces additional challenges with its exploratory model development process, additional skills and knowledge needed, difficulties testing ML systems, need for continuous evolution and monitoring, and non-traditional quality requirements such as fairness and explainability. Through interviews with 45 practitioners from 28 organizations, we identified key collaboration challenges that teams face when building and deploying ML systems into production. We report on common collaboration points in the development of production ML systems for requirements, data, and integration, as well as corresponding team patterns and challenges. We find that most of these challenges center around communication, documentation, engineering, and process, and collect recommendations to address these challenges.

Move Method Refactoring (MMR) is used to place highly coupled methods in appropriate classes for making source code more cohesive. Like other refactoring techniques, it is mandatory that applying MMR will preserve applications’ behaviors. However, traditional MMR techniques failed to meet this essential precondition for Action methods in web-based application and API methods in libraries projects. The reason is that applying MMR on these methods changes the behaviors of the projects by raising Application-breaking issues, for instance, failure of browser requests and compilation errors in client projects. To resolve this problem, developers are suggested to manually check Action and API methods while applying MMR. However, manually inspecting thousands of lines of code for these issues is a time-consuming and hectic task. In this paper, an advanced MMR technique is proposed which automatically identifies Application-breaking MMR suggestions. This technique first takes the initial move method suggestions from the existing prominent MMR techniques e.g. JDeodorant. For each of the suggestions, it parses the source code and construct Abstract Syntax Tree to examine two types of usage. One is whether a suggestion has not been used in any unit test and Regular Class, and another is whether the suggestion has been used in unit test classes only. If any MMR suggestion is found having one of these two types of usage or both, the respective suggestion is marked as Application-breaking. In order to evaluate the proposed technique, several experiments have been conducted on open source projects. The experimental results show that the proposed technique achieved 96.4% Precision, 90% Recall and 93.1% F-score in detecting Application-breaking MMR suggestions, because of considering external dependencies of the MMR suggestions.

Developers need to put lots of time and effort to reuse the code snippets retrieved by the existing code search engines. The reason is that these engines do not provide self-executable, functionally correct and easily understandable code snippets as search results. Developers manually resolve all the dependencies to make the code snippets executable in their development contexts. They have to write and execute the same test cases many times to check the correctness of the code fragments. In this paper, a technique has been proposed that converts each method in a code base into self-executable method (i.e., program slice) by resolving method calls, data and library dependencies. To ensure that the methods are functionally correct, automatic test scripts are generated and executed for each self-executable method based on the branch, statement, and path coverage. The understandability of the code fragments is increased by replacing irrelevant textual keywords with relevant words. All the self-executable code fragments are indexed using traditional Information Retrieval approach. So, when a user query is submitted, the technique will retrieve self-executable and functionally correct code snippets.