arXiv subjects

Ayushi Rastogi

Publications and source records attributed to Ayushi Rastogi.

At least 19 recordsLinked to original sources

arXiv2026

Psychological Safety Framework in Pull-based Open Source Projects

Psychological safety refers to the belief that team members can speak up, ask questions, and make mistakes without fear of negative consequences. Although psychological safety has been studied in traditional software teams, less is known about how it may appear in pull-based open-source software development, where contributors are self-directed and often collaborate voluntarily. This paper introduces a theory-informed framework for understanding how psychological safety may be reflected in pull request interactions. Drawing on psychological safety theory and prior work on software teams and open-source collaboration, the framework identifies observable interaction patterns related to feedback exchange, active participation, asking for input, and visible engagement from relevant project actors. To examine the framework empirically, we operationalize these patterns using nine observable variables from 60,684 pull requests across 26 popular GitHub repositories. The empirical results refine the framework by showing that visible engagement from contributors, reviewers, integrators, and other project members is positively associated with sustained participation, while interaction appears most useful when there is enough discussion without becoming excessive.

cs.SE↗

arXiv2026

Machine Learning Models for the Early Detection of Burnout in Software Engineering: a Systematic Literature Review

Burnout is an occupational syndrome that, like many other professions, affects the majority of software engineers. Past research studies showed important trends, including an increasing use of machine learning techniques to allow for an early detection of burnout. This paper is a systematic literature review (SLR) of the research papers that proposed machine learning (ML) approaches, and focused on detecting burnout in software developers and IT professionals. Our objective is to review the accuracy and precision of the proposed ML techniques, and to formulate recommendations for future researchers interested to replicate or extend those studies. From our SLR we observed that a majority of primary studies focuses on detecting emotions or utilise emotional dimensions to detect or predict the presence of burnout. We also performed a cross-sectional study to detect which ML approach shows a better performance at detecting emotions; and which dataset has more potential and expressivity to capture emotions. We believe that, by identifying which ML tools and datasets show a better performance at detecting emotions, and indirectly at identifying burnout, our paper can be a valuable asset to progress in this important research direction.

cs.SE↗

arXiv2026

Group versus Individual Review Requests: Tradeoffs in Speed and Quality at Mozilla Firefox

The speed at which code changes are integrated into the software codebase, also referred to as code review velocity, is a prevalent industry metric for improved throughput and developer satisfaction. While prior studies have explored factors influencing review velocity, the role of the review assignment process, particularly the `group review request', is unclear. In group review requests, available on platforms like Phabricator, GitHub, and Bitbucket, a code change is assigned to a reviewer group, allowing any member to review it, unlike individual review assignments to specific reviewers. Drawing parallels with shared task queues in Management Sciences, this study examines the effects of group versus individual review requests on velocity and quality. We investigate approximately 66,000 revisions in the Mozilla Firefox project, combining statistical modeling with practitioner views from a focus group discussion. Our study associates group reviews with improved review quality, characterized by fewer regressions, while having a negligible association with review velocity. Additional perceived benefits include balanced work distribution and training opportunities for new reviewers.

cs.SE↗

arXiv2025

Is Our Chatbot Telling Lies? Assessing Correctness of an LLM-based Dutch Support Chatbot

Companies support their customers using live chats and chatbots to gain their loyalty. AFAS is a Dutch company aiming to leverage the opportunity large language models (LLMs) offer to answer customer queries with minimal to no input from its customer support team. Adding to its complexity, it is unclear what makes a response correct, and that too in Dutch. Further, with minimal data available for training, the challenge is to identify whether an answer generated by a large language model is correct and do it on the fly. This study is the first to define the correctness of a response based on how the support team at AFAS makes decisions. It leverages literature on natural language generation and automated answer grading systems to automate the decision-making of the customer support team. We investigated questions requiring a binary response (e.g., Would it be possible to adjust tax rates manually?) or instructions (e.g., How would I adjust tax rate manually?) to test how close our automated approach reaches support rating. Our approach can identify wrong messages in 55\% of the cases. This work demonstrates the potential for automatically assessing when our chatbot may provide incorrect or misleading answers. Specifically, we contribute (1) a definition and metrics for assessing correctness, and (2) suggestions to improve correctness with respect to regional language and question type.

cs.CL↗

arXiv2025

Blended PC Peer Review Model: Process and Reflection

The academic peer review system is under increasing pressure due to a growing volume of submissions and a limited pool of available reviewers, resulting in delayed decisions and an uneven distribution of reviewing responsibilities. Building upon the International Conference on Mining Software Repositories (MSR) community's earlier experience with a Shadow PC (2021 and 2022) and Junior PC (2023 and 2024), MSR 2025 experimented with a Blended Program Committee (PC) peer review model for its Technical Track. This new model pairs up one Junior PC member with two regular PC members as part of the core review team of a given paper, instead of adding them as an extra reviewer. This paper presents the rationale, implementation, and reflections on the model, including empirical insights from a post-review author survey evaluating the quality and usefulness of reviews. Our findings highlight the potential of a Blended PC to alleviate reviewer shortages, foster inclusivity, and sustain a high-quality peer review process. We offer lessons learned and recommendations to guide future adoption and refinement of the model.

cs.SE↗

arXiv2025

It is Giving Major Satisfaction: Why Fairness Matters for Software Practitioners

Software practitioners often encounter workplace unfairness, such as unequal recognition and gender bias. While the link between fairness and job satisfaction has been established in other fields, its relevance to software professionals remains underexplored. This study examines how fairness perceptions relate to job satisfaction among software practitioners, focusing on both general trends and demographic-specific differences. We conducted an online survey of 108 software practitioners, followed by ordinal logistic regression to analyze the relationship between fairness perceptions and job satisfaction in software engineering contexts, with moderation analysis examining how this relationship varies across demographic groups. Our findings indicate that all four fairness dimensions (namely distributive, procedural, interpersonal, and informational fairness) significantly affect overall job satisfaction and satisfaction with job security. Among these, interpersonal fairness has the biggest impact. The relationship between fairness and job satisfaction is stronger for female, ethnically underrepresented, less experienced practitioners, and those with work limitations. Fairness in authorship emerged as an important factor for job satisfaction collectively, while fairness in policy implementation, high-demand situations, and working hours impacted specific demographic groups. This study highlights the role of fairness among software practitioners, offering strategies for organizations to promote fair practices and targeted approaches for certain demographic groups.

cs.SE↗

arXiv2025

Exploring turnover, retention and growth in an OSS Ecosystem

The Gentoo ecosystem has evolved significantly over 23 years, highlighting the critical impact of developer sentiment on workforce dynamics such as turnover, retention, and growth. While prior research has explored sentiment at the project level, sentiment-driven dynamics at the component level remain underexplored, particularly in their implications for software stability. This study investigates the interplay between developer sentiment and workforce dynamics in Gentoo. The primary objectives are to (1) compare workforce metrics (turnover, retention, and growth rates) between sentiment-positive (SP) and sentiment-negative (SN) components, (2) examine temporal trends across three time phases, and (3) analyze the impact of these dynamics on software stability. A mixed-method approach was employed, integrating sentiment analysis of mailing lists and commit histories using the SentiStrength-SE tool. Workforce metrics were statistically analyzed using Pearson Correlation Matrix and Mann-Whitney U tests. The analysis focused on the most SP and SN components in the ecosystem. SN components exhibited higher retention rates but slower growth and turnover compared to SP components, which showed dynamic contributor behavior but reduced long-term stability. Temporal analysis revealed significant variations in workforce dynamics over three phases, with developer retention correlating positively with modifications in both sentiment groups. Tailored strategies are necessary for managing sentiment-driven dynamics in OSS projects. Improving \textit{adaptability} in SN components, and \textit{continuity} in SP components, could improve project sustainability and innovation. This study contributes to a nuanced understanding of sentiment's role in workforce behavior and software stability within OSS ecosystems.

cs.SE↗

arXiv2025

Ecosystem-wide influences on pull request decisions: insights from NPM

The pull-based development model facilitates global collaboration within open-source software projects. However, whereas it is increasingly common for software to depend on other projects in their ecosystem, most research on the pull request decision-making process explored factors within projects, not the broader software ecosystem they comprise. We uncover ecosystem-wide factors that influence pull request acceptance decisions. We collected a dataset of approximately 1.8 million pull requests and 2.1 million issues from 20,052 GitHub projects within the NPM ecosystem. Of these, 98% depend on another project in the dataset, enabling studying collaboration across dependent projects. We employed social network analysis to create a collaboration network in the ecosystem, and mixed effects logistic regression and random forest techniques to measure the impact and predictive strength of the tested features. We find that gaining experience within the software ecosystem through active participation in issue-tracking systems, submitting pull requests, and collaborating with pull request integrators and experienced developers benefits all open-source contributors, especially project newcomers. These results are complemented with an exploratory qualitative analysis of 538 pull requests. We find that developers with ecosystem experience make different contributions than users without. Zooming in on a subset of 111 pull requests with clear ecosystem involvement, we find 3 overarching and 10 specific reasons why developers involve ecosystem projects in their pull requests. The results show that combining ecosystem-wide factors with features studied in previous work to predict the outcome of pull requests reached an overall F1 score of 0.92. However, the outcomes of pull requests submitted by newcomers are harder to predict.

cs.SE↗

arXiv2024

Understanding Fairness in Software Engineering: Insights from Stack Exchange

Software practitioners discuss problems at work with peers, in-person and online. These discussions can be technical (e.g., how to fix a bug?) and social (e.g., how to assign work fairly?). While there is a growing body of knowledge exploring fairness problems and solutions in the human and social factors of software engineering, most focus has been on specific problems. This study provides fairness discussions by software practitioners on Stack Exchange sites. We present an exploratory study presenting the fairness experience of software practitioners and fairness expectations in software teams. We also want to identify the fairness aspects software practitioners talk about the most. For example, do they care more about fairness in income or how they are treated in the workplace? Our investigation of fairness discussions on eight Stack Exchange sites resulted in a list of 136 posts (28 questions and 108 answers) manually curated from 4,178 candidate posts. The study reveals that the majority of fairness discussions (24 posts) revolve around the topic of income suggesting that many software practitioners are highly interested in matters related to their pay and how it is fairly distributed. Further, we noted that while not discussed as often, discussions on fairness in recruitment tend to receive the highest number of views and scores. Interestingly, the study shows that unfairness experiences extend beyond the protected attributes. In this study, only 25 out of 136 posts mention protected attributes, with gender mainly being discussed.

cs.SE↗

arXiv2024

Characterising Developer Sentiment in Software Components: An Exploratory Study of Gentoo

Collaborative software development happens in teams, that cooperate on shared artefacts, and discuss development on online platforms. Due to the complexity of development and the variety of teams, software components often act as effective containers for parallel work and teams. Past research has shown how communication between team members, especially in an open-source environment, can become extremely toxic, and lead to members leaving the development team. This has a direct effect on the evolution and maintenance of the project in which the former members were active in. The purpose of our study is two-fold: first, we propose an approach to evaluate, at a finer granularity, the positive and negative emotions in the communication between developers; and second, we aim to characterise a project's development paths, or components, as more or less impacted by the emotions. Our analysis evaluates single sentences rather than whole messages as the finest granularity of communication. The previous study found that the high positivity or negativity at the sentence level may indirectly impact the writer him/herself, or the reader. In this way, we could highlight specific paths of Gentoo as the most affected by negative emotions, and show how negative emotions have evolved and changed along the same paths. By joining the analysis of the mailing lists, from which we derive the sentiment of the developers, with the information derived from the development logs, we obtained a longitudinal picture of how development paths have been historically affected by positive or negative emotions. Our study shows that, in recent years, negative emotions have generally decreased in the communication between Gentoo developers. We also show how file paths, as collaborative software development artefacts, were more or less impacted by the emotions of the developers.

cs.SE↗

arXiv2023

What Do You Mean by Memory? When Engineers Are Lost in the Maze of Complexity

An accepted practice to decrease applications' memory usage is to reduce the amount and frequency of memory allocations. Factors such as (a) the prevalence of out-of-memory (OOM) killers, (b) memory allocations in modern programming languages done implicitly, (c) overcommitting being a default strategy in the Linux kernel, and (d) the rise in complexity and terminology related to memory management makes the existing guidance inefficient. The industry needs detailed guidelines for optimizing memory usage targeting specific operating systems (OS) and programming language types.

cs.SE↗

arXiv2023

The Devil Is in the Command Line: Associating the Compiler Flags With the Binary and Build Metadata

Engineers build large software systems for multiple architectures, operating systems, and configurations. A set of inconsistent or missing compiler flags generates code that catastrophically impacts the system's behavior. In the authors' industry experience, defects caused by an undesired combination of compiler flags are common in nontrivial software projects. We are unaware of any build and CI/CD systems that track how the compiler produces a specific binary in a structured manner. We postulate that a queryable database of how the compiler compiled and linked the software system will help to detect defects earlier and reduce the debugging time.

cs.SE↗

arXiv2023

Does Code Review Speed Matter for Practitioners?

Increasing code velocity is a common goal for a variety of software projects. The efficiency of the code review process significantly impacts how fast the code gets merged into the final product and reaches the customers. We conducted a survey to study the code velocity-related beliefs and practices in place. We analyzed 75 completed surveys from 39 participants from the industry and 36 from the open-source community. Our critical findings are (a) the industry and open-source community hold a similar set of beliefs, (b) quick reaction time is of utmost importance and applies to the tooling infrastructure and the behavior of other engineers, (c) time-to-merge is the essential code review metric to improve, (d) engineers have differing opinions about the benefits of increased code velocity for their career growth, and (e) the controlled application of the commit-then-review model can increase code velocity. Our study supports the continued need to invest in and improve code velocity regardless of the underlying organizational ecosystem.

cs.SE↗

arXiv2023

Are We Speeding Up or Slowing Down? On Temporal Aspects of Code Velocity

This paper investigates how the duration of various code review periods changes over a projects' lifetime. We study four open-source software (OSS) projects: Blender, FreeBSD, LLVM, and Mozilla. We mine and analyze the characteristics of 283,235 code reviews that cover, on average, seven years' worth of development. Our main conclusion is that neither the passage of time or the project's size impact code velocity. We find that (a) the duration of various code review periods (time-to-first-response, time-to-accept, and time-to-merge) for FreeBSD, LLVM, and Mozilla either becomes shorter or stays the same; no directional trend is present for Blender, (b) an increase in the size of the code bases (annually 3-17%) does not accompany a decrease in code velocity, and (c) for FreeBSD, LLVM, and Mozilla, the 30-day moving median stays in a fixed range for time-to-merge. These findings do not change with variabilities in code churn metrics, such as the number of commits or distinct authors of code changes.

cs.SE↗

arXiv2022

Who Ate My Memory? Towards Attribution in Memory Management

To understand applications' memory usage details, engineers use instrumented builds and profiling tools. Both approaches are impractical for use in production environments or deployed mobile applications. As a result, developers can gather only high-level memory-related statistics for deployed software. In our experience, the lack of granular field data makes fixing performance and reliability-related defects complex and time-consuming. The software industry needs lightweight solutions to collect detailed data about applications' memory usage to increase developer productivity. Current research into memory attribution-related data structures, techniques, and tools is in the early stages and enables several new research avenues.

cs.SE↗

arXiv2022

When malloc() Never Returns NULL -- Reliability as an Illusion

For decades, the guidance given to software engineers has been to check the memory allocation results. This validation step is necessary to avoid crashes. However, in user mode, in modern operating systems (OS), such as Android, FreeBSD, iOS, and macOS, the caller does not have an opportunity to handle the memory allocation failures. This behavioral trait results from the actions of a system component called an out-of-memory (OOM) killer. We identify that the only mainstream OS that, by default, lets applications detect memory allocation failures is Microsoft Windows. The false expectation that an application can handle OOM errors can negatively impact its design. The presence of error-handling code creates an illusion of reliability and is wasteful in terms of lines of code and code size. We describe the current behavior of a sample of popular OSs during low-memory conditions and provide recommendations for engineering practices going forward.

cs.SE↗

arXiv2022

There Ain't No Such Thing as a Free Custom Memory Allocator

Using custom memory allocators is an efficient performance optimization technique. However, dependency on a custom allocator can introduce several maintenance-related issues. We present lessons learned from the industry and provide critical guidance for using custom memory allocators and enumerate various challenges associated with integrating them. These recommendations are based on years of experience incorporating custom allocators into different industrial software projects.

cs.SE↗

arXiv2022

Is Kernel Code Different From Non-Kernel Code? A Case Study of BSD Family Operating Systems

Code churn and code velocity describe the evolution of a code base. Current research quantifies and studies code churn and velocity at a high level of abstraction, often at the overall project level or even at the level of an entire company. We argue that such an approach ignores noticeable differences among the subsystems of large projects. We conducted an exploratory study on four BSD family operating systems: DragonFlyBSD, FreeBSD, NetBSD, and OpenBSD. We mine 797,879 commits to characterize code churn in terms of the annual growth rate, commit types, change type ratio, and size taxonomy of commits for different subsystems (kernel, non-kernel, and mixed). We also investigate differences among various code review periods, i.e., time-to-first-response, time-to-accept, and time-to-merge, as indicators of code velocity. Our study provides empirical evidence that quantifiable evolutionary code characteristics at a global system scope fail to take into account significant individual differences that exist at a subsystem level. We found that while there exist similarities in the code base growth rate and distribution of commit types (neutral, additive, and subtractive) across BSD subsystems, (a) most commits contain kernel or non-kernel code exclusively, (b) kernel commits are larger than non-kernel commits, and (c) code reviews for kernel code take longer than non-kernel code.

cs.SE↗