Open source software (OSS) sustainability depends not only on code contributions but also on governance structures that define who decides, who acts, and how responsibility is distributed. We lack systematic empirical evidence of how projects formally codify roles and authority in written artifacts. This paper investigates how OSS projects define and structure governance through their GOVERNANCE.md files and related documents. We analyze governance as an institutional infrastructure, a set of explicit rules that shape participation, decision rights, and community memory. We used Institutional Grammar to extract and formalize role definitions from repositories hosted on GitHub. We decompose each role into scope, privileges, obligations, and life-cycle rules to compare role structures across communities. Our results show that although OSS projects use a stable set of titles, identical titles carry different responsibilities, and different labels describe similar functions, which we call role drift. Still, we observed that a few actors sometimes accumulate technical, managerial, and community duties.
Remote and hybrid work have transformed how software development teams organize, communicate, and assure quality. This study investigates how regression testing is performed and experienced under these distributed conditions. Using qualitative interviews with twenty software professionals from diverse organizations, we analyzed how regression testing processes, tools, and coordination practices adapt to remote and hybrid environments. The results show that while the core phases of regression testing remain stable, their execution increasingly depends on documentation, automation, and tool integration to support asynchronous collaboration. Communication and coordination challenges were mitigated through standardized reporting, shared repositories, and traceability mechanisms that replaced informal co-located interactions. These findings reveal regression testing as a socio-technical practice shaped by the interaction between human collaboration and digital infrastructure. Our study contributes to understanding how software quality assurance evolves under remote conditions and offers practical implications for teams and organizations adopting hybrid work models.
Context: Empathy is increasingly recognized as a critical human capability for software engineers, supporting collaboration, ethical awareness, and user-centered design. While many disciplines have long explored empathy as part of professional formation, its incorporation into software engineering education remains fragmented. Aim: This study investigates how empathy has been used, taught, and discussed in general engineering and software engineering education, with the goal of identifying pedagogical practices, outcomes, and disciplinary differences that inform the structured integration of empathy into software curricula. Method: Following established guidelines for systematic reviews in software engineering, we conducted a comprehensive search across six databases and analyzed 43 primary studies published between 2001 and 2025. Data were coded and synthesized using descriptive and thematic analysis to capture how empathy is conceptualized, fostered, and assessed across educational contexts. Findings: Our findings show that engineering programs frame empathy as an ethical and reflective capacity linked to social responsibility, whereas software engineering translates empathy into structured, design-oriented, and measurable practices. Across both domains, empathy teaching enhances collaboration, ethical reasoning, bias awareness, and motivation, but remains limited by low curricular prioritization, measurement challenges, and resource constraints. Conclusion: Empathy is evolving from a peripheral soft skill into a measurable pedagogical construct in software engineering education. Embedding empathy as a continuous, assessable component of design and development courses can strengthen inclusivity, ethical reflection, and responsible innovation in future software professionals.
The adoption of Generative AI (GenAI) suggests major changes for software engineering, including technical aspects but also human aspects of the professionals involved. One of these aspects is how individuals perceive themselves regarding their work, i.e., their work identity, and the processes they perform to form, adapt and reject these identities, i.e., identity work. Existent studies provide evidence of such identity work of software professionals triggered by the adoption of GenAI, however they do not consider differences among diverse roles, such as developers and testers. In this paper, we argue the need for considering the role as a factor defining the identity work of software professionals. To support our claim, we review some studies regarding different roles and also recent studies on how to adopt GenAI in software engineering. Then, we propose a research agenda to better understand how the role influences identity work of software professionals triggered by the adoption of GenAI, and, based on that, to propose new artifacts to support this adoption. We also discuss the potential implications for practice of the results to be obtained.
[Context] Online Recruitment and Selection (R S) processes are often the first point of contact between early-career software engineers and the tech industry. Yet many candidates experience these processes as opaque, inefficient, or even discouraging. While prior research has extensively documented the flaws and biases in online tech hiring, little is known about the practices that create positive candidate experiences. [Objective Method] This paper explores such practices, referred to as Constructive Patterns (CPs), from the perspective of early-career software engineers. Guided by Applicant Attribution-Reaction Theory, we conducted 22 semi-structured interviews in which participants collectively described over 470 online R S experiences. [Results] Through thematic analysis, we identified 22 CPs that reflect positive practices such as comprehensive and transparent job advertisements (CP01), specific and developmental feedback (CP03), humanized and respectful interaction (CP06), and framing the process as a two-way street (CP18). [Conclusion] Our findings extend the conversation on tech hiring beyond diagnosing dysfunctions toward designing for human-centered and growth-oriented candidate experiences. The resulting catalog of CPs provides a concrete and empirically grounded resource for organizations seeking to attract and support early-career software engineers more effectively.
