Searcharxiv⌕ Search

arXiv subjects

Khairul Alam

Publications and source records attributed to Khairul Alam.

13 recordsLinked to original sources

Who Pays the Review Cost? Triage, Fairness, and Accountability in AI-authored Pull Requests

AI coding agents are moving from local code assistance into pull-based workflows, where generated contributions must be reviewed, explained, and maintained within existing project norms. Although recent work has begun to characterize AI-authored pull requests (AIPRs), less is known about how reviewers govern their entry into review, how AI authorship reshapes credibility and fairness, and what intake mechanisms protect review sustainability. We report a mixed-method questionnaire survey of 239 practitioners from 31 countries with code-review experience and varying exposure to AIPRs. In the scenarios and self-reports elicited by the survey, AI authorship was not a categorical rejection signal. Instead, respondents described review effort as conditional on whether an AIPR arrived as an accountable contribution, with bounded scope, project-grounded rationale, validation beyond Continuous Integration (CI), contributor responsiveness, and identifiable post-merge ownership. This conditional logic extended to newcomer AIPRs, where respondents emphasized visible participation in the current review process over profile-level reputation alone. Qualitative responses further described shifts in mentoring, scrutiny, deferral, and routing when human stewardship was difficult to observe. We conceptualize missing rationale, validation, and ownership as reviewability debt, the work reviewers must absorb when generated code lacks sufficient human grounding. These findings reframe AIPR governance around making human judgment observable before generated contributions consume scarce reviewer attention.

cs.SE↗

Understanding Maintenance and Support in a Community-Driven Scientific Workflow Ecosystem: A Cross-Space Study of Galaxy

Galaxy is a widely used, community-driven scientific workflow system whose sustainability depends on continuous maintenance across its software, tools, workflows, infrastructure, documentation, and user-support ecosystem. However, maintenance knowledge in Galaxy is distributed across development and community-support spaces, making it difficult to understand what is maintained, how maintenance artifacts are resolved, and how user-facing concerns connect to repository-level development. We conduct a large-scale empirical study of Galaxy using 11,762 GitHub issues, 52,203 pull requests, and 6,235 Community Forum discussions. We characterize maintenance and support concerns, examine factors associated with resolution outcomes and resolution time, and investigate explicit and candidate connections among maintenance artifacts across these spaces. Using BERTopic modeling, we identify nine issue topics, 14 pull-request topics, and 14 forum topics, revealing a maintenance landscape spanning workflow execution, data management, tools and dependencies, infrastructure, testing, scientific resources, documentation, and user support. Resolution analyses show that coordination, diagnostic, contributor, automation, and engagement characteristics exhibit different associations with whether artifacts are resolved and how quickly resolution occurs. We further find limited explicit traceability between development and support spaces: 97.77\% of 16,426 resolved explicit relationships occur within GitHub, while only 294 connect GitHub artifacts with Community Forum discussions, despite additional semantic and technical relatedness across these spaces. Together, these findings characterize Galaxy maintenance as a distributed ecosystem-level process and identify opportunities to improve diagnostic reporting, lifecycle-aware triage, cross-space traceability, and the reuse of community-support knowledge.

cs.SE↗

Understanding Developer Pain Points in Federated Learning: Insights from Stack Overflow and GitHub

Federated Learning (FL) enables collaborative model training without centralizing raw data, but building and operating FL systems remains difficult due to distributed execution, rapidly evolving frameworks, and privacy and governance requirements. In this paper, we present an empirical study of FL developer challenges by independently analyzing 495 Stack Overflow posts and 9,116 GitHub issues and pull requests from 92 FL-related projects. Using BERTopic-based topic modeling and difficulty indicators such as unresolved rates and median resolution time, we characterize recurring problem areas and compare how they manifest across the two support platforms, Stack Overflow and GitHub. Our analysis surfaces nine dominant Stack Overflow topics and thirteen GitHub topics, with persistent difficulties concentrated in environment setup and dependency compatibility, API breakages and migration, training instability under non-IID data, evaluation and metric correctness, and the integration of privacy-preserving mechanisms. We also categorize posts by question intent to understand the kinds of help developers seek; this intent analysis shows that "How"-type questions dominate, reflecting strong demand for procedural guidance. Several topics, such as "TFF Installation and Environment Compatibility" and "Federated Feature Engineering and SecureBoost Issues," exhibit high unresolved rates and long resolution times, suggesting shortcomings in tooling, documentation, and debugging support. Based on these findings, we provide actionable implications for FL framework designers, documentation authors, and educators. Although our results are constrained to public discussions and a subset of widely discussed frameworks, the study offers a scalable method for continuously monitoring developer pain points and improving the usability, reliability, and deployability of FL systems.

cs.SE↗

Maintenance and Support in Community-Driven Scientific Pipeline Ecosystems: A Cross-Platform Empirical Study of nf-core

Community-driven scientific pipeline ecosystems are increasingly important for reproducible data-intensive research, but their sustainability depends on more than workflow engines, templates, and testing infrastructure. It also depends on how communities maintain pipelines, integrate contributions, and support users across heterogeneous execution environments. This paper presents a cross-platform empirical study of maintenance and support in nf-core, a large ecosystem of standardized Nextflow pipelines. We analyze 15,760 GitHub issues, 35,411 GitHub pull requests, and 895 Seqera Community Forum discussions to examine what maintenance and support concerns arise, how they differ across artifact types, which factors are associated with resolution outcomes, and how problems and solutions flow between repository-centered and community-centered spaces. We find that issues primarily capture repository-level problem reporting and maintenance coordination; pull requests capture implementation, review, testing, dependency, and template-update work; and forum discussions capture user-facing support around execution failures, containers, cloud and HPC environments, MultiQC reporting, and Nextflow usage. Resolution outcomes are associated with actionability, coordination, and diagnostic evidence. Issue closure is linked to assignees, comments, milestones, bug labels, error mentions, and version information. Pull request integration varies by author role, automation type, draft status, checklists, linked issues, and review routing. Forum accepted answers are more likely when discussions include code blocks, sustained interaction, and concrete technical evidence, while cloud, HPC, and workflow-semantics questions are harder to resolve. Cross-platform analysis reveals strong repository-internal traceability within GitHub, but limited explicit linkage between forum discussions and repository artifacts.

cs.SE↗

Analyzing GitHub Issues and Pull Requests in nf-core Pipelines: Insights into nf-core Pipeline Repositories

Scientific Workflow Systems (SWSs) such as Nextflow have become essential software frameworks for conducting reproducible, scalable, and portable computational analyses in data-intensive fields like genomics, transcriptomics, and proteomics. Building on Nextflow, the nf-core community curates standardized, peer-reviewed pipelines that follow strict testing, documentation, and governance guidelines. Despite its widespread adoption, little is known about the challenges users face in developing and maintaining these pipelines. This paper presents an empirical study of 25,173 issues and pull requests from these pipelines to uncover recurring challenges, management practices, and perceived difficulties. Using BERTopic modeling, we identify 13 key challenges, including pipeline development and integration, bug fixing, integrating genomic data, managing CI configurations, and handling version updates. We then examine issue-resolution dynamics, showing that 89.38\% of issues and pull requests are eventually closed, with half resolved within 3 days. Statistical analysis reveals that the presence of labels (large effect, $\mathit{d} = 0.94$) and code snippets (medium effect, $\mathit{d} = 0.50$) significantly improves the likelihood of resolution. Further analysis reveals that tool development and repository maintenance poses the most significant challenges, followed by testing pipelines and CI configurations, and debugging containerized pipelines. Overall, this study provides actionable insights into the collaborative development and maintenance of nf-core pipelines, highlighting opportunities to enhance their usability, sustainability, and reproducibility.

cs.SE↗

Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study

Autonomous coding agents (e.g., OpenAI Codex, Devin, GitHub Copilot) are increasingly used to generate fix-related pull requests (PRs) in real world software repositories. However, their practical effectiveness depends on whether these contributions are accepted and merged by project maintainers. In this paper, we present an empirical study of AI agent involved fix related PRs, examining both their integration outcomes, latency, and the factors that hinder successful merging. We first analyze 8,106 fix related PRs authored by five widely used AI coding agents from the AIDEV POP dataset to quantify the proportions of PRs that are merged, closed without merging, or remain open. We then conduct a manual qualitative analysis of a statistically significant sample of 326 closed but unmerged PRs, spending approximately 100 person hours to construct a structured catalog of 12 failure reasons. Our results indicate that test case failures and prior resolution of the same issues by other PRs are the most common causes of non integration, whereas build or deployment failures are comparatively rare. Overall, our findings expose key limitations of current AI coding agents in real world settings and highlight directions for their further improvement and for more effective human AI collaboration in software maintenance.

cs.SE↗

What Drives Issue Resolution Speed? An Empirical Study of Scientific Workflow Systems on GitHub

Scientific Workflow Systems (SWSs) play a vital role in enabling reproducible, scalable, and automated scientific analysis. Like other open-source software, these systems depend on active maintenance and community engagement to remain reliable and sustainable. However, despite the importance of timely issue resolution for software quality and community trust, little is known about what drives issue resolution speed within SWSs. This paper presents an empirical study of issue management and resolution across a collection of GitHub-hosted SWS projects. We analyze 21,116 issues to investigate how project characteristics, issue metadata, and contributor interactions affect time-to-close. Specifically, we address two research questions: (1) how issues are managed and addressed in SWSs, and (2) how issue and contributor features relate to issue resolution speed. We find that 68.91% of issues are closed, with half of them resolved within 18.09 days. Our results show that although SWS projects follow structured issue management practices, the issue resolution speed varies considerably across systems. Factors such as labeling and assigning issues are associated with faster issue resolution. Based on our findings, we make recommendations for developers to better manage SWS repository issues and improve their quality.

cs.SE↗

From Prompt to Pipeline: Large Language Models for Scientific Workflow Development in Bioinformatics

Scientific Workflow Systems such as Galaxy and Nextflow are essential for scalable, reproducible, and automated bioinformatics analyses. However, developing and understanding scientific workflows remains challenging for many domain scientists due to the complexity of tool/module selection, infrastructure requirements, and limited programming expertise. This study explores whether state-of-the-art Large Language Models such as GPT-4o, Gemini 2.5 Flash, and DeepSeek-V3 can assist in generating accurate, complete, and usable bioinformatics workflows. We evaluate a set of representative workflows covering tasks such as RNA-seq, SNP analysis, and DNA methylation across both Galaxy (graphical) and Nextflow (script-based) platforms. To simulate realistic usage, we adopt a tiered prompting strategy: each workflow is first generated using an instruction-only prompt; if the output is incomplete or incorrect, we escalate to a role-based prompt, and finally to chain-of-thought prompting if needed. The generated workflows are evaluated against community-curated baselines from the Galaxy Training Network and nf-core, using criteria including correctness, completeness, tool appropriateness, and executability. Results show that LLMs exhibit strong potential in workflow development. Gemini 2.5 Flash produced the most accurate and user-friendly workflows in Galaxy, while DeepSeek-V3 excelled in Nextflow pipeline generation. GPT-4o performed nicely with structured prompts. Prompting strategy significantly influenced output quality, with role-based and chain-of-thought prompts enhancing correctness and completeness. Overall, LLMs can reduce the cognitive and technical barriers to workflow development, making SWSs more accessible to novice and expert users. This work highlights the practical utility of LLMs and provides actionable insights for integrating them into real-world bioinformatics workflow design.

cs.SE↗

An Empirical Investigation on the Challenges in Scientific Workflow Systems Development

Scientific Workflow Systems (SWSs) are advanced software frameworks that drive modern research by orchestrating complex computational tasks and managing extensive data pipelines. These systems offer a range of essential features, including modularity, abstraction, interoperability, workflow composition tools, resource management, error handling, and comprehensive documentation. Utilizing these frameworks accelerates the development of scientific computing, resulting in more efficient and reproducible research outcomes. However, developing a user-friendly, efficient, and adaptable SWS poses several challenges. This study explores these challenges through an in-depth analysis of interactions on Stack Overflow (SO) and GitHub, key platforms where developers and researchers discuss and resolve issues. In particular, we leverage topic modeling (BERTopic) to understand the topics SWSs developers discuss on these platforms. We identified 10 topics developers discuss on SO (e.g., Workflow Creation and Scheduling, Data Structures and Operations, Workflow Execution) and found that workflow execution is the most challenging. By analyzing GitHub issues, we identified 13 topics (e.g., Errors and Bug Fixing, Documentation, Dependencies) and discovered that data structures and operations is the most difficult. We also found common topics between SO and GitHub, such as data structures and operations, task management, and workflow scheduling. Additionally, we categorized each topic by type (How, Why, What, and Others). We observed that the How type consistently dominates across all topics, indicating a need for procedural guidance among developers. The dominance of the How type is also evident in domains like Chatbots and Mobile development. Our study will guide future research in proposing tools and techniques to help the community overcome the challenges developers face when developing SWSs.

cs.SE↗

Developer Challenges on Large Language Models: A Study of Stack Overflow and OpenAI Developer Forum Posts

Large Language Models (LLMs) have gained widespread popularity due to their exceptional capabilities across various domains, including chatbots, healthcare, education, content generation, and automated support systems. However, developers encounter numerous challenges when implementing, fine-tuning, and integrating these models into real-world applications. This study investigates LLM developers' challenges by analyzing community interactions on Stack Overflow and OpenAI Developer Forum, employing BERTopic modeling to identify and categorize developer discussions. Our analysis yields nine challenges on Stack Overflow (e.g., LLM Ecosystem and Challenges, API Usage, LLM Training with Frameworks) and 17 on the OpenAI Developer Forum (e.g., API Usage and Error Handling, Fine-Tuning and Dataset Management). Results indicate that developers frequently turn to Stack Overflow for implementation guidance, while OpenAI's forum focuses on troubleshooting. Notably, API and functionality issues dominate discussions on the OpenAI forum, with many posts requiring multiple responses, reflecting the complexity of LLM-related problems. We find that LLM-related queries often exhibit great difficulty, with a substantial percentage of unresolved posts (e.g., 79.03\% on Stack Overflow) and prolonged response times, particularly for complex topics like 'Llama Indexing and GPU Utilization' and 'Agents and Tool Interactions'. In contrast, established fields like Mobile Development and Security enjoy quicker resolutions and stronger community engagement. These findings highlight the need for improved community support and targeted resources to assist LLM developers in overcoming the evolving challenges of this rapidly growing field. This study provides insights into areas of difficulty, paving the way for future research and tool development to better support the LLM developer community.

cs.SE↗

Reusability Challenges of Scientific Workflows: A Case Study for Galaxy

Scientific workflow has become essential in software engineering because it provides a structured approach to designing, executing, and analyzing scientific experiments. Software developers and researchers have developed hundreds of scientific workflow management systems so scientists in various domains can benefit from them by automating repetitive tasks, enhancing collaboration, and ensuring the reproducibility of their results. However, even for expert users, workflow creation is a complex task due to the dramatic growth of tools and data heterogeneity. Thus, scientists attempt to reuse existing workflows shared in workflow repositories. Unfortunately, several challenges prevent scientists from reusing those workflows. In this study, we thus first attempted to identify those reusability challenges. We also offered an action list and evidence-based guidelines to promote the reusability of scientific workflows. Our intensive manual investigation examined the reusability of existing workflows and exposed several challenges. The challenges preventing reusability include tool upgrading, tool support unavailability, design flaws, incomplete workflows, failure to load a workflow, etc. Such challenges and our action list offered guidelines to future workflow composers to create better workflows with enhanced reusability. In the future, we plan to develop a recommender system using reusable workflows that can assist scientists in creating effective and error-free workflows.

cs.SE↗

Uniform Benchmarking of Low Voltage Van Der Waals FETs

Monolayer MoS2, MoSe2, MoTe2, WS2, WSe2, and black phosphorous field effect transistors (FETs) operating in the low-voltage (LV) regime (0.3V) with geometries from the 2019 and 2028 nodes of the 2013 International Technology Roadmap for Semiconductors (ITRS) are benchmarked along with an ultra-thin-body Si FET. Current can increase or decrease with scaling, and the trend is strongly correlated with the effective mass. For LV operation at the 2028 node, an effective mass of ~0.4 m0, corresponding to that of WSe2, gives the maximum drive current. The short 6 nm gate length combined with LV operation is forgiving in its requirements for material quality and contact resistances. In this LV regime, device and circuit performance are competitive using currently measured values for mobilities and contact resistances for the monolayer two-dimensional materials.

cond-mat.mes-hall↗

Electronic Properties of Carbon Nanotubes Calculated from Density Functional Theory and the Empirical pi-Bond Model

The validity of the DFT models implemented by FIREBALL for CNT electronic device modeling is assessed. The effective masses, band gaps, and transmission coefficients of semi-conducting, zigzag, (n,0) carbon nanotubes (CNTs) resulting from the ab initio tight-binding density functional theory (DFT) code FIREBALL and the empirical, nearest-neighbor pi-bond model are compared for all semiconducting n values 5 <(=) n <(=) 35. The DFT values for the effective masses differ from the pi-bond values by +(-) 9% over the range of n values, 17 <(=) n <(=) 29, most important for electronic device applications. Over the range 13 <(=) n <(=) 35, the DFT bandgaps are less than the empirical bandgaps by 20-180 meV depending on the functional and the n value. The pi-bond model gives results that differ signifcantly from the DFT results when the CNT diameter goes below 1 nm due to the large curvature of the CNT. The pi-bond model quickly becomes inaccurate away from the bandedges for a (10, 0) CNT, and it is completely inaccurate for n <(=) 8.

cond-mat.mes-hall↗