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

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

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

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

softwarearchitecture softwareengineering testing

software engineering, software architecture, testing

Maintenance and Support in Community-Driven Scientific Pipeline Ecosystems: A Cross-Platform Empirical Study of nf-core Khairul Alam1*, Kowsik Roy2 , Md Shamimur Rahman3 , Banani Roy4 1,3,4* 2

Department of Computer Science, University of Saskatchewan, Saskatoon, S7N 5A2, Canada. Department of Computer Science and Engineering, BRAC University, Dhaka, 1212, Bangladesh.

arXiv:2607.10839v1 [cs.SE] 12 Jul 2026

*Corresponding author(s). E-mail(s): [email protected]; Contributing authors: [email protected]; [email protected]; [email protected]; Abstract 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. Using topic modeling, statistical outcome analysis, direct-link mining, semantic similarity analysis, technical-signal overlap analysis, and qualitative inspection, we show that issues primarily capture repositorylevel 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. These findings show that sustaining scientific pipeline ecosystems requires not only technical standardization, but also actionable support processes, review-ready contribution workflows, infrastructure-specific guidance, and stronger traceability between user support and repository maintenance. Keywords: nf-core, scientific workflow systems, pipeline maintenance, community support, cross-platform mining, empirical software engineering

1 Introduction Modern data-intensive science increasingly depends on computational pipelines to transform raw data into reliable scientific results [1, 2]. In domains such as bioinformatics, astronomy and cosmology, and earth and climate science, these pipelines coordinate many interdependent steps, including quality control, alignment, quantification, statistical analysis, reporting, visualization, simulation, and large-scale data processing. They also bind together software tools, parameters, reference datasets, containers, execution profiles, and infrastructure-specific configurations [1, 3, 4]. As scientific analyses become more computationally intensive and distributed, reproducibility depends not only on sharing data and code, but also on making the full analytical process portable, executable, 1

inspectable, and maintainable across changing computational environments [5–9]. However, achieving these goals remains difficult because pipelines must operate across changing software dependencies, container images, operating systems, cloud services, high-performance computing (HPC) schedulers, file systems, and institutional configurations [10]. Scientific Workflow Systems (SWSs) have emerged as a central response to these challenges. Systems such as Nextflow [4], Snakemake [11], Galaxy [12], Pegasus [13], Taverna [14], and others [15] provide abstractions for specifying, executing, scaling, and reusing multi-step computational analyses. These systems improve portability and reproducibility by separating workflow logic from execution infrastructure and by supporting execution across local machines, high-performance computing (HPC) clusters, cloud platforms, and containerized environments [8, 16, 17]. Among these systems, Nextflow [4] has become particularly prominent because it combines a dataflow programming model with support for containers, package managers, cloud execution, HPC schedulers, and scalable deployment [18]. However, the existence of a workflow engine alone does not guarantee that pipelines remain reusable, well-tested, documented, executable, or sustainably maintained. These qualities also depend on software engineering processes, review practices, documentation, testing infrastructure, dependency management, and community support. Within this broader landscape, nf-core1 has become one of the most visible community-driven ecosystems for standardized Nextflow pipelines. We use the term community-driven scientific pipeline ecosystem to refer to a socio-technical system in which reusable scientific pipelines, shared components, development tools, infrastructure conventions, contributors, maintainers, and users jointly sustain computational analyses over time. Software ecosystem research emphasizes that such systems are shaped by both technical dependencies and social coordination among actors, projects, and shared infrastructure [19–21]. nf-core exemplifies this form of ecosystem because it combines Nextflow with shared development guidelines, reusable modules and subworkflows, automated testing, container support, documentation requirements, stable releases, and community review [1, 18]. Over time, nf-core has expanded from a collection of pipelines into a broader ecosystem that includes reusable DSL2 modules, subworkflows, shared test datasets, helper tools, governance structures, training material, outreach activities, and user-support channels. The sustainability of nf-core depends not only on technical standardization but also on continuous maintenance and user support. Pipelines depend on evolving tools, modules, reference datasets, container images, package versions, execution profiles, and infrastructure-specific settings. Users run these pipelines across heterogeneous environments, including local workstations, institutional HPC clusters, commercial cloud platforms, container runtimes, and managed execution services. As a result, they encounter problems related to input formatting, software versions, resource limits, executor behavior, storage systems, reference files, containers, profiles, and pipeline-specific parameters. These problems are not always conventional software defects. Addressing these problems requires more than bug fixing; it requires triage, documentation, review, dependency maintenance, template synchronization, infrastructure troubleshooting, and community-based knowledge sharing. These activities are distributed across multiple socio-technical spaces. GitHub issues [22] capture repositorycentered problem reporting, bug reports, documentation gaps, module behavior, configuration problems, and pipeline-specific failures. GitHub pull requests [23] capture implementation and integration work, including fixes, tests, dependency updates, template changes, documentation edits, review discussion, and automated maintenance. Seqera Community Forum discussions [24] capture user-facing support needs, including pipeline execution failures, container and dependency problems, cloud and HPC deployment questions, MultiQC reporting issues, Nextflow syntax questions, and troubleshooting practices. Prior empirical software engineering research has shown that GitHub artifacts and developer discussion spaces provide valuable evidence about collaboration, contribution evaluation, maintenance practices, and user support [25–29]. For nf-core, mining these artifacts is appropriate because maintenance and support work is explicitly recorded through issue reports, pull request discussions, review metadata, forum questions, accepted answers, links, labels, and other observable traces. At the same time, these traces must be interpreted carefully because repository and forum data are incomplete records of broader community activity [27]. Studying only one of these spaces would provide an incomplete view of nf-core maintenance and support. Studying only GitHub issues and pull requests would emphasize formal repository maintenance while missing many practical user-facing execution problems. Studying only forum discussions would reveal support needs but miss how maintainers implement, review, and integrate durable changes. A cross-platform perspective is therefore necessary to understand how maintenance and support concerns arise, how they differ across artifact types, how they are resolved, and whether user-facing support problems are traceably connected to repository-level maintenance work. Prior work has established the importance of SWSs for reproducible computational science and has described nf-core’s role in standardizing and curating Nextflow pipelines [1, 7, 8, 15, 18]. Recent empirical studies provide 1

https://nf-co.re/

useful context for this work. Alam and Roy [3] analyzed issues and pull requests from nf-core pipeline repositories to characterize repository-level development and maintenance challenges. Alam et al. [10] examined broader SWS development challenges using Stack Overflow and GitHub data across multiple workflow-system contexts. However, these studies did not examine nf-core as a broader maintenance and support ecosystem spanning issues, pull requests, and community forum discussions, nor did they analyze how user-facing support problems connect to repository-level maintenance work. Related empirical software engineering studies have mined GitHub issues, pull requests, and forum discussions to understand open-source maintenance, contribution acceptance, collaboration, and user support [25, 26, 28–32]. However, little is known about how these dynamics unfold in communitydriven scientific pipeline ecosystems, where maintenance problems often involve not only software defects but also workflow logic, containers, dependencies, reference data, HPC and cloud execution, reporting tools, and user configuration. In particular, we lack empirical evidence on what maintenance and support concerns dominate nf-core, how these concerns differ across repository-centered and community-centered spaces, which artifact-level characteristics are associated with resolution, and whether user-facing support problems are explicitly or implicitly connected to repository-level maintenance work. To address this gap, we present a cross-platform empirical study of maintenance and support in the nf-core ecosystem. We analyze 15,760 GitHub issues, 35,411 GitHub pull requests, and 895 Seqera Community Forum discussions. Methodologically, we combine topic modeling, manual topic interpretation, statistical outcome analysis, direct-link mining, semantic similarity analysis, technical-signal overlap analysis, and qualitative inspection. This design allows us to characterize what kinds of maintenance and support concerns arise, where they appear, how they are resolved, and how problems and solutions flow between repository-centered development spaces and community-centered support spaces. We investigate the following research questions (RQs):

• RQ1. What maintenance and support topics emerge across nf-core GitHub issues, pull requests, and Seqera Community Forum discussions? • RQ2. How do maintenance and support topics differ across GitHub issues, pull requests, and Seqera Community Forum discussions? • RQ3. What factors are associated with resolution outcomes across nf-core GitHub issues, pull requests, and Seqera Community Forum discussions? • RQ4. How do problems and solutions flow between repository-centered development spaces and community-centered support spaces? Our results show that nf-core maintenance and support are distributed across distinct but complementary spaces. GitHub issues primarily capture repository-level problem reporting and maintenance coordination, including execution failures, runtime diagnostics, container problems, reporting issues, testing gaps, linting behavior, and modernization requests. Pull requests capture implementation-oriented work, including module development, review, testing, dependency updates, template propagation, metadata management, input validation, and community infrastructure maintenance. Forum discussions capture user-facing support needs around pipeline execution, Nextflow dataflow, containers, cloud and HPC environments, MultiQC reporting, development tooling, and pipeline-specific troubleshooting. Resolution outcomes are shaped by actionability, coordination, and diagnostic evidence. Issue closure is associated with assignees, comments, milestones, bug labels, error mentions, and version information. Pull request integration varies by author role, automation group, draft status, linked issues, requested reviewers, checklists, and contribution-readiness signals. Forum accepted answers are more likely when discussions include code blocks, sustained community interaction, and concrete technical evidence, while cloud, HPC, and workflow-semantics questions are harder to resolve. Cross-platform analysis shows strong issue–pull-request traceability within GitHub but limited explicit linkage between forum discussions and GitHub artifacts, suggesting that many userfacing support problems remain only implicitly connected to repository-level maintenance work. This paper makes the following contributions:

• We provide a large-scale cross-platform empirical analysis of maintenance and support in a community-driven scientific pipeline ecosystem, using GitHub issues, pull requests, and Seqera Community Forum discussions from nf-core. • We develop a topic-based characterization of nf-core maintenance and support, showing how repository-centered and community-centered platforms expose different layers of ecosystem work.

• We analyze resolution outcomes across issues, pull requests, and forum discussions, identifying artifact-level features associated with issue closure, pull request integration, closed-without-merge outcomes, and acceptedanswer status. • We examine explicit and implicit problem–solution flow across platforms, showing strong repository-internal traceability within GitHub but weak explicit linkage between user-facing forum support and formal repository maintenance. • We derive actionable recommendations for improving documentation, issue and forum templates, cross-platform traceability, contributor workflows, review readiness, and infrastructure-specific support for containers, cloud, and HPC execution. By studying nf-core as a socio-technical scientific pipeline ecosystem, this work extends prior research on scientific workflow systems beyond workflow design and execution. It shows that the sustainability of reusable scientific pipelines also depends on how communities organize maintenance, support users, integrate contributions, preserve traceability, and translate recurring support problems into durable ecosystem improvements.

2 Background and Related Work This section situates our study in four areas of prior work: scientific workflow systems and pipeline sustainability, the nf-core ecosystem, repository mining for software maintenance, and community-support analysis. We then position our study by identifying the gap addressed by our cross-platform empirical design.

2.1 Scientific Workflow Systems and Pipeline Sustainability Scientific Workflow Systems (SWSs) are specialized platforms for designing, executing, and managing complex computational analyses, often organized as scientific pipelines [2]. They allow researchers to specify analytical steps, data dependencies, software requirements, parameters, and execution logic in a structured workflow rather than through ad hoc scripts or manual command sequences [7, 8, 33]. Examples include Galaxy [12], Nextflow [4], Snakemake [11], Pegasus [13], and Taverna [14]. By making workflow structure and dependencies explicit, SWSs support reproducibility, scalability, provenance tracking, and reuse across computational settings [9, 34–36]. However, workflow specification alone does not ensure long-term pipeline sustainability. Scientific pipelines depend on evolving tools, reference datasets, container images, package versions, executor profiles, cloud services, and HPC schedulers [8, 16]. A pipeline may therefore be well specified but still fail when dependencies change, containers become unavailable, input schemas evolve, or infrastructure-specific configurations no longer work. Sustaining pipelines requires continued maintenance of code, documentation, tests, configuration profiles, containers, reference resources, and user-facing guidance. This socio-technical view is central to our study. Users encounter workflows through concrete execution attempts, error messages, resource limits, installation problems, scheduler policies, cloud credentials, missing files, and unclear documentation. These problems become visible through maintenance and support artifacts: GitHub issues that report failures or request changes, pull requests that update and validate pipelines, and forum discussions that document user-facing troubleshooting. Analyzing these artifacts therefore helps explain how scientific pipeline sustainability is maintained after pipelines are released.

2.2 Nextflow and the nf-core Ecosystem Nextflow is a widely used SWS that supports scalable and portable execution through a dataflow programming model [4]. Its process–channel abstraction allows developers to define computational steps as independent processes and connect them through explicit data dependencies. This design enables the same pipeline logic to be executed across local machines, HPC schedulers, cloud platforms, and containerized environments. Nextflow also integrates with technologies such as Docker, Singularity/Apptainer, Conda, and cloud or batch execution backends, making it well suited for large-scale scientific data analysis [18]. nf-core builds on Nextflow by organizing pipelines, reusable modules, subworkflows, templates, test datasets, documentation, and development tools into a shared community ecosystem [1]. Rather than functioning as a collection of isolated repositories, nf-core provides common conventions for pipeline structure, review, testing, release, documentation, and execution. These conventions help standardize pipeline development, but they also create continuous maintenance demands as tools, dependencies, templates, containers, and execution environments evolve. This makes nf-core an appropriate empirical setting for our study. Its maintenance work includes conventional software-engineering activities, such as fixing bugs, reviewing pull requests, updating documentation, and managing dependencies. At the same time, it includes scientific-pipeline-specific work, such as updating

modules, validating sample sheets, maintaining container images, revising execution profiles, resolving referencedata problems, synchronizing templates, and supporting users across local, HPC, cloud, and managed execution environments. Because these activities are distributed across GitHub issues, pull requests, and community forum discussions, nf-core provides a rich setting for examining how community-driven scientific pipeline ecosystems are maintained and supported in practice.

2.3 Mining GitHub Artifacts for Software Maintenance GitHub has become a major source of socio-technical evidence for studying software maintenance. Prior studies have analyzed issues, pull requests, commits, and review discussions to understand collaboration, contribution evaluation, pull-based development, bug fixing, feature evolution, and software quality [25, 26, 31, 32, 37–40]. These studies show that repository artifacts capture both technical and social aspects of maintenance, including how contributors propose changes, how maintainers evaluate them, and which factors influence acceptance or delay. Repository mining is particularly useful in specialized technical domains, where maintenance challenges are shaped by domain-specific tools, assumptions, and execution contexts [10, 41–43]. In the nf-core context, Alam and Roy [3] analyzed GitHub issues and pull requests from pipeline repositories to characterize repository-level development and maintenance challenges. However, their analysis was limited to pipeline repositories. The present study examines the broader nf-core ecosystem, including pipelines, modules, tooling, configurations, infrastructure, and community-facing repositories, together with Seqera Community Forum discussions. It also compares the roles of issues, pull requests, and forum discussions, analyzes their artifact-specific resolution outcomes, and examines cross-artifact traceability and correspondence. This broader perspective captures maintenance concerns involving not only source-code defects, but also reusable components, test data, templates, containers, execution environments, and user support that may not be visible through pipeline repositories alone.

2.4 Community Support and Discussion Platforms Community support platforms play a central role in open-source ecosystems by capturing how users ask questions, report problems, share workarounds, clarify documentation, and learn from previous discussions. Prior studies have shown that user forums and discussion platforms support troubleshooting, knowledge sharing, onboarding, and collaboration beyond formal repository workflows [28, 29]. Such spaces are especially important when users encounter problems that are difficult to classify as software defects, such as environment-specific failures, installation issues, configuration errors, or uncertainty about expected behavior. For nf-core, community support is particularly important because successful pipeline execution depends on the interaction between pipeline definitions and their execution contexts. Users may encounter failures caused by Singularity or Apptainer image retrieval, Docker layer errors, Wave authentication, Conda environment creation, AWS Batch or Google Cloud configuration, Slurm queue policies, file permissions, memory limits, profile settings, reference-data paths, or incomplete logs. These problems directly affect whether users can run and trust pipelines, even when the pipeline code itself is correct. The Seqera Community Forum therefore provides a complementary perspective on nf-core maintenance by revealing practical user-facing problems that may not be visible in GitHub repositories alone. At the same time, support discussions can contain maintenance-relevant knowledge. Repeated forum questions may reveal documentation gaps, missing examples, confusing error messages, usability barriers, or pipeline defects. If these discussions are not linked to GitHub issues or pull requests, maintainers may miss opportunities to translate recurring support problems into durable repository-level improvements. This motivates our cross-platform analysis of whether and how problems and solutions flow between community support spaces and repository-centered development spaces.

2.5 Topic Modeling for Maintenance and Support Analysis Topic modeling is widely used to identify recurring themes in large collections of unstructured text, supporting document organization, information retrieval, recommendation, and software repository analysis [44–47]. Prior studies have applied topic modeling to understand developer and user challenges in domains such as quantum software engineering, cryptography APIs, open-source AI repositories, deep learning frameworks, desktop web applications, scientific workflow systems, Eclipse forums, and online discussion forums [10, 41–43, 48–54]. Traditional topic models such as Latent Dirichlet Allocation (LDA) and its variants (e.g., sLDA, CTM, RTM, DTM) have been extensively used for software text analysis [55]. However, these models often require a predefined number of topics, are sensitive to hyperparameter choices, and may produce incoherent topics when applied to short, noisy, and technical texts. BERTopic [56] addresses several of these limitations by combining transformerbased embeddings with clustering to generate more contextual and interpretable topics. Because GitHub issues, pull requests, and community forum posts often contain domain-specific terminology, short descriptions, code 5

fragments, logs, and noisy text, we utilize BERTopic for identifying maintenance and support topics in the nf-core ecosystem.

2.6 Research Gap Prior work has established the importance of SWSs for reproducible research and has described nf-core’s role in standardizing Nextflow pipelines [1, 7, 8, 57]. Empirical software engineering research has also shown that GitHub artifacts and support forums can reveal maintenance, collaboration, and user-support practices [25, 26, 28, 29]. However, we still lack empirical evidence on how maintenance and support are organized in a community-driven scientific pipeline ecosystem where problems span workflow code, reusable modules, containers, dependencies, reference data, execution profiles, cloud services, HPC schedulers, reporting tools, and user configuration. In particular, existing work does not explain: (i) what maintenance and support topics dominate nf-core across repository and community spaces; (ii) how these topics differ between GitHub issues, pull requests, and forum discussions; (iii) which artifact-level characteristics are associated with closure, merge, or accepted-answer outcomes; and (iv) whether user-facing support problems are explicitly or implicitly connected to repository-level maintenance work. Our study addresses this gap through a cross-platform empirical analysis of nf-core GitHub issues, pull requests, and Seqera Community Forum discussions. By treating these artifacts as complementary units of analysis, we examine maintenance and support as distributed ecosystem work rather than as isolated repository activity.

3 Study Design This study adopts a cross-platform empirical design to examine how maintenance and support are organized in the nf-core ecosystem. We analyze three complementary artifact types: GitHub issues, pull requests, and Seqera Community Forum discussions. These artifacts represent different layers of ecosystem activity. Figure 1 summarizes the overall research process, including data collection, preprocessing, topic modeling, cross-platform comparison, resolution analysis, problem–solution flow analysis, and synthesis of actionable improvements. Data Sources nf-core GitHub Pull Requests

nf-core GitHub Issues

Seqera Community Forum Discussions

Data Collection and Filtering Data preprocessing, metadata extraction, technical-signal construction

Shared Processing Pipeline

Shared Analytical Preparation topic-modeling corpus, resolution features, and cross-platform linkage features

RQ1 Topic discovery BERTopic modeling, coherence tuning, manual topic labeling

RQ4 Problem– solution flow direct links, semantic similarity, technicalsignal overlap

RQ2 Platform comparison topic distributions, shared concerns, platform-specific roles

RQ3 Resolution analysis outcome definitions, bivariate tests, multivariable and survival models RQ-Specific Analyses and Synthesis

Synthesis Actionable improvements documentation, templates, traceability, review and infrastructure support

Cross-platform empirical insights into maintenance and support in the nf-core ecosystem

Fig. 1: Overview of the study design for analyzing maintenance and support in the nf-core ecosystem.

3.1 Data Collection We collected artifacts from three sources: nf-core GitHub issues, pull requests, and Seqera Community Forum discussions. At the time of data collection on May 8, 2026, the nf-core ecosystem contained 191 GitHub repositories. Of these, 19 repositories were archived. As archived repositories are no longer actively maintained and may not reflect ongoing maintenance and support activity, we excluded them from the analysis. This resulted in 172 active repositories for GitHub data collection. To reduce right-censoring and allow artifacts sufficient time to receive responses or reach observable outcomes, we applied a one-month observation buffer. Accordingly, we included only GitHub issues, pull requests, and forum discussions created on or before April 8, 2026. This cutoff is important for the resolution-oriented analyses because artifacts created shortly before data collection may appear unresolved simply because maintainers, contributors, or community members have not yet had enough time to respond. From the 172 active repositories, 149 repositories contained at least one issue created on or before the cutoff date, yielding 15,763 GitHub issues for analysis. For pull requests, 164 repositories contained at least one pull request created on or before the cutoff date, yielding 36,521 pull requests. We utilized the GitHub REST API to collect issues and pull requests. However, some pull requests were directly associated with existing issues. Treating these linked pull requests as fully independent records could introduce redundancy, particularly when the same maintenance task was represented both as an issue and as an associated pull request. To reduce this duplication, following prior works [3, 10], we used the GitHub Search API to identify pull requests explicitly associated with existing issues and excluded 1,091 linked pull requests from the pull request dataset. After this filtering step, the final pull request dataset contained 35,430 pull requests. For community support data, we developed a custom Python script to collect discussions from the Seqera Community Forum. The initial forum dataset contained 957 discussions. Among them, 62 were categorized as events and announcements in the forum that were not directly related to maintenance or user support, including event-organizing posts, announcements, and general community updates. The remaining 895 forum discussions captured user facing problems and we utilized that for our analysis.

Table 1: Data-flow summary for artifact collection, filtering, and preprocessing Stage

Issues

Pull requests

Forum discussions

Artifacts collected after repository/date filtering After removing non-support forum discussions After linked-pull-request de-duplication Final topic-modeling corpus after text-quality filtering

15,763 15,763 15,763 15,760

36,521 36,521 35,430 35,411

957 895 895 895

Note. The linked-pull-request de-duplication step applies to the pull request corpus used for topic and outcome analyses. Explicit issue–pullrequest relationships identified during this step are retained as link evidence for the problem–solution flow analysis.

Table 1 reconciles the dataset counts used in the paper. We distinguish between collected artifacts, deduplicated analysis corpora, and final topic-modeling corpora to avoid ambiguity. Unless otherwise stated, RQ1–RQ3 use the final preprocessed corpora, while RQ4 uses explicit link records and semantic-flow candidates derived during the linkage analysis. The exclusion of issue-linked pull requests from the pull request analysis corpus does not remove issue–pull request relationships from the study; rather, these relationships are retained as explicit traceability evidence for RQ4, where the goal is to examine problem–solution flow across artifacts. Thus, linked pull requests are excluded only to reduce redundancy in topic modeling and pull request outcome analyses, while their associations with issues remain part of the cross-artifact linkage analysis.

3.2 Data Preprocessing We preprocessed textual content for topic modeling and separately retained metadata, structural indicators, and technical signals for outcome and flow analyses. This distinction is important because the requirements of topic modeling differ from the requirements of resolution analysis. Topic modeling benefits from reducing repeated syntax, markup, and boilerplate, while resolution analysis requires preserving whether artifacts contain code, URLs, errors, configuration details, or other diagnostic evidence. For topic modeling, we constructed one textual document for each artifact. For GitHub issues and pull requests, we concatenated the title and body fields. For Seqera Community Forum discussions, we concatenated the discussion title and rendered discussion content. We removed or normalized HTML markup, URLs, code fragments, command-line snippets, stack traces, configuration blocks, and other structured technical fragments to prevent topic representations from being dominated by repeated paths, commands, environment variables, or syntax tokens. 7

We then lowercased text, removed punctuation and non-alphabetic symbols, removed standard English stopwords [58], and removed high-frequency ecosystem terms such as nf-core, Nextflow, issue, and pull request. These terms identify the general study context but do not help distinguish one maintenance or support topic from another. Finally, we applied lemmatization using the spaCy en core web sm model [59]. Because technical fragments can contain meaningful diagnostic information in nf-core, we did not discard their presence from the overall analysis. Instead, we preserved structural and technical indicators as separate features, including code-block presence, URL presence, error mentions, version mentions, command mentions, system-information mentions, container terms, cloud terms, HPC terms, MultiQC terms, and reproduction-related terms. These features are used in RQ3 and RQ4 to analyze resolution outcomes and cross-platform technical-signal overlap. After preprocessing, in the issue dataset, we found three non-informative records: two issues had only numeric titles, and one issue contained only a URL in the title, with an empty body. We removed these three records, resulting in 15,760 GitHub issues for subsequent analysis. Similarly, we identified and removed 19 non-informative pull request records, resulting in 35,411 pull requests. In contrast, all retained forum discussions contained meaningful title and discussion content after preprocessing. The final topic-modeling corpus therefore consisted of 15,760 issues, 35,411 pull requests, and 895 forum discussions. It is important to note that this preprocessing was applied to the textual corpus used for topic modeling. For resolution-oriented analyses, we retained relevant metadata and structural indicators, such as labels, assignees, comments, requested reviewers, linked issues, draft status, reply counts, accepted-answer status, and the presence of code blocks or URLs. This separation allowed us to reduce textual noise for topic discovery while preserving artifact-level features needed to analyze maintenance and support outcomes.

3.3 Identifying Maintenance and Support Topics To answer RQ1, we applied BERTopic [56] separately to the issue, pull request, and forum corpora. We modeled three artifact types separately because each serves a different communicative role in the nf-core ecosystem. Issues are primarily used for problem reporting and maintenance coordination, pull requests for implementation and review, and forum discussions for user-facing troubleshooting. Separate modeling allowed platform-specific topic structures to emerge without forcing all artifacts into a single shared topic space. BERTopic represents documents as semantic embeddings before clustering them into topics. For each corpus, we generated embeddings using the all-mpnet-base-v2 sentence-transformer model, a fine-tuned MPNet model available through Hugging Face that produces 768-dimensional dense vectors optimized for semantic similarity, clustering, and semantic search [60–62]. This model is well suited for short, technical, and domain-specific texts because it captures semantic similarity beyond exact keyword overlap. We then reduced the embedding dimensions using UMAP, which preserves meaningful local structure in high-dimensional data [63], and clustered the reduced embeddings with HDBSCAN, a hierarchical density-based method that can identify clusters of varying density while treating weakly related documents as outliers [64]. This embedding–reduction–clustering pipeline allowed us to identify semantically coherent topics without predefining the number of clusters. We tuned BERTopic parameters separately for each artifact type to balance coherence, interpretability, and granularity. We explored UMAP settings for n neighbors between 15 and 60 and n components between 5 and 40, using cosine distance to align with sentence-transformer embeddings. For HDBSCAN, we varied min cluster size between 30 and 300 and used Euclidean distance on the UMAP-reduced embeddings. We evaluated topic quality using topic coherence, which measures semantic similarity among top topic terms and supports interpretability assessment [65]. We used unigram and bigram features in CountVectorizer, following prior software-engineering topic-modeling studies [3, 10, 42, 66]. The final topic models used in RQ1 produced 11 issue topics, 13 pull request topics, and 8 forum topics. BERTopic assigns the special label -1 to documents that do not fit clearly into any of the discovered topic clusters. This label is commonly used for outlier or mixed-topic documents whose semantic patterns are less coherent than those of the main clusters. Because the data had already been extensively preprocessed, we interpreted Topic -1 as a main topic category rather than excluding it as noise.

Manual topic validation. We validated topic interpretations through expert inspection. For each topic, the first author reviewed the top representative terms and at least 25 representative artifacts. This procedure was applied consistently across issues, pull requests, and forum discussions. Initial labels were assigned based on recurring technical concerns, artifact context, and representative examples. The proposed labels were then reviewed by co-authors with experience in SWSs, pipelines, and empirical software engineering. Borderline cases and ambiguous labels were discussed until

consensus was reached. The detailed process is described in section 4.1. We documented representative examples and rationale for topic labels in the replication package to support transparency and reproducibility.

3.4 Cross-Platform Topic Comparison To answer RQ2, we compared how maintenance and support concerns differ across GitHub issues, pull requests, and Community Forum discussions. Because topics were modeled separately for each artifact type, we did not force a one-to-one topic mapping. Instead, we compared topic names, representative terms, and representative artifacts to identify shared concerns and artifact-specific roles. Two authors with over five and nine years of experience with scientific pipelines independently reviewed the topic labels and representative artifacts to identify recurring cross-platform concerns, including execution failures, containers, documentation, testing, dependencies, configuration, MultiQC/reporting, modules/subworkflows, and HPC/cloud execution. We then summarized how each concern appeared in each artifact type. For example, execution failures may appear in issues as runtime bug reports, in pull requests as fixes or tests, and in forum discussions as troubleshooting questions. Disagreements were resolved through discussion. This comparison allowed us to interpret the three artifact types as complementary views of nf-core maintenance and support rather than interchangeable text sources.

3.5 Resolution Outcome Analysis To answer RQ3, we defined artifact-specific resolution outcomes because issues, pull requests, and forum discussions follow different workflows. For GitHub issues, we measured closure status and time-to-close, computed from issue creation to closure, with open issues treated as censored in time-to-event analyses. For pull requests, we measured whether a pull request was merged, closed without merge, or remained open, along with time-to-merge and time-to-final-decision; open pull requests were treated as censored in lifecycle analyses. For forum discussions, we used accepted-answer status as the explicit support-resolution indicator. Because accepted-answer timestamps were unavailable, we used activity span, measured from discussion creation to last activity, as an exploratory lifecycle proxy rather than as exact time-to-answer. We organized explanatory features into three groups to avoid causal or predictive overinterpretation. Submission-time features are available from the initial artifact text or metadata, such as title/body text, author type, labels present at collection, code blocks, URLs, errors, versions, commands, container terms, cloud terms, HPC terms, and topic assignment. Process features are created as the artifact is handled, such as comments, assignees, milestones, requested reviewers, replies, likes, and review-routing indicators. Outcome-adjacent features are close to the resolution process itself, such as accepted-answer discussion activity or final review state. We therefore interpret all RQ3 results as associations observed over the artifact lifecycle, not as causal effects or purely submission-time predictions. We first summarized outcome rates and lifecycle distributions for each artifact type. We then conducted bivariate analyses to examine associations between artifact features and outcomes [67]. For binary features, we used contingency-table analyses [68] and reported odds ratios where appropriate. For numeric features, we used nonparametric comparisons and effect sizes because comments, replies, views, and resolution times were highly skewed. We applied Benjamini–Hochberg [69] false-discovery-rate correction for multiple comparisons. We then fitted multivariable models to examine whether associations remained after accounting for other artifact characteristics. For issues, we used logistic regression for closure and Cox proportional hazards models for time-to-close [70, 71]. For pull requests, we used logistic and regularized logistic models for merge and closedwithout-merge outcomes [72]. For forum discussions, we used regularized logistic regression for accepted-answer status. In addition, we used Kaplan–Meier curves [73] for all three artifact types to visualize lifecycle differences across selected binary features. For issues, the event was issue closure; for pull requests, the event was a final decision, either merged or closed without merge; and for forum discussions, the event was receiving an accepted answer, using activity span as an exploratory proxy because exact accepted-answer timestamps were unavailable. Continuous predictors were log-transformed where appropriate to reduce skew and standardized before multivariable modeling; binary predictors were encoded as 0/1. Sparse categorical levels were collapsed, and constant, duplicate, or highly correlated predictors were removed before fitting. For regularized logistic models, we used L1 regularization to handle sparse and correlated predictors and treated coefficients as adjusted directional associations rather than formal significance tests. We report odds ratios, hazard ratios, confidence intervals where available, adjusted p-values where applicable, and effect sizes to avoid relying only on statistical significance. For Cox models, we checked proportional-hazards assumptions and interpret results cautiously when assumptions were imperfect. Full model specifications and robustness checks are included in the replication package.

3.6 Problem–Solution Flow Analysis To answer RQ4, we examined how problems and solutions are connected across issues, pull requests, and forum discussions. We analyzed both explicit traceability and weaker implicit relatedness. Explicit links provide direct evidence of cross-artifact relationships, while semantic similarity and shared technical signals identify candidate relationships that require cautious interpretation. We first extracted explicit references from artifact text. These included GitHub issue URLs, pull request URLs, forum URLs, GitHub-style references such as #123, and pull request closing-keyword references such as fixes, closes, and resolves. Closing-keyword references were treated as stronger evidence of problem–solution flow because they indicate that a pull request is intended to address a specific issue. We resolved extracted references against the collected artifacts and classified the resulting relationships by source and target artifact type, such as pull request-to-issue, issue-to-pull request, forum-to-GitHub, and GitHub-to-forum. Because many related artifacts may not be explicitly linked, we also examined implicit relatedness between issues and pull requests. We represented artifact text using TF–IDF features and computed cosine similarity between candidate cross-artifact pairs. We removed directly linked pairs before semantic analysis so that the semantic-flow results would capture additional candidate relationships rather than rediscover known links. We then applied temporal constraints to identify plausible issue-to-pull-request sequences and pull-request-before-issue sequences. These pairs are interpreted as candidate semantic flows, not definitive causal links. To reduce overinterpretation, we validated a sample of semantic-flow candidates through manual inspection. Candidate pairs were classified as exact or strongly related, broadly related, weakly related, or unrelated. Exact or strongly related pairs discuss the same problem and likely implementation response; broadly related pairs share a technical concern but do not show clear problem–solution continuity; weak or unrelated pairs share vocabulary but do not provide meaningful evidence of flow. We report these validation results in RQ4 and use them to qualify the strength of the semantic-flow interpretation. We also extracted shared technical signals across artifact types, including execution errors, workflow execution, containers, cloud, HPC, MultiQC/reporting, testing/linting, documentation/training, dependency updates, template synchronization, modules/subworkflows, configuration, and channel/dataflow concerns. Signal overlap helps identify recurring problem domains that appear across issues, pull requests, and forum discussions even when artifacts are not directly linked. Together, direct links, semantic-flow candidates, manual validation, and signal overlap allow us to characterize both visible traceability and weaker thematic connections between community support and repository maintenance.

4 Results 4.1 RQ1: Maintenance and Support Topics 4.1.1 Motivation Maintenance and support for nf-core span multiple artifact types, but the recurring concerns discussed in these spaces have not been systematically characterized. GitHub issues, pull requests, and Seqera Community Forum discussions capture different forms of ecosystem activity: users and maintainers report problems and coordinate maintenance tasks, contributors implement and review changes, and community members seek help with execution, configuration, containers, cloud/HPC environments, reporting, and Nextflow behavior. Without first identifying the topics that appear in these artifacts, it is difficult to understand what kinds of problems users encounter, what kinds of maintenance work contributors perform, and which support needs emerge outside repository-centered development. RQ1 therefore establishes the empirical foundation of the study by identifying the main maintenance and support topics across nf-core issues, pull requests, and forum discussions.

4.1.2 Approach To identify maintenance and support topics, we applied BERTopic separately to the preprocessed issue, pull request, and forum corpora, as described in Section 3.3. The modeling process yields 11 topics for issues, 13 topics for pull requests, and 8 topics for forum discussions, along with representative keywords and documents for each topic. We then manually assigned meaningful and contextually accurate labels to the discovered topics. Following established practices in prior studies [3, 10, 42, 49, 74–76], the first author proposed initial topic labels based on the top representative keywords and a manual review of at least 25 representative artifacts per topic. The first author has over five years of experience working with nf-core pipelines and more than a decade of professional software development experience. The proposed labels were then reviewed and refined through discussions with another author with over nine years of experience in scientific pipeline research and an additional expert with 10

more than two decades of experience in empirical software engineering. Ambiguous labels and borderline cases were discussed until consensus was reached. This manual validation helped ensure that the final labels reflected both the topic-model output and the domain-specific context of nf-core maintenance and support.

4.1.3 Results of RQ1 RQ1 identifies distinct but complementary maintenance and support topics across the three artifact types. As shown in Tables 2, 3, and 4, GitHub issues, pull requests, and forum discussions expose different layers of nf-core ecosystem work. Table 2: Maintenance and support topics identified from nf-core GitHub issue discussions. SL Topic Name

Representation

Pipeline Execution and Debugging Support

Module Development, Updates, and Migration

Sequencing, Alignment, and Genome Reference Support

pipeline, output, version, command use, add, relevant file, description feature, module, file response, check work module, exist module, open search, module search, exist open, planning, track work, add facilitate, issue information genome, sequence, read, add, description feature, variant, module, propose pipeline, support, alignment

Pipeline Tooling, Documentation, and Feature Support

Subworkflow Testing and nf-test Migration

Runtime Bugs and Diagnostics Reports

Container Images and Runtime Environment Failures

MultiQC Reporting and Quality-Control

Pipeline Test Infrastructure and CI Validation

Pipeline Modernization and Template Migration

Concise Description with Examples

This topic captures running and debugging issues, including command-line errors, execution failures, unexpected outputs, version warnings, and relevant-file inspection. Examples include Run cannot start due to "Unknown option", which reports a pipeline failure caused by an unrecognized option, and Pipeline line warns igenomes-related files missing, despite specifying skip features, which describes an unexpected iGenomes-related warning in nf-core/taxprofiler. This topic represents coordination issues around module-level work, including new module requests, searches for existing implementations, module updates, and migration to newer nf-core standards. For example, issues to propose new modules such as new module: FASTQDL, track implementation progress, improve existing module behavior such as Improve module specific resource requests, or coordinate standardization work such as migrate phispy to nf-test. This topic focuses on sequencing and genome-resource issues, including reference genomes, sequencing reads, alignment steps, variant processing, and database inputs. Examples include Reference genome downloaded for each sample, which concerns repeated reference-genome handling in nf-core/methylseq; bwameth index creation fail, which reports an indexing failure while using the bwameth aligner; and No variant calling jobs if bait padding is set to zero, where nf-core/raredisease skips DeepVariant jobs and then runs GLnexus without VCF inputs, causing the pipeline to crash. update, documentation, This topic captures tooling, documentation, and feature-support issues, including feature, pipeline, make, pipeline-download problems, missing documentation, tooling behavior, and module, browser, usability-focused requests. For example, nf-core pipeline downloads issues when community, template, downloading pipelines for --platform reports bugs in nf-core/tools when downloading rfc pipelines for Seqera Platform use; Missing instruction on how to update nf-core tools in Tools documentation identifies a documentation gap; and Add support for giving NCBI acc2tax files to MALT databases requests support for providing NCBI accession-to-taxonomy files during MALT database construction. subworkflow, nftest, This topic highlights subworkflow testing, validation, installation, and migration to module, test, feature nf-test. Examples include Subworkflow install is not properly finding modules with relate, additional " ", which reports missing module downloads during subworkflow installation; Migrate all subworkflows to nf-test, which tracks the transition to nf-test; and Add ability to context, problem, install a subworkflow composed nf-core and non-nf-core modules/subworkflows, which response alternative, requests more flexible subworkflow installation support. create, update description bug, This topic focuses on runtime bugs and diagnostic reports supported by version details, version, run, terminal commands, terminal output, relevant files, and system information. Examples include output, pipeline, Sarek possibly supplying the wrong number of args for relevant file, CONTROLFREEC ASSESSSIGNIFICANCE? in nf-core/sarek, which reports a Control-FREEC information, check, step runtime failure involving R-script arguments, Slurm, and Singularity. singularity, image, This topic covers containerized runtime environments, including Singularity/Apptainer, container, version, Docker images, image downloads, offline execution, and executor-related failures. pipeline, description Examples include Issue with pulling singularity images in nf-core/rnafusion, docker: bug, docker image, use failed to register layer: Error processing tar file in nf-core/rnaseq, and Change terminal, output, devcontainer to install tools at current commit in nf-core/tools. response information multiqc report, plot, This topic centers on generating, extending, and correcting quality-control reports, add, description especially MultiQC summaries, plots, statistics, and pipeline-specific reporting behavior. feature, table, Examples include Increase the number of decimal points in MultiQC reporting of summary, qc, stat, Endogenous DNA in nf-core/eager, which requests more precise reporting of endogenous DNA generate, pipeline values, and SortMeRNA stats in MultiQC report are reported for read2 in nf-core/rnaseq, which reports unexpected read-specific SortMeRNA statistics in the MultiQC output. datum, description This topic captures test infrastructure for validating nf-core pipelines, modules, and feature, test dataset, subworkflows, including test datasets, CI profiles, stub runs, runtime optimization, and add test, pipeline, ci test-configuration tooling. Examples include Move the test data into a new repository test, test profile, create, and set up clones, which proposes moving bundled test data into a separate repository aws, stub for easier testing; Reduce run time of CI tests, which discusses reducing long continuous-integration runtimes through test-profile or parallelization changes. migrate, version, This topic highlights migration to newer nf-core conventions, including template pipeline, template, local migration, local-module replacement, nf-test adoption, version compatibility, schema module, nftest, replace, changes, and pipeline modernization. Examples include Update lint checks for rfc, update modules testdata base path and pipelines testdata base path, which discusses improving parameter-related lint checks, and Make utils nfcore <pipeline> pipeline subworkflow nfcoremodule, feature nf-core linting compliant or do not lint file, which reports linting problems in local add subworkflow templates. Continued on next page

Table 2: Maintenance and support topics identified from nf-core GitHub issue discussions. SL Topic Name

Representation

Concise Description with Examples

lint, pipeline, module, check, description bug, sync, terminal output, information, run, template branch

This topic focuses on nf-core linting and automated template checks across pipelines, modules, and subworkflows. Examples include Update lint checks for modules testdata base path and pipelines testdata base path and Make utils nfcore ¡pipeline¿ pipeline subworkflow nf-core linting compliant or do not lint file.

Automated Linting and Template Compliance

Note. Topic names were assigned based on BERTopic representations and inspection of representative issue discussions.

GitHub issues capture problem reporting and maintenance coordination. The issue topics show that GitHub issues are the primary repository-centered space for surfacing pipeline problems, requesting changes, and coordinating maintenance work. Several topics concern user-visible execution and runtime problems, including pipeline execution failures, debugging support, runtime bug reports, container-image failures, MultiQC reporting problems, and genome-reference handling. These topics suggest that issues often translate observed pipeline failures into repository-level concerns that can be discussed, triaged, and potentially converted into maintenance tasks. Issues also capture coordination around reusable nf-core components and shared ecosystem standards. Topics related to module development, subworkflow testing, nf-test migration, CI validation, template migration, and automated linting show that issues are used to plan and track work that affects pipelines, modules, subworkflows, templates, and testing infrastructure. Thus, issue discussions are not limited to conventional bug reports; they also support planning, standardization, migration, validation, and documentation-oriented maintenance across the nf-core ecosystem. Table 3: Maintenance and support topics identified from nf-core GitHub pull request discussions. SL Topic Name

Representation

Concise Description with Example

Module Development and Quality Assurance

Pipeline Documentation, Testing, and Template Alignment

This topic captures pull requests that extend and validate the nf-core module ecosystem. It includes adding new modules, updating existing modules, integrating test data, standardizing module inputs and outputs, and validating modules through container-based CI. Examples include pull requests adding modules such as BUSCO and gatk4/splitcram, as well as updating antismashlite outputs with nf-core checklist requirements for tests, documentation, naming conventions, and parameters. This topic highlights pipeline- and ecosystem-level pull requests that align nf-core pipelines with community expectations for documentation, tests, outputs, templates, and usability. Examples include epitopeprediction pull requests for template updates, Zenodo link fixes, and empty prediction-result fixes; airrflow pull requests adding nf-test, merging template updates, and addressing minor bugs; and website pull requests updating ByteSize links, pipeline buttons, and interface spacing.

Module Review, Linting, and Interface Validation

Routine Maintenance and Reliability Improvements

add test, module, new tool, convention, make, comment, documentation update, change reason, contain description, fix bug documentation update, new tool, add test, nfcoretestdataset repository, make lint, repository make, follow pipeline, output documentation, update include, update output requirement, module, test add, option guideline, follow parameter, input-output option, naming convention, docker singularity, quite flaky add test, comment contain, change reason, documentation update, fix bug, module, lint, file, make

Template Update Propagation Across Pipelines

Contribution Checklist and Review Preparation

This topic captures pull request work on validating nf-core modules against review requirements, including linting, input/output definitions, parameter conventions, test data, documentation, and container compatibility. Examples include pull requests, nf-core/modules update arriba, nf-core/sarek Fix linte, and nf-core/tools add module linting condition, which address module conventions, deprecated parameters, tests, linting, and tooling support for module validation.

This topic captures routine pull requests that improve nf-core reliability across tools, pipelines, websites, configurations, and test-data repositories. It includes bug fixes, documentation updates, lint adjustments, parameter handling, test-data support, and usability improvements. Examples include nf-core/tools pull requests such as Dump pipeline parameters into a json file, Add singularity note for offline use, and Remove params.enable conda, which support JSON parameter export, offline Singularity guidance, and updated Conda configuration practices. It also includes smaller pipeline or website fixes, such as correcting module specification text. nfcoretool template, This topic covers pull requests that propagate shared nf-core template and tooling updates automate attempt, across existing pipelines. Such changes often require maintainers to apply template updates, apply relevant, make resolve merge conflicts, update pipeline files, refresh documentation, and keep pipelines resolve, branch fork, aligned with the current nf-core/tools release. Examples include repeated Template resolve conflict, instruc- update nfcoretool pull requests in pipelines such as eager, crisprseq, and proteomicslfq; tion information, nf-core/tools pull requests such as [FIX] Missing r-markdown dependency, which fixes a complete make, new missing template dependency; and follow-up template-merge changes such as Some more minor, update pipeline tweaks from the final rnaseq template merge. contribute, update This topic represents pull requests structured around the nf-core contribution checklearn, appropriate list for review preparation. These include documenting change rationale, identifying delete, relevant combug fixes or tool additions, adding tests, updating usage/output documentation, linking mon, thing comment, nf-core/test-datasets branches, and running checks. Examples include nf-core/rnaseq lint documentation, pull requests rnaseqconfig and dupradar fusion, nf-core/scrnaseq Fix time limits, add test, necesand nf-core/tools Don’t pin nf-validation plugin version whose bodies contain these sary make, branch review-preparation checklist items. nfcoretestdataset, fix Continued on next page

Table 3: Maintenance and support topics identified from nf-core GitHub pull request discussions (continued). SL Topic Name

Representation

config, directory add, custom profile, file toplevel, step, cluster, target branch, relevant issue, include link, submit work

Execution Profile and Infrastructure Configuration

Concise Description with Example

This topic highlights pull requests that add or update nf-core execution profiles and infrastructure-specific configurations, including custom profiles, cluster settings, cloud/batch definitions, GPU behavior, and Singularity or executor options. Examples include new configuration-profile submissions such as googlebatch and pawsey nimbus; Azure Batch pool configuration in nf-core/test-datasets; GPU profile fixes across Docker, Singularity/Apptainer, Slurm, AWS Batch, Google Cloud, and Kubernetes; and pipeline-level configuration changes in nf-core/methylseq and nf-core/rnafusion. Community netlify, project, local This topic captures pull requests that maintain nf-core’s community-facing infrastrucInfrastructure site, hackathon, group, ture, including website content, documentation pages, event and hackathon resources, local and Website update, registration, hub information, registration workflows, ByteSize materials, and Netlify-backed deployMaintenance time ment behavior. Examples include nf-core/website pull requests such as Add high-level section in style-guide.md, yt and figshare link for bytesize precommit, and identify busy netlify functions. Automated rebase retry, compare This topic focuses on pull requests that maintain nf-core’s automated repository workflows Dependency source, dependand development dependencies, including Renovate/Dependabot updates, GitHub Actions and Reposiabot, update, define updates, pre-commit hook updates, Docker/devcontainer digests, automation schedules, tory Workflow automerge, time sched- linting support, and template-related workflow checks. Examples include nf-core/tools Maintenance ule, branch creation, pull requests such as Update GitHub Actions, Update astral-sh/setup-uv action to v8, and repository job, generate Update actions/checkout action to v6. mend, renovate view Reference Data file, add, genome, This topic highlights pull requests that add, update, or fix reference and alignmentand Alignment sequence, alignment, related data resources used to validate nf-core pipelines and modules, including genome Test Resources test datum, bam, files, sequence inputs, BAM/alignment files, database files, and test datasets. Examples dataset, include include nf-core/test-datasets pull requests such as Replace corrupted sample url file and Salmon results set for tximport testing, as well as module and pipeline updates such as nf-core/modules pull requests for update datavzrd and fix bismark & bwameth align fasta symlink for multiple samples. Runtime Envi- conda, singularity, This topic represents pull requests that maintain software environments used by nf-core ronment and dependency, test, modules and pipelines, especially Conda references, Docker/Singularity container images, Container schedule, docker image, BioContainers tags, dependency pinning, and container-related test behavior. Examples Dependency automerge, tag, update include nf-core/tools pull requests such as Fix conda environment reference and Download: fix Seqera container support - Patch 1; nf-core/methylseq pull requests updating the bwameth container image version; and nf-core/modules updates involving BioContainers Docker tags and module container versions. Subworkflow update json, documen- This topic focuses on pull requests that integrate or refine subworkflows and update Integration tation update, tool, pipeline metadata, documentation, JSON/schema files, test data links, and output descripand Pipeline automate, test add, tions needed to make new pipeline functionality reviewable and reproducible. Examples Metadata subworkflow, repository include the nf-core/viralrecon pull request Add Minimap2, seqwish and vg variant calling Management make, pipeline conven- for all assemblers and the nf-core/taxprofiler pull request Fix MultiQC mixing, where tion, nfcoretestdataset changes involve subworkflow-level functionality, output documentation, test additions, and repository, include new pipeline-convention updates. Sample Sheet test dataset, module, This topic reflects pull requests focused on validating pipeline inputs through samand Input file, samplesheet, add ple sheets, FASTA references, read files, and pipeline-specific test cases. Examples Validation datum, pipeline, read, include nf-core/methylseq pull requests such as Create a test for samplesheet with testdataset, new, need technical replicates, which adds test coverage for sample sheet handling, and Add fastqc outputs for testing MultiQC, which supports downstream report testing. It also includes nf-core/test-datasets updates such as Added lima and refine samplesheets to test injection points individually, which extend test resources for validating pipeline input behavior. Note. Topic names were assigned based on BERTopic representations and inspection of representative pull request discussions.

GitHub pull requests capture implementation, review, and integration work. Pull request topics represent the implementation side of nf-core maintenance. Table 3 shows how maintenance needs become reviewable changes to modules, pipelines, documentation, tests, templates, dependencies, execution profiles, reference data, metadata, and community infrastructure. Topics such as module development and quality assurance, module review and linting, sample-sheet validation, runtime-environment dependency updates, and subworkflow integration show that pull requests are the main mechanism through which nf-core changes are tested, reviewed, standardized, and integrated. The pull request topics also reveal ecosystem-level maintenance mechanisms that are less visible in issue or forum discussions. Template propagation, automated dependency updates, contribution checklists, repository workflow maintenance, and CI-related changes show how nf-core keeps many repositories aligned with shared conventions. This indicates that pull requests are not only responses to individual problems; they also sustain the infrastructure and standards that make nf-core pipelines reusable and maintainable across the ecosystem. Forum discussions capture user-facing support and execution contexts. Forum topics (4) differ from GitHub topics by foregrounding practical user-support needs. Many discussions concern running, debugging, and configuring pipelines in real execution environments. Users ask about failed runs, incomplete logs, version-specific behavior, dataflow and channel behavior, output propagation, container setup, dependency resolution, cloud and batch execution, HPC scheduling, and resource allocation. These topics capture operational problems that may not immediately appear as repository issues or pull requests, especially when the problem depends on the user’s execution environment. 13

Table 4: Maintenance and support topics identified from Seqera Community Forum discussions. SL Topic Name

Representation

Pipeline Execution and Debugging Support

run, error, try, workflow, script, path, batch, make, version

Dataflow, Channels, and Output Propagation

Quality-Control Reporting and Result Visualization

Containerized Runtime Environments and Dependency Resolution

Cloud and Batch Execution Support

Nextflow Development Tooling and Syntax Support

PipelineSpecific Runtime Errors and Version Issues HPC Execution, Process Scheduling, and Resource Allocation

Concise Description with Example

This topic centers on forum discussions where users seek help running, configuring, and debugging nf-core pipelines. These discussions often involve runtime errors, scripts, file paths, version-specific behavior, empty or incomplete logs, and uncertainty about failed tasks. Examples include Workflow execution completed unsuccessfully?, where a pipeline fails on Seqera Platform despite running from the command line, and How to debug a task in the context of Fusion, which asks how to inspect a failed task under Fusion-enabled execution. channel, output, This topic focuses on how data move through Nextflow and nf-core workflows, including channels, workflow, tuple, tuples, operators, process inputs and outputs, file collection, workflow-level outputs, and operator, collect, publishing behavior. Examples include Using workflow outputs to publish files from a nested input file, resume map channel, Stage single input for multiple instances of one process, and Multi-channel output cannot be applied to operator combine for which argument is already provided. table, plot, This topic represents discussions about generating, extending, and troubleshooting MultiQC report, MultiQC-based reporting in nf-core and Nextflow pipelines, including custom tables, plots, custom content, HTML content, images, Picard metrics, workflow-status summaries, and report-layout behavior. generate, HTML, Examples include Include nextflow workflow status information in MultiQC report, Picard Picard, include QualityYieldMetrics does not display all data in QC report, and Pandoc fails to convert html to pdf in the presence of a unicode ≥ sign. Singularity, This topic centers on configuring and troubleshooting software environments used to run nf-core image, Wave, and Nextflow pipelines, especially Singularity/Apptainer images, Docker images, Wave pipeline, Docker containers, Conda environments, private registries, and container-related execution behavior. image, Conda, Examples include Single Seqera container failing to build, Wave cannot connect with my directory, module, Seqera access token, and Are container pulls and conda environment creations counted in container, realtime in a nextflow trace?. platform AWS Batch, run, This topic highlights discussions about running nf-core and Nextflow pipelines on cloud and pipeline, compute managed batch infrastructures, especially AWS Batch, Google Cloud, Seqera Platform compute environment, environments, job queues, storage permissions, Fusion, Wave, and cloud-execution logs. error, job, log, Examples include Job failing in GCP due to no CredentialsProvider, Unable to run the Google, cloud submitted job through AWS batch with Seqera listed firewall configuration IP, and Issue with nf-core/taxprofiler Pipeline Stuck in Runnable Status on AWS Batch. VSCode, This topic centers on tools and configurations used to develop, validate, and debug Nextflow or extension, nf-core workflows, including VSCode extension behavior, language-server initialization, linting, language server, strict syntax, Gradle library support, nf-test installation, and development-environment config, linter, configuration. Examples include Importing Nextflow as a library in Gradle no longer strict syntax, supported?, Nftest installation, and Codespace running in recovery mode due to a block, pipeline, configuration error. define pipeline, run, This topic centers on runtime problems in specific nf-core pipeline contexts, often involving error, version, version-dependent behavior, failed jobs, data handling, pipeline steps, and execution differences sequence, rnaseq, across environments. Examples include Own variant calling nextflow pipeline - error with job, data, GRCh, Variant Recalibrator. Argument resource is missing, MultiQC does not find picard step rnaseqmetrics files, and Final step of my pipeline halts successfully after 1 sample. run, process, This topic focuses on running Nextflow and nf-core pipelines on HPC and cluster environments, submit, number, especially Slurm job submission, executor behavior, process parallelism, CPU and memory GB, cluster, HPC, directives, queue limits, GPU use, and resource-allocation failures. Examples include limit, executor, nf-core/rnaseq v3.18.0 -- Minimum-55-CPU rule, account suspensions & debug-queue limits, Slurm job Assistance Needed for Configuring SLURM to Utilize GPUs in VM for AlphaFold, and Slurm requiring multiple resumes for pipeline advancement.

The forum also captures support needs around Nextflow development and reporting. Discussions about development tooling, strict syntax, nf-test installation, MultiQC reports, custom visualizations, and pipeline-specific runtime errors show that users need help both in running standardized nf-core pipelines and in developing or adapting workflow logic. Compared with GitHub issues and pull requests, the forum provides a more direct view of the barriers users encounter when applying nf-core and Nextflow pipelines across heterogeneous computational environments.

Summary of RQ1. RQ1 shows that maintenance and support in nf-core extend beyond correcting sourcecode defects. GitHub issues expose repository-level problems and coordination needs; pull requests implement, validate, and integrate maintenance changes; and forum discussions surface user-facing execution and infrastructure problems. Together, the topics show that sustaining nf-core requires continuous work on modules, tests, templates, documentation, containers, dependencies, execution profiles, reporting outputs, and support for users running pipelines across heterogeneous environments.

4.2 RQ2: Cross-Platform Differences in Maintenance and Support Topics 4.2.1 Motivation RQ1 identifies the maintenance and support topics that emerge within each artifact type. However, identifying topics separately does not show how maintenance work is distributed across the nf-core ecosystem. GitHub issues, pull requests, and Community Forum discussions play different but complementary roles: issues surface problems and maintenance needs, pull requests implement and validate changes, and forum discussions capture user-facing

execution support. Comparing topics across these spaces is therefore necessary to understand which concerns are handled through repository-centered development and which concerns emerge primarily through communitycentered troubleshooting. RQ2 examines these differences to characterize the division of maintenance and support work across nf-core GitHub artifacts and community forum discussions.

4.2.2 Approach To compare topics across artifact types, we used the topic labels and representative artifacts identified in RQ1. Because the topic models were trained separately for issues, pull requests, and forum discussions, we did not impose a one-to-one topic mapping. Instead, two authors with over five and nine years of experience with scientific pipelines research compared topic names, representative keywords, and representative artifacts to identify shared maintenance and support concerns that appeared across artifact types. These concerns included execution failures, containers and runtime environments, documentation and training, testing and validation, dependency updates, templates, modules and subworkflows, reporting outputs, configuration, and HPC/cloud execution. We then examined how each shared concern appeared in each artifact type. For example, execution failures may appear in issues as runtime bug reports, in pull requests as fixes or tests, and in forum discussions as troubleshooting questions. Similarly, container concerns may appear in issues as image-pull failures, in pull requests as container or dependency updates, and in forum discussions as runtime setup questions. This comparison treats issues, pull requests, and forum discussions as complementary evidence sources rather than interchangeable text records.

4.2.3 Results of RQ2 RQ2 shows that similar maintenance and support concerns take different forms across the nf-core ecosystem. Table 5 summarizes these differences. GitHub issues primarily capture reported problems and coordination needs; pull requests capture implementation and integration work; and forum discussions capture user-facing execution and troubleshooting contexts.

Table 5: Cross-artifact mapping of shared maintenance and support concerns in nf-core. Concern

GitHub issues

GitHub pull requests

Execution failures

Runtime bug reports, failed runs, command errors, unexpected outputs, and diagnostic logs. Docker, Singularity/Apptainer, image-pull failures, offline execution, and runtime-environment problems.

Fixes, tests, validation changes, and pipeline behavior updates.

Containers and runtime environments Documentation and usability

Testing and validation Modules and subworkflows Templates and standards Reporting and outputs HPC and cloud execution

Forum discussions

Troubleshooting failed runs, interpreting logs, debugging tasks, and understanding runtime behavior. Container image updates, Runtime setup questions Conda references, BioContainers involving Docker, tags, dependency pinning, and Singularity/Apptainer, Wave, container-related tests. Conda, private registries, and platform execution. Missing or outdated Documentation updates, output Usage confusion, requests for documentation, tooling documentation, explanation, training-related behavior, feature requests, and template-aligned docs, and questions, and guidance for user-facing guidance gaps. website/community content applying nf-core or Nextflow changes. features. CI failures, test datasets, stub New tests, nf-test adoption, Questions about nf-test, output runs, nf-test migration, linting, module validation, CI updates, correctness, development and validation gaps. checklists, and review-readiness tooling, and workflow validation evidence. behavior. Requests for new modules, Module implementation, Questions about adapting module updates, subworkflow subworkflow integration, workflow logic, process behavior, testing, migration, and reusable- interface validation, metadata channels, tuples, and outputs. component coordination. updates, and quality assurance. Template migration, lint Template propagation, Less prominent; appears failures, schema changes, and repository synchronization, indirectly through user compliance with nf-core checklist compliance, and confusion about expected conventions. standardization changes. behavior or development setup. MultiQC report problems, Output documentation, MultiQC customization, report plots, tables, statistics, and MultiQC-related fixes, report generation, visualization, quality-control output issues. test data, and reporting HTML/PDF output, and integration changes. reporting interpretation. Configuration problems, Execution profiles, cluster/cloud User support for Slurm, AWS executor behavior, resource configuration, GPU settings, Batch, Google Cloud, Seqera limits, and infrastructureand infrastructure-specific pull Platform, queues, storage, specific issue reports. request changes. credentials, and resource allocation.

GitHub issues emphasize problem reporting and maintenance coordination. GitHub issue topics show where nf-core users and maintainers identify problems, request changes, and coordinate maintenance work. Issues contain runtime failures, debugging reports, container-image problems, genome-reference issues, MultiQC reporting problems, linting failures, template migration requests, and test-infrastructure concerns. These topics indicate that issues often function as a repository-centered entry point where user-visible problems are translated into maintainable tasks. Issues also support coordination around reusable components, including module development, subworkflow testing, nf-test migration, and ecosystem-wide standardization. GitHub pull requests emphasize implementation, review, and integration. Pull request topics are more implementation-oriented. They capture the concrete changes through which nf-core maintenance work is performed, including module development, test additions, documentation updates, dependency updates, template propagation, execution-profile changes, sample-sheet validation, metadata updates, and community-infrastructure maintenance. Pull requests therefore represent the integration layer of the ecosystem: they convert maintenance needs into reviewable changes that can be tested, standardized, and merged. Compared with issues, pull requests more directly expose nf-core’s review and quality-assurance practices, including contribution checklists, linting, interface validation, CI updates, and automation. Forum discussions emphasize user-facing support and execution contexts. Forum discussions differ from GitHub artifacts by foregrounding practical support problems encountered during pipeline use. Forum topics include pipeline execution failures, Nextflow dataflow and channel behavior, container and dependency resolution, MultiQC reporting, cloud and batch execution, HPC scheduling, resource allocation, and development-tooling questions. These discussions often involve local or infrastructure-specific context that may not immediately correspond to a repository defect. The forum therefore exposes operational barriers that arise when users run nf-core or Nextflow workflows across local, cloud, HPC, containerized, and managed execution environments. Cross-artifact interpretation. The comparison shows that the same broad concern often appears differently depending on artifact type. Execution problems appear in issues as bug reports, in pull requests as fixes or tests, and in forum discussions as troubleshooting requests. Container concerns appear in issues as runtime failures, in pull requests as dependency or image updates, and in forum discussions as setup and execution questions. Documentation appears in issues as gaps or requests, in pull requests as concrete documentation changes, and in forum discussions as usage confusion. HPC and cloud concerns appear in issues as configuration or executor problems, in pull requests as profile and infrastructure updates, and in forum discussions as user-support questions about queues, credentials, storage, and resources. Summary of RQ2. RQ2 shows that no single artifact type provides a complete view of nf-core maintenance and support. GitHub issues reveal what needs attention, pull requests show how changes are implemented and integrated, and forum discussions reveal where users encounter practical barriers during execution and development. This division of work supports the cross-platform design of the study: understanding maintenance and support in nf-core requires analyzing repository-centered and community-centered spaces together.

4.3 RQ3: Factors Associated with Resolution Outcomes 4.3.1 Motivation RQ1 and RQ2 show what maintenance and support concerns appear in nf-core and how these concerns differ across GitHub issues, pull requests, and Seqera Community Forum discussions. However, topic distributions alone do not show how the ecosystem responds to reported problems, proposed changes, and user-support requests. Some artifacts are closed, merged, or answered quickly, while others remain open, are closed without merge, or receive no accepted answer. Understanding these differences is important because resolution outcomes provide evidence about how maintenance and support work is handled across the ecosystem. RQ3 therefore examines artifact-level factors associated with resolution outcomes. Because this is an observational repository- and forum-mining study, we interpret the results as lifecycle associations rather than causal effects or early prediction models. In particular, some features are available when an artifact is submitted, such as text, author type, code blocks, URLs, error mentions, version mentions, and topic assignment. Other features

Number of closed issues

1000 800 600 400 200 0

log(1 + resolution days)

Fig. 2: Log-transformed distribution of time-to-close for closed issues.

emerge during handling, such as comments, assignees, milestones, requested reviewers, replies, and likes. We therefore treat these later features as process signals that describe how artifacts are handled, not as independent causes of resolution.

4.3.2 Approach We analyzed resolution outcomes separately for the three artifact types, following the procedure described in Section 3.5. For issues, we examined closure and time-to-close. For pull requests, we examined merge, closed-without-merge, and time-to-final-decision. For forum discussions, we examined accepted-answer status and engagement; because accepted-answer timestamps were unavailable, forum lifecycle curves are interpreted as exploratory activity-span summaries rather than exact time-to-answer estimates. For each artifact type, we combine descriptive outcome summaries, bivariate associations, multivariable models, and lifecycle curves. The descriptive analysis reports closure, merge, closed-without-merge, accepted-answer, and timing distributions. The bivariate analysis compares outcome rates across individual features. The multivariable analysis examines adjusted associations while accounting for other artifact characteristics. Kaplan–Meier curves are used descriptively to compare lifecycle trajectories across selected binary features. This artifact-specific design allows us to compare how resolution differs across problem reports, implementation work, and user-support discussions while respecting the distinct workflows of GitHub and the community forum.

4.3.3 Results of RQ3 Overall, resolution outcomes in nf-core are associated with three recurring conditions: actionability, coordination, and diagnostic evidence. Issues were more likely to close when they showed maintainer attention or contained concrete technical details. Pull requests were more likely to merge when they were review-ready, linked to issues, supported by tests or checklists, or authored by contributors close to the project. Forum discussions were more likely to receive accepted answers when they contained concrete technical evidence and sustained interaction. In contrast, infrastructure-specific and coordination-intensive artifacts, especially those involving cloud, HPC, templates, or workflow semantics, were less consistently resolved or took longer to reach a final state.

GitHub issue resolution. Among 15,760 GitHub issues, 12,471 were closed, corresponding to a closure rate of 79.13%, while 3,289 remained open. Closure time was strongly right-skewed. Among closed issues, the median time-to-close was 27.91 days, compared with a mean of 131.25 days. The percentile distribution further shows this long tail: 25% of closed issues were resolved within 4.05 days, 50% within 27.91 days, 75% within 140.01 days, and 95% within 655.03 days. Most issues with an explicit state reason were closed as completed (n = 11,954), while fewer were marked not planned (n = 483). Duplicate (n = 34) and reopened (n = 53) issues were rare. This indicates that issue closure in nf-core is dominated by completed maintenance or support actions rather than duplicate removal or rejection. 17

Figure 2 shows the log-transformed distribution of time-to-close for closed nf-core issues. The distribution confirms that issue resolution is highly right-skewed: many issues are closed within a short period, while a substantial tail of issues remains open for much longer before closure. This pattern suggests that nf-core handles many issues quickly, but some issues require extended discussion, delayed prioritization, complex fixes, or long-term tracking.

Table 6: Selected bivariate associations between issue features and closure Feature

Absent Present

OR Adj. p

Has comments Has assignee Good first issue label Has milestone Bug label Mentions error Mentions version Has checklist Has URL Enhancement label

66.28% 73.42% 78.69% 77.27% 76.83% 76.84% 77.85% 78.32% 80.97% 83.56%

3.18 2.68 2.93 1.86 1.68 1.49 1.41 1.42 0.77 0.43

86.22% 88.11% 91.60% 86.34% 84.79% 83.21% 83.22% 83.73% 76.66% 68.62%

< .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001

Note. Absent and Present indicate issue-closure rates when the feature is absent or present. OR denotes the odds ratio for closure when the feature is present relative to absent. Adjusted p-values use Benjamini– Hochberg correction.

Bivariate associations with issue closure. We examined a broader set of binary issue features, including triage metadata, author-role indicators, textual evidence, interaction signals, and common labels. For each feature, we compared closure rates when the feature was absent versus present, estimated odds ratios, and applied Benjamini–Hochberg correction for multiple comparisons. Table 6 reports the most influential and interpretable associations. Bivariate results show that issue closure was strongly associated with interaction and triage signals. Issues with comments had a much higher closure rate than issues without comments (86.22% vs. 66.28%; OR=3.18), and assigned issues were also more likely to close than unassigned issues (88.11% vs. 73.42%; OR=2.68). Milestonelinked issues followed the same pattern (86.34% vs. 77.27%; OR=1.86), suggesting that discussion, ownership, and planning are closely related to issue resolution. Label-based patterns show that good first issue labels were associated with the highest closure rate among the selected features (91.60%; OR=2.93), while bug labels were also positively associated with closure (84.79% vs. 76.83%; OR=1.68). In contrast, enhancement issues were much less likely to close (68.62% vs. 83.56%; OR=0.43), indicating that feature-oriented requests may require longer deliberation or remain open as future work. Textual evidence also mattered: issues mentioning errors, versions, or checklists had higher closure rates, whereas issues containing URLs had lower closure rates (76.66% vs. 80.97%; OR=0.77). These results suggest that closure is linked to visibility, ownership, and diagnostic clarity, while featureoriented or context-heavy issues often require longer discussion or remain open as future work. The complete set of tested features is available in the replication package. Topic-level variation in issue resolution. Issue closure rates varied across maintenance and support topics, although most topics showed relatively high resolution levels. As shown in Figure 3, Module Development, Updates, and Migration had the highest closure rate, indicating that module-related coordination and migration tasks are often well scoped and actionable. Pipeline Tooling, Documentation, and Feature Support and Container Images and Runtime Environment Failures also showed comparatively high closure rates. In contrast, Sequencing, Alignment, and Genome Reference Support, Automated Linting and Template Compliance, and Runtime Bugs and Diagnostics Reports had lower closure rates, suggesting that issues involving domain-specific resources, template/linting behavior, or runtime diagnosis often require more investigation and coordination before resolution. Overall, topic-level variation indicates that issue resolution depends not only on whether an issue receives attention, but also on the technical scope and maintainability of the reported concern. Multivariable model of issue closure. To examine which issue-level factors were independently associated with closure, we fitted a robust multivariable logistic regression model with is closed as the outcome. The model included issue metadata, triage signals, textual evidence, selected labels, and categorical controls for repository and issue type. To avoid estimation problems caused by sparse categories and collinearity, rare categorical levels were collapsed, categorical controls were one-hot encoded, and constant, duplicate, and near-perfectly correlated predictors were removed before fitting the model. The final model used 15,760 issues, contained 113 predictors after encoding and cleaning, and was full rank. The standard logistic regression model converged successfully, with McFadden’s pseudo-R2 of 0.203.

Module Development, Updates, and Migration Pipeline Tooling, Documentation, and Feature Support Container Images and Runtime Environment Failures Subworkflow Testing and nf-test Migration Pipeline Test Infrastructure and CI Validation Pipeline Execution and Debugging Support MultiQC Reporting and Quality-Control Pipeline Modernization and Template Migration Runtime Bugs and Diagnostics Reports Linting and Template-Check Failures Sequencing, Alignment, and Genome Reference Support 0

Closure rate (%)

Fig. 3: Issue closure rate by topic.

Table 7: Selected predictors from the multivariable logistic regression model for issue closure Predictor

95% CI low

95% CI high

Adj. p

Number of assignees Comments Enhancement label Has milestone Has URL Mentions version Bug label Mentions system information Has parent issue Number of labels Author is member/owner Has code block Mentions error Good first issue label Text length Author is contributor

2.45 1.14 0.49 1.61 0.74 1.46 1.62 0.75 0.61 0.82 1.35 0.74 1.40 1.76 0.91 1.17

2.22 1.11 0.43 1.40 0.67 1.28 1.37 0.67 0.50 0.75 1.18 0.64 1.19 1.23 0.85 1.03

2.71 1.16 0.56 1.85 0.82 1.67 1.92 0.84 0.75 0.89 1.53 0.85 1.65 2.53 0.97 1.34

< .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .01 < .01 < .05

Note. OR denotes the odds ratio for issue closure after adjusting for other predictors in the model. Values above 1 indicate higher odds of closure; values below 1 indicate lower odds. Adjusted p-values use Benjamini–Hochberg correction.

Table 7 reports the most interpretable predictors. Triage and coordination signals remained strongly associated with closure: additional assignees (OR=2.45), comments (OR=1.14), and milestones (OR=1.61) all increased closure odds. Label and textual signals also mattered. Bug issues (OR=1.62), good first issue issues (OR=1.76), version mentions (OR=1.46), and error mentions (OR=1.40) were positively associated with closure, while enhancement issues were less likely to close (OR=0.49). More complex or context-heavy reports showed lower closure odds, including issues with URLs (OR=0.74), system-information mentions (OR=0.75), code blocks (OR=0.74), parent-issue links (OR=0.61), more labels (OR=0.82), and longer text (OR=0.91). Overall, issue closure in nf-core is most strongly associated with ownership, discussion, planning, and concrete diagnostic evidence, while feature-oriented or more complex reports are less likely to reach closure within the observation window. Issue Time-to-closure analysis. We further analyzed issue resolution speed using a Cox proportional hazards model, treating open issues as censored observations. The model included 15,760 issues, with 12,471 observed closures and 3,289 censored open issues, and achieved a concordance index of 0.601. In this model, hazard ratios above 1 indicate faster closure, while values below 1 indicate slower closure. Table 8 shows that triage and actionable diagnostic signals were associated with faster closure. Issues with assignees (HR=1.41), good first issue labels (HR=1.43), bug labels (HR=1.21), error mentions (HR=1.18),

Table 8: Selected Cox proportional hazards results for issue time-to-closure Predictor

95% CI low

95% CI high

Adj. p

Enhancement label Has assignee Number of labels Good first issue label Bug label Has URL Mentions error Mentions version Has milestone Author is contributor Mentions system info Text length

0.71 1.41 0.86 1.43 1.21 0.89 1.18 1.14 1.11 1.10 0.91 0.97

0.68 1.33 0.83 1.30 1.15 0.85 1.12 1.09 1.06 1.05 0.88 0.95

0.74 1.49 0.89 1.58 1.28 0.92 1.24 1.20 1.16 1.15 0.95 0.99

< .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .01

Note. HR denotes the hazard ratio from the Cox proportional hazards model. HR values above 1 indicate faster issue closure; values below 1 indicate slower closure. Adjusted p-values use Benjamini–Hochberg correction. The full model output is available in the replication package.

version mentions (HR=1.14), and milestones (HR=1.11) moved more quickly toward closure. In contrast, enhancement issues closed more slowly (HR=0.71), as did issues with more labels (HR=0.86), URLs (HR=0.89), system-information mentions (HR=0.91), and longer text (HR=0.97). These results reinforce the logisticregression findings: issue resolution is faster when ownership and concrete diagnostic evidence are present, while feature-oriented or more complex environment-specific reports tend to progress more slowly.

(a) Assignee presence

(b) Enhancement label

Fig. 4: Kaplan–Meier curves for selected issue features. The y-axis shows the probability that an issue remains open over time.

Kaplan–Meier analysis of issue-resolution trajectories. We generated Kaplan–Meier curves for several binary issue features to examine how resolution trajectories differed over time. For space, Figure 4 reports three representative factors that summarize the main patterns observed in the survival analysis: assignee presence, enhancement label, and error mention. The y-axis shows the probability that an issue remains open; therefore, curves that decline more quickly indicate faster closure. Issues with assignees moved toward closure faster than unassigned issues, consistent with the Cox model result that assignee presence was associated with faster closure (HR=1.41). Issues mentioning errors also showed faster closure trajectories than issues without error mentions, supporting the interpretation that concrete diagnostic evidence makes issues more actionable (HR=1.18). In contrast, enhancement-labeled issues remained open for longer than non-enhancement issues, consistent with their lower closure hazard (HR=0.71). Overall, the Kaplan– Meier curves reinforce the regression results: issues close faster when they have clear ownership or actionable diagnostic information, whereas feature-oriented issues tend to remain open longer because they often require prioritization, design discussion, or longer-term planning. GitHub pull request resolution. Among 35,411 pull requests, 32,518 were merged (91.83%), 2,290 were closed without merge (6.47%), and 603 remained open (1.70%). Pull request integration was generally fast but right-skewed. The median time-to-merge was 0.50 days, while the mean was 8.04 days. Similarly, the median time-to-final-decision was 0.71 days, compared 20

Number of merged Pull Requests

14000 12000 10000 8000 6000 4000 2000 0

2 3 4 5 log(1 + days to merge)

Fig. 5: Log-transformed distribution of time to merge for merged pull requests.

with a mean of 17.54 days. As shown in Figure 5, many pull requests were merged shortly after submission, while a smaller subset required substantially longer review, validation, or coordination. Automation status further differentiated pull request outcomes. Human-authored pull requests formed the largest group and had a high merge rate (96.93%; median time to merge = 0.39 days). Renovate pull requests had the highest merge rate (98.46%; median = 0.43 days), suggesting that these automated updates align well with nf-core’s review and validation workflows. In contrast, Dependabot pull requests were merged less consistently (72.13%; median = 0.54 days), and other bot-authored pull requests had the lowest merge rate (51.94%) and longest median time to merge (4.95 days). These results show that automated maintenance is heterogeneous: some automation supports efficient integration, whereas other bot-generated changes are more likely to require manual intervention, become obsolete, or be closed without merge. Review routing and issue linkage. Pull requests with linked issues were more likely to be merged than pull requests without linked issues (96.71% vs. 91.35%), but they also took longer to merge (median 0.87 vs. 0.26 days). A similar pattern appears for requested reviewers: pull requests with requested reviewers had a higher merge rate than those without requested reviewers (95.70% vs. 91.81%), while also having a longer median time-to-merge (0.88 vs. 0.30 days). These results suggest that issue linkage and reviewer assignment support eventual integration by providing context and review routing, but they also mark pull requests that require additional coordination, verification, or maintainer attention before merging. Topic-level variation in pull request integration. Pull request merge rates varied by topic, although all topics showed high integration levels overall. As shown in Figure 6, Community Infrastructure and Website Maintenance had the highest merge rate, followed by Routine Maintenance and Reliability Fixes and Runtime Environment and Container Dependency. These topics often involve localized website updates, reliability fixes, or concrete environment-maintenance changes that can be reviewed and integrated relatively efficiently. In contrast, Subworkflow Integration and Pipeline Metadata Management, Execution Profile and Infrastructure Configuration, and Pipeline Documentation, Testing, and Template Alignment had comparatively lower merge rates, although they still remained above 87%. These lower rates suggest that changes involving subworkflow integration, metadata, execution profiles, documentation, and template alignment may require more coordination, repository-specific review, or validation before integration. Overall, the topic-level pattern indicates that nf-core pull request integration is broadly successful, but coordination-intensive and infrastructure-oriented changes are somewhat less consistently merged than localized maintenance or community-infrastructure updates. Table 9 adds the closed-without-merge and median-time perspective. Community Infrastructure and Website Maintenance had the highest merge rate (97.06%) and a short median time-to-merge (0.11 days), followed by Routine Maintenance and Reliability Improvements (95.92%) and Runtime Environment and Container Dependency (95.58%). By contrast, Subworkflow Integration and Pipeline Metadata Management (87.53%), Execution Profile and Infrastructure Configuration (88.30%), and Pipeline Documentation, Testing, and Template Alignment (89.57%) had comparatively lower merge rates and higher closed-without-merge rates. Overall, topic-level variation

Community Infrastructure and Website Maintenance Routine Maintenance and Reliability Fixes Runtime Environment and Container Dependency Module Review, Linting, and Interface Validation Sample Sheet and Input Validation Contribution Checklist and Review Preparation Module Development and Quality Assurance Automated Dependency and Repository Workflow Maintenance Reference Data and Alignment Test Resources Template Update Propagation Across Pipelines Pipeline Documentation, Testing, and Template Alignment Execution Profile and Infrastructure Configuration Subworkflow Integration and Pipeline Metadata Management

Merge rate (%)

100

Fig. 6: Merge rate by pull request topic.

Table 9: Topic-level pull request resolution summary Topic

Merged

Closed

Med. days

Module Development and Quality Assurance Pipeline Documentation, Testing, and Template Alignment Module Review, Linting, and Interface Validation Routine Maintenance and Reliability Fixes Template Update Propagation Across Pipelines Contribution Checklist and Review Preparation Execution Profile and Infrastructure Configuration Community Infrastructure and Website Maintenance Automated Dependency and Repository Workflow Maintenance Reference Data and Alignment Test Resources Runtime Environment and Container Dependency Subworkflow Integration and Pipeline Metadata Management Sample Sheet and Input Validation

93.41% 89.57% 94.17% 95.92% 90.71% 93.54% 88.30% 97.06% 92.98% 92.28% 95.58% 87.53% 94.01%

5.87% 9.60% 4.82% 3.53% 8.10% 5.91% 11.06% 2.59% 5.61% 6.37% 3.01% 11.22% 5.72%

0.44 0.69 0.66 0.41 0.61 0.69 0.73 0.11 0.28 0.19 0.51 0.62 0.05

Note. Closed denotes pull requests closed without merge. Median days are calculated for merged pull requests only.

indicates that nf-core pull request integration is broadly successful, but coordination-intensive and infrastructureoriented changes are somewhat less consistently merged than localized maintenance or community-infrastructure updates. Bivariate associations with merge outcome. We examined a broad set of binary pull request features, including review signals, author and automation indicators, target-branch information, textual cues, and labels. Table 10 reports the most influential and interpretable associations. Bivariate merge results show that contributionreadiness and review-routing signals were associated with higher merge rates. Pull requests mentioning tests (96.80% vs. 84.33%; OR=5.62), fixes (96.99% vs. 85.73%; OR=5.36), or checklists (96.99% vs. 86.91%; OR=4.85) had substantially higher merge rates. Pull requests with linked issues (96.71% vs. 91.35%; OR=2.78) and requested reviewers (95.70% vs. 91.81%; OR=1.98) were also more likely to merge. However, these same review-routing features were associated with longer median time-to-merge: linked-issue pull requests took 0.87 days versus 0.26 days, and pull requests with requested reviewers took 0.88 days versus 0.30 days. Thus, issue linkage and reviewer assignment are associated with eventual integration, but they also appear to mark changes requiring more coordination or verification. Bivariate associations with closed-without-merge outcomes. Closed-without-merge outcomes show the complementary pattern. Table 11 reports the most influential and interpretable associations. Bot-authored pull

Table 10: Selected bivariate associations between pull request features and merge outcome Feature

Absent

Present

Adj. p

Mentions test Mentions fix Has checklist Has linked issue Requested reviewer Renovate pull request Auto-merge enabled Bot-authored Draft pull request Mentions template Targets development branch Targets main/master branch

84.33% 85.73% 86.91% 91.35% 91.81% 92.49% 92.53% 96.93% 93.17% 97.34% 97.16% 89.50%

96.80% 96.99% 96.99% 96.71% 95.70% 98.46% 99.51% 61.96% 72.25% 87.31% 88.22% 97.17%

5.62 5.36 4.85 2.78 1.98 5.01 13.93 0.05 0.19 0.19 0.22 4.02

< .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001

Note. Absent and Present indicate merge rates when the feature is absent or present. OR denotes the odds ratio for merging when the feature is present relative to absent. Adjusted p-values use Benjamini–Hochberg correction.

Table 11: Selected bivariate associations between pull request features and closed-without-merge outcome Feature

Absent

Present

Adj. p

Bot-authored Mentions template Targets development branch Has URL Has body Draft pull request Dependabot pull request Mentions fix Mentions test Has checklist Has linked issue Requested reviewer Renovate pull request

2.34% 2.03% 2.26% 1.90% 1.53% 6.22% 6.55% 13.52% 14.94% 12.35% 7.98% 7.46% 6.71%

37.13% 11.75% 10.81% 8.76% 7.18% 22.70% 22.81% 2.22% 2.39% 2.19% 2.17% 3.38% 1.56%

24.68 6.41 5.23 4.94 4.94 4.44 4.33 0.15 0.14 0.16 0.26 0.43 0.23

< .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001 < .001

Note. Absent and Present indicate closed-without-merge rates among pull requests that reached a final decision. OR denotes the odds ratio for being closed without merge when the feature is present relative to absent. Open pull requests are excluded. Adjusted p-values use Benjamini–Hochberg correction.

requests had a much higher closed-without-merge rate than non-bot pull requests (37.13% vs. 2.34%; OR=24.68). Template-related pull requests, development-branch targets, pull requests containing URLs or bodies, draft pull requests, and Dependabot updates were also more likely to be closed without merge. In contrast, pull requests mentioning fixes or tests, containing checklists, linking to issues, requesting reviewers, or coming from Renovate were less likely to be closed without merge. These results suggest that non-merged closure is concentrated in automation-heavy, draft, template-related, and branch-specific work, while review-ready and traceable pull requests are more consistently integrated. Bivariate associations with time-to-merge. We analyzed time-to-merge among merged pull requests using Mann–Whitney U tests and Cliff’s δ effect sizes. Table 12 reports the most influential and interpretable associations. Several features associated with successful integration were also associated with longer merge times. Pull requests linked to issues, requesting reviewers, containing checklists, or mentioning templates took longer to merge, suggesting that traceability and review-readiness signals often appear in contributions requiring additional verification or coordination. The largest delays were observed for pull requests linked to milestones, enhancement-labeled pull requests, bot-authored pull requests, and labeled pull requests, indicating that planned, feature-oriented, automated, or explicitly classified changes often require more review effort. Overall, time-to-merge results show that fast integration is common in nf-core, but pull requests involving coordination, metadata, documentation, templates, or automation tend to remain under review longer before successful integration. Multivariable model of pull request merging. The regularized merge model shows that contributor familiarity and contribution-readiness signals remained associated with integration after adjustment. As shown in Table 13, pull requests authored by members or owners (OR=18.89) and contributors (OR=7.70) had substantially higher adjusted odds of merging. Renovate pull requests (OR=6.59), security mentions (OR=5.50), 23

Table 12: Selected bivariate associations between pull request features and time-to-merge Feature Has milestone Enhancement label Bot-authored Has label Has assignee Has body Has URL Mentions documentation Has linked issue Requested reviewer Mentions template Has checklist

Absent

Present

Diff.

Cliff ’s δ

0.46 0.48 0.39 0.33 0.36 0.03 0.12 0.15 0.26 0.30 0.22 0.18

3.77 3.25 2.16 1.80 1.34 0.68 0.76 0.76 0.87 0.88 0.81 0.73

3.32 2.77 1.77 1.47 0.98 0.65 0.65 0.61 0.62 0.59 0.59 0.55

0.39 0.35 0.32 0.31 0.26 0.40 0.24 0.21 0.19 0.19 0.17 0.16

Note. Absent and Present indicate median time-to-merge in days among merged pull requests. Diff. denotes the median difference when the feature is present relative to absent. All selected associations are significant after Benjamini–Hochberg correction (padj < .001).

Table 13: Selected predictors from the regularized logistic regression model for pull request merging Predictor

Coefficient

Author is member/owner Author is contributor Renovate pull request Mentions security Auto-merge enabled Has checklist Mentions fix Mentions test Mentions dependency Has linked issue Has milestone

2.94 2.04 1.89 1.71 1.70 1.16 0.90 0.59 0.52 0.19 0.17

18.89 7.70 6.59 5.50 5.49 3.20 2.45 1.80 1.68 1.22 1.19

Number of labels Mentions template Text length Dependabot pull request Bot-authored Draft pull request Targets development branch

-0.22 -0.54 -0.78 -1.30 -1.41 -2.58 -2.93

0.80 0.58 0.46 0.27 0.24 0.08 0.05

Note. OR denotes the odds ratio from the L1-regularized logistic regression model. Values above 1 indicate higher adjusted odds of merging; values below 1 indicate lower adjusted odds. Repository and branch controls were included but omitted for readability. Because this is a regularized model, results are interpreted as adjusted directional associations rather than formal significance tests.

auto-merge (OR=5.49), checklists (OR=3.20), fix mentions (OR=2.45), test mentions (OR=1.80), dependency mentions (OR=1.68), linked issues (OR=1.22), and milestones (OR=1.19) were also associated with higher merge odds. Lower merge odds were associated with development-branch targets (OR=0.05), draft status (OR=0.08), bot authorship (OR=0.24), Dependabot updates (OR=0.27), longer text (OR=0.46), template mentions (OR=0.58), and more labels (OR=0.80). Because this model is regularized, these estimates are interpreted as adjusted directional associations rather than formal significance tests.

Multivariable model for closed-without-merge outcomes. We fitted a regularized logistic regression model to identify factors associated with pull requests being closed without merge rather than merged, excluding open pull requests. Table 14 reports the most interpretable adjusted odds ratios. Draft status showed the strongest association with non-merged closure (OR=13.81), indicating that pull requests not ready for review were much more likely to be closed without integration. Development-branch targets (OR=4.43), bot authorship (OR=4.10), Dependabot updates (OR=3.07), longer text (OR=2.19), template mentions (OR=2.14), and larger numbers of labels (OR=1.27) were also associated with higher odds of closedwithout-merge outcomes.

Table 14: Selected adjusted odds ratios for pull requests closed without merge Predictor

Draft pull request Targets development branch Bot-authored Dependabot pull request Longer text Mentions template Number of labels Has linked issue Mentions test Mentions dependency Mentions fix Mentions security Renovate pull request Has checklist Author is contributor Author is member/owner Auto-merge enabled

13.81 4.43 4.10 3.07 2.19 2.14 1.27 0.64 0.55 0.55 0.40 0.30 0.29 0.27 0.16 0.06 0.01

Note. Odds ratios are from an L1-regularized logistic regression model comparing pull requests closed without merge against merged pull requests. Open pull requests are excluded. Values above 1 indicate higher adjusted odds of closedwithout-merge outcomes; values below 1 indicate lower adjusted odds. Repository, topic, and author-association controls were included but omitted for readability.

In contrast, several features were associated with lower odds of non-merged closure. Pull requests linked to issues (OR=0.64), mentioning tests (OR=0.55), dependencies (OR=0.55), fixes (OR=0.40), or security (OR=0.30), and those containing checklists (OR=0.27) were less likely to be closed without merge. Renovate pull requests also had lower odds of non-merged closure (OR=0.29), while contributor and member/owner authorship were strongly protective against non-merged closure. Overall, the model suggests that non-merged closure in nf-core is concentrated among draft, bot-generated, template-related, and branch-specific pull requests, whereas issue linkage, validation evidence, checklist use, and maintainer familiarity support successful integration.

(a) Draft status

(b) Linked issue

Fig. 7: Kaplan–Meier curves for time to final pull request decision across selected factors. The y-axis shows the probability that a pull request remains open. Draft pull requests remain open substantially longer, while pull requests with linked issues or requested reviewers also show longer decision trajectories.

Kaplan–Meier analysis of Pull Request-resolution trajectories We further examined time to final pull request decision using Kaplan–Meier curves. The event was a final decision, either merge or closed without merge, while pull requests that remained open were treated as censored. We explored several binary features, including checklist presence, linked issue, requested reviewer, bot authorship, automation status, draft status, dependency mentions, documentation mentions, template mentions, and test mentions. For space, Figure 7 reports three representative factors with clear interpretation: draft status, linked issue, and requested reviewer. Draft status shows the strongest separation. Draft pull requests remained open substantially longer than nondraft pull requests, indicating that contributions marked as not ready for review move more slowly toward a final decision. Pull requests linked to issues and pull requests with requested reviewers also showed longer decision trajectories than their counterparts. This does not necessarily indicate weaker integration; earlier results show 25

that linked issues and requested reviewers are associated with higher merge rates. Rather, these features appear to mark pull requests that require additional coordination, verification, or domain-specific review before resolution. Overall, the lifecycle analysis shows that most nf-core pull requests are resolved quickly, but draft work and coordination-intensive pull requests remain open longer before reaching a final decision.

4.3.4 Factors Associated with Forum Discussion Resolution Outcomes: Forum support outcomes and engagement We analyzed 895 Seqera Community Forum discussions to examine how user-facing support requests reach resolution. Overall, 412 discussions received an accepted answer, corresponding to an accepted-answer rate of 46.03%, while 483 discussions did not receive an accepted answer. A similar proportion received at least one reply (446 discussions; 49.83%), indicating that support engagement is unevenly distributed across forum posts.

Fig. 8: Log-transformed distribution of forum discussion views.

The median number of replies was 0, although the mean was 1.15, showing that many discussions received no reply while a smaller subset generated more active exchanges. Discussions nevertheless attracted substantial visibility, with a median of 113 views and a mean of 172.45 views. Because raw view counts were skewed, Figure 8 presents the log-transformed distribution, which shows that most discussions received moderate visibility while a smaller number attracted substantially closer attention. The median activity span was 1.75 days, compared with a mean of 22.58 days, indicating that many discussions became inactive quickly, while a smaller subset remained active for much longer. These results suggest that forum resolution is less formalized than GitHub issue closure or pull request merging: accepted-answer outcomes depend on sustained community interaction, while even unresolved discussions may remain useful as visible support resources for later users facing similar nf-core or Nextflow execution problems. Technical evidence and accepted answers. Accepted-answer rates varied by the technical evidence included in forum discussions. Discussions containing code blocks had a higher accepted-answer rate than those without code blocks (49.92% vs. 38.41%) and also showed greater engagement, with a median of one reply and 122 views compared with zero replies and 98 views for discussions without code blocks. This suggests that concrete technical evidence, such as commands, configuration snippets, workflow fragments, or error logs, makes support requests more diagnosable. Accepted-answer rates also differed across technical signals. As shown in Figure 9, discussions mentioning MultiQC had the highest accepted-answer rate (53.28%), followed by training-related discussions (49.38%) and version-related discussions (46.60%). Discussions mentioning errors, reproduction information, or containers had moderate accepted-answer rates, ranging from 41.67% to 43.57%. In contrast, cloud- and HPC-related discussions had the lowest accepted-answer rates, at 34.34% and 34.31%, respectively. These results suggest that reporting, 26

mentions_multiqc

Mentioned Keywords

mentions_training mentions_version mentions_error mentions_reproduce mentions_container mentions_cloud mentions_hpc 0

Accepted-answer rate (%)

Fig. 9: Accepted-answer rate by technical signal in forum discussions.

training, or version-specific questions are more readily resolved, whereas cloud and HPC questions are harder to answer conclusively because they often depend on local infrastructure, credentials, schedulers, storage systems, or execution policies.

Containerized Runtime Environments and Dependency Resolution Pipeline-Specific Runtime Errors and Version Issues

Forum topic

Quality-Control Reporting and Result Visualization HPC Execution, Process Scheduling, and Resource Allocation Pipeline Execution and Debugging Support Cloud and Batch Execution Support Dataflow, Channels, and Output Propagation Nextflow Development Tooling and Syntax Support

Accepted-answer rate (%)

Fig. 10: Accepted-answer rate by forum topic.

Topic-level variation in forum resolution. Accepted-answer rates varied across forum topics, indicating that some support needs were easier to resolve than others. As shown in Figure 10, Containerized Runtime Environments and Dependency Resolution had the highest accepted-answer rate (61.84%), followed by Pipeline-Specific Runtime Errors and Version Issues (51.52%), Quality-Control Reporting and Result Visualization (50.62%), and HPC Execution, Process Scheduling, and Resource Allocation (50.00%). These topics often involve concrete runtime symptoms, reporting outputs, or identifiable environment behavior. In contrast, Nextflow Development Tooling and Syntax Support had the lowest accepted-answer rate (34.21%), followed by Dataflow, Channels, and Output Propagation (40.78%) and Cloud and Batch Execution Support (43.14%). These lower rates suggest that questions involving workflow semantics, development tooling, or cloud execution are harder to resolve conclusively, likely because they require more context about user code, platform configuration, or infrastructure-specific constraints.

Table 15: Selected bivariate associations between forum features and accepted-answer outcomes Feature

Absent Present

Has multiple comments Has reply Has likes MultiQC tag Has code block Mentions MultiQC Mentions cloud Mentions HPC SLURM tag HPC tag

0.00% 29.62% 30.57% 42.05% 38.41% 43.54% 49.35% 48.15% 46.66% 46.78%

OR Adj. p

51.95% 221.66 62.56% 3.96 62.24% 3.73 76.70% 4.47 49.92% 1.60 53.28% 1.48 34.34% 0.54 34.31% 0.57 0.00% 0.05 20.00% 0.31

< .001 < .001 < .001 < .001 .005 .037 .001 .012 .004 .029

Note. Absent and Present indicate accepted-answer rates when the feature is absent or present. OR denotes the odds ratio for receiving an accepted answer when the feature is present relative to absent. Adjusted p-values use Benjamini– Hochberg correction.

Bivariate associations with accepted answers. We examined a broad set of binary forum features, including engagement signals, technical evidence, infrastructure mentions, and tag indicators. For each feature, we compared accepted-answer rates when the feature was absent versus present, estimated odds ratios using 2×2 contingency tables, and applied Benjamini–Hochberg correction for multiple comparisons. Table 15 reports the most influential and interpretable associations. The strongest associations involved conversational engagement. Discussions with replies had a much higher accepted-answer rate than discussions without replies (62.56% vs. 29.62%; OR=3.96), and discussions with likes showed a similar pattern (62.24% vs. 30.57%; OR=3.73). Discussions with multiple posts also had a higher accepted-answer rate, although this should be interpreted as an engagement condition rather than an independent causal factor. Technical specificity was also associated with resolution: discussions containing code blocks were more likely to receive accepted answers (49.92% vs. 38.41%; OR=1.60), and MultiQC-related discussions showed higher acceptance, especially those tagged with multiqc (76.70% vs. 42.05%; OR=4.47). In contrast, infrastructurerelated discussions were less likely to receive accepted answers. Cloud mentions (34.34% vs. 49.35%; OR=0.54), HPC mentions (34.31% vs. 48.15%; OR=0.57), and HPC/SLURM tags were associated with lower acceptedanswer rates. Overall, forum resolution is most strongly associated with active community interaction and concrete diagnostic evidence, while infrastructure-dependent questions are harder to resolve conclusively.

Table 16: Selected numeric predictors associated with accepted-answer outcomes in forum discussions Feature

No accepted Accepted Diff. Cliff ’s δ Adj. p

Posts Replies Likes Activity span days Code blocks Views

2.00 0.00 0.00 1.07 2.00 107.00

5.00 3.00 1.00 1.00 1.00 1.00 3.45 2.38 3.00 1.00 122.00 15.00

0.56 0.33 0.32 0.21 0.10 0.10

< .001 < .001 < .001 < .001 < .05 < .05

Note. Values show medians for discussions without and with accepted answers. Diff. denotes the median difference for acceptedanswer discussions. Adjusted p-values use Benjamini–Hochberg correction.

Numeric predictors of accepted answers. We compared numeric discussion features between forum posts with and without accepted answers using Mann–Whitney U tests and Cliff’s δ effect sizes. Numeric comparisons reinforce the engagement pattern. As shown in Table 16, accepted-answer discussions had more posts (median 5 vs. 2; Cliff’s δ = 0.56), more replies (1 vs. 0; δ = 0.33), more likes (1 vs. 0; δ = 0.32), and longer activity spans (3.45 vs. 1.07 days; δ = 0.21). Accepted-answer discussions also contained slightly more code blocks and received slightly more views, although these effects were small. In contrast, text-length measures showed negligible differences, suggesting that accepted answers are associated less with longer questions and more with conversational engagement, diagnostic evidence, and sustained community interaction. Multivariable model of accepted-answer outcomes. We fitted a regularized logistic regression model to examine which forum features were associated with receiving an accepted answer after accounting for engagement, technical evidence, infrastructure mentions, text length, and topic/category controls. The regularized logistic model for accepted-answer status shows similar adjusted associations. As shown in Table 17, accepted answers were positively associated with posts count (OR=149.33), likes count (OR=2.18), code blocks (OR=2.00), attachments 28

Table 17: Selected predictors from the regularized logistic regression model for accepted-answer outcomes in forum discussions Predictor

Coefficient

Posts count, log-transformed Likes count, log-transformed Has code block Has attachment Mentions MultiQC Text length, log-transformed Mentions version

5.01 0.78 0.69 0.54 0.36 0.05 0.03

149.33 2.18 2.00 1.72 1.43 1.05 1.03

Mentions reproduce Mentions Seqera Platform Has image Views, log-transformed Activity span, log-transformed Mentions HPC Mentions Nextflow Replies count, log-transformed

-0.25 -0.27 -0.28 -0.29 -0.35 -0.56 -0.72 -1.73

0.78 0.77 0.76 0.75 0.71 0.57 0.49 0.18

Note. OR denotes the odds ratio from the L1-regularized logistic regression model. Values above 1 indicate higher adjusted odds of receiving an accepted answer; values below 1 indicate lower adjusted odds. Topic/category controls were included but omitted for readability. Because this is a regularized model, results are interpreted as adjusted directional associations rather than formal significance tests.

(OR=1.72), MultiQC mentions (OR=1.43), text length (OR=1.05), and version mentions (OR=1.03). Lower adjusted odds were associated with reproduction mentions (OR=0.78), Seqera Platform mentions (OR=0.77), images (OR=0.76), views (OR=0.75), activity span (OR=0.71), HPC mentions (OR=0.57), Nextflow mentions (OR=0.49), and reply count (OR=0.18). The negative coefficient for reply count should be interpreted cautiously because posts and replies are partially overlapping engagement measures. In combination, the model suggests that broader conversational development and concrete technical evidence are more informative than reply count alone. Because this is a regularized model, these coefficients are interpreted as adjusted directional associations rather than formal significance tests.

(a) Code block

(b) Cloud mention

Fig. 11: Kaplan–Meier-style lifecycle curves for selected forum discussion features. The y-axis shows the probability that a discussion has not received an accepted answer over its observed activity span.

Forum Discussion Lifecycle. We examined how selected discussion features relate to accepted-answer outcomes over the observed activity span of each forum discussion. The event was receiving an accepted answer, while discussions without accepted answers were treated as censored. For space, Figure 11 reports three representative signals: code blocks, cloud mentions, and HPC mentions. The curves show that discussions with code blocks moved more quickly toward accepted-answer outcomes, consistent with the bivariate results showing that concrete diagnostic evidence improves resolvability. In contrast, discussions mentioning cloud or HPC remained without accepted answers for longer, indicating that infrastructuredependent support problems are harder to resolve conclusively. These patterns suggest that forum questions are more likely to reach resolution when they include actionable technical evidence, whereas cloud and HPC questions often depend on local configuration, credentials, schedulers, storage systems, or institutional execution policies. 29

Qualitative sampling for interpretation. To contextualize the quantitative forum results, we inspected representative discussions from four groups: acceptedanswer discussions with high engagement, high-engagement discussions without accepted answers, unanswered discussions with no replies, and long-lifecycle discussions without accepted answers. This sampling was used to interpret the statistical patterns rather than to introduce a separate qualitative coding scheme. Accepted-answer discussions with high engagement typically contained concrete technical details and active back-and-forth interaction. For example, How to wait until a process is complete? received an accepted answer after 23 posts, 12 replies, 913 views, and an activity span of 12.96 days. Similarly, Timeout issue in nextflow process run on Azure batch had 19 posts, 12 replies, 517 views, and 4 likes before reaching an accepted answer. These cases illustrate how detailed, active discussions can converge on a support outcome. However, engagement alone did not guarantee resolution. Some high-engagement discussions remained without accepted answers, including Proper way to utilize >1 GPUs in a single machine?, which had 14 posts, 9 replies, 509 views, and remained active for 530.82 days, and Is it possible to use Nextflow with the libmamba conda solver?, which had 13 posts, 8 replies, 1,076 views, and 11 likes but no accepted answer. Unanswered discussions also attracted substantial visibility: MultiQC on fastp results had no replies but 1,047 views, while Using conda environments in singularity containers with nextflow had no replies but 627 views. Long-lifecycle unresolved discussions often involved development tooling, GPU use, HPC/cloud execution, or job-log recovery; for example, Remote-debug in IntelliJ is not stopping at breakpoints remained active for 639.86 days without an accepted answer, and My jobs are being canceled and logs are unable to be recovered remained unresolved for 514.50 days. Overall, the qualitative inspection supports the statistical findings: forum questions are more likely to reach accepted-answer resolution when they are bounded and technically diagnosable, while infrastructure-dependent or environment-specific questions may remain visible and useful but unresolved in formal accepted-answer terms. Summary of RQ3. RQ3 shows that resolution in nf-core is associated with actionability, coordination, and infrastructure complexity. GitHub issues were more likely to close and closed faster when they showed maintainer attention and diagnostic clarity, such as assignees, comments, milestones, bug labels, error mentions, and version information. Pull requests were highly likely to merge overall, but successful integration was associated with contributor familiarity, checklists, fix/test framing, linked issues, requested reviewers, and well-aligned automation such as Renovate. In contrast, draft pull requests, development-branch targets, template-related changes, Dependabot updates, and bot-authored changes were less consistently integrated. Forum discussions were less formalized: accepted answers were more likely when discussions included code blocks, multiple comments, likes, and concrete technical evidence, while cloud, HPC, and workflow-semantics questions were harder to resolve. Overall, nf-core resolves artifacts most effectively when problems are concrete, technically diagnosable, and routed through clear coordination mechanisms.

4.4 RQ4: Problem–Solution Flow Across Repository and Support Spaces 4.4.1 Motivation RQ1–RQ3 show what maintenance and support concerns appear in nf-core, how they differ across artifact types, and which factors are associated with resolution outcomes. However, these analyses do not show whether problems raised in one space are connected to solutions or follow-up work in another. This matters because maintenance and support in nf-core are distributed across GitHub issues, pull requests, and Seqera Community Forum discussions. A forum discussion may reveal a recurring user-facing execution problem, an issue may formalize that problem as a repository-level task, and a pull request may implement the corresponding fix or documentation update. Understanding this flow is important for evaluating traceability in the ecosystem. Strong traceability helps maintainers connect reported problems to implementation work and durable improvements. Weak traceability, especially between user-support discussions and repository artifacts, may cause recurring support problems to remain isolated in forum threads rather than being converted into GitHub issues, pull requests, documentation updates, or template improvements. RQ4 therefore examines how visible and traceable problem–solution flow is across repository-centered development spaces and community-centered support spaces.

4.4.2 Approach We followed the problem–solution flow procedure described in Section 3.6, but report the results in three layers. First, we analyzed explicit traceability by extracting direct references, including GitHub issue and pull request URLs, forum URLs, GitHub #number references, and closing-keyword references such as fixes, closes, and resolves. These links provide the strongest evidence of visible cross-artifact relationships.

Second, we analyzed implicit issue–pull request relatedness using semantic similarity after removing directly linked pairs. These pairs are treated as candidate semantic flows rather than confirmed problem–solution links because textual similarity does not prove that one artifact caused or directly informed another. We therefore interpret them as evidence of possible related maintenance work that is not explicitly linked. Third, we compared technical-signal overlap across issues, pull requests, and forum discussions. Signal overlap does not establish artifact-level traceability, but it shows whether similar technical concerns recur across repository and support spaces. Together, direct links, semantic-flow candidates, and technical-signal overlap allow us to distinguish strong explicit traceability from weaker thematic connections.

4.4.3 Results of RQ4 RQ4 shows that problem–solution flow in nf-core is strongly traceable within GitHub but weakly traceable between GitHub and the Seqera Community Forum. Pull requests frequently reference issues and other pull requests, creating a visible repository-internal pathway from reported problems to implementation work. In contrast, explicit links between forum discussions and GitHub artifacts are rare, even though forum discussions and GitHub artifacts share many technical concerns. This suggests that user-facing support knowledge often enters maintenance indirectly, through recurring technical themes, rather than through explicit cross-platform links.

Table 18: Explicit direct-link flows across nf-core artifacts Flow type

Links

Pull request → Issue Pull request → Pull request Issue → Issue Issue → Pull request Pull request → unresolved GitHub reference Issue → unresolved GitHub reference GitHub → Forum Forum → GitHub Forum → Forum

7,599 6,021 1,886 1,091 804 99 6 5 1

Note. Direct links include explicit GitHub/forum URLs, GitHub #number references, and closing-keyword references.

Explicit links are concentrated inside GitHub. Table 18 summarizes explicit direct-link flows across nf-core artifacts. We identified 17,512 explicit cross-artifact references. The largest flow was from pull requests to issues, with 7,599 links. This included closing-keyword references, explicit issue URLs, and issue-number references. We also observed 6,021 pull request-to-pull request references, 1,886 issue-to-issue references, and 1,091 issue-to-pull request references. These results indicate that GitHub provides the clearest traceable problem–solution pathway in nf-core. Although many detected references point from pull requests to issues, the underlying maintenance logic is problemto-solution: issues describe reported problems, feature requests, or maintenance tasks, while pull requests provide implementation, review, or integration work. This pattern shows that nf-core contributors frequently connect related repository artifacts, especially when pull requests address, discuss, or supersede issue-level maintenance tasks. Forum–GitHub traceability is limited. Explicit links between the Seqera Community Forum and GitHub artifacts were rare. We found only five forumto-GitHub links and six GitHub-to-forum links, along with one forum-to-forum link (Table 18). This pattern indicates that user-facing support discussions are weakly connected to repository-centered maintenance through explicit references. This weak traceability is important because forum discussions often contain maintenance-relevant knowledge. Repeated forum questions may reveal documentation gaps, confusing error messages, cloud or HPC configuration problems, container issues, or recurring pipeline-execution failures. However, without explicit links to GitHub issues, pull requests, or documentation updates, this knowledge may remain local to the support thread. As a result, forum support may help individual users but not always become durable repository-level improvement.

Table 19: Implicit semantic flow after removing directly linked artifact pairs Flow type

Pairs Median sim. Median lag

Issue problem → Pull request solution Pull request precedes issue

5,985 1,137

0.359 0.343

18.27 -7.88

Note. Semantic-flow pairs are candidate relationships identified using TF–IDF cosine similarity after removing directly linked artifact pairs. Median lag is measured in days from source artifact creation to target artifact creation; negative values indicate that the pull request preceded the related issue.

Semantic similarity reveals additional candidate issue–pull request flow. Because many related artifacts may not be explicitly linked, we also examined semantic similarity between GitHub issues and pull requests after removing directly linked pairs. Table 19 reports the resulting candidate relationships. We identified 5,985 candidate issue-to-pull-request flows, with a median cosine similarity of 0.359 and a median lag of 18.27 days. This suggests that related implementation work often appears within weeks after an issue is raised, even when the issue and pull request are not explicitly connected. We also found 1,137 cases where a semantically related pull request preceded an issue, with a median lag of −7.88 days. These cases may reflect follow-up reports, regressions, documentation needs, or issues opened after related implementation work had already begun. Because these pairs are based on textual similarity and temporal ordering rather than explicit references, we interpret them as candidate implicit flows rather than confirmed problem–solution links. Table 20: Manual validation of sampled RQ4 linkage candidates Candidate type

Sample

Exact

Weakly related

Unrelated

Direct link Issue–pull request reference Semantic similarity

72 10 20

8 (11.1%) 7 (70.0%) 7 (35.0%)

47 (65.3%) 3 (30.0%) 8 (40.0%)

15 (20.8%) 0 (0.0%) 4 (20.0%)

2 (2.8%) 0 (0.0%) 1 (5.0%)

Overall

102

22 (21.6%)

58 (56.9%)

19 (18.6%)

3 (2.9%)

Note. Exact pairs refer to the same concrete maintenance or support concern. Related pairs share a meaningful technical or maintenance concern but may not show direct problem–solution continuity. Weakly related pairs share limited vocabulary or broad context. Unrelated pairs do not provide meaningful evidence of maintenance flow.

Manual validation of linkage candidates. Because direct references and semantic similarity can vary in evidential strength, we manually validated a stratified sample of over a hundred linkage candidates drawn from the RQ4 linkage pool. The sample included direct links, issue–pull request references, and semantic-similarity candidates across the observed flow types. Each sampled pair was classified as exact, related, weakly related, or unrelated. Exact pairs referred to the same problem, feature, bug, module, pull request, or implementation concern. Related pairs shared a meaningful maintenance or support concern but did not always show direct problem–solution continuity. Weakly related pairs shared limited vocabulary, repository context, or broad ecosystem terminology. Unrelated pairs did not show a meaningful maintenance connection. Table 20 reports the validation results. Overall, 22 of 102 sampled candidates were exact, 58 were related, 19 were weakly related, and 3 were unrelated. Thus, 80 of 102 sampled candidates were either exact or related. The validation also shows differences across evidence types. Direct links were often meaningful, but unresolved GitHub references and cross-platform links sometimes produced weak matches. Issue–pull request references were the strongest category, with all 10 sampled cases classified as exact or related. Semantic-similarity candidates were more mixed: 7 of 20 were exact, 8 were related, 4 were weakly related, and 1 was unrelated. This confirms that semantic similarity can identify useful implicit relationships, but it also produces false positives and should not be interpreted as definitive evidence of problem–solution flow. Technical signals recur across spaces even without explicit links. Technical-signal overlap provides a broader view of recurring maintenance and support concerns across artifact types. Table 21 shows that forum discussions were dominated by user-facing execution and infrastructure signals, including workflow execution (83.69%), execution errors (52.85%), configuration (48.60%), cloud (27.04%), 32

Table 21: Technical signal overlap across forum discussions, issues, and pull requests Signal

Forum Issues Pull requests

Execution error Workflow execution Container/runtime Cloud HPC MultiQC/reporting Testing/linting Docs/training Dependency update Template sync Module/subworkflow Configuration Channel/dataflow

52.85% 83.69% 26.37% 27.04% 18.77% 23.35% 52.96% 16.09% 23.13% 4.92% 14.30% 48.60% 51.17%

36.50% 58.91% 16.30% 6.19% 9.50% 14.36% 43.63% 11.34% 26.44% 6.72% 27.72% 25.60% 39.14%

52.80% 61.66% 22.51% 3.21% 2.24% 7.08% 65.98% 54.12% 64.07% 15.19% 27.93% 31.49% 47.01%

Note. Values are percentages of artifacts containing each signal. Signals are not mutually exclusive, so percentages within each artifact type may sum to more than 100%.

and HPC (18.77%). Pull requests showed a more implementation-oriented profile, with high levels of testing/linting (65.98%), dependency updates (64.07%), documentation/training (54.12%), and template synchronization (15.19%). Issues occupied an intermediate position, where execution problems, testing/linting, channel/dataflow behavior, and module/subworkflow concerns were formalized as repository-level maintenance tasks. These overlaps suggest that similar technical concerns move across the ecosystem even when direct links are missing. For example, execution and configuration problems appear prominently in forum discussions as user-support needs, appear in issues as repository-level problem reports, and appear in pull requests as tests, fixes, documentation updates, dependency changes, or template improvements. However, because signal overlap is aggregate-level evidence, it should not be interpreted as proof that specific forum posts caused specific GitHub changes. Instead, it indicates that recurring support concerns and repository maintenance work share common technical domains.

Synthesis of problem–solution flow. Together, the three analyses show a layered pattern of traceability. Explicit links provide strong evidence that GitHub is the main traceable space where nf-core problems are connected to implementation work. Semantic similarity reveals additional candidate issue–pull request relationships that are not explicitly linked, suggesting that repository maintenance contains more related work than direct references alone capture. Technical-signal overlap shows that forum discussions, issues, and pull requests share recurring technical concerns, especially around execution, configuration, containers, cloud, HPC, reporting, testing, dependencies, and documentation. However, the weakest layer is explicit forum–GitHub traceability. Forum discussions frequently contain support problems that overlap with GitHub maintenance concerns, but they are rarely linked to repository artifacts. This means that user-facing support knowledge often enters repository maintenance indirectly, if at all. Strengthening lightweight links between forum threads, GitHub issues, pull requests, and documentation updates could help convert recurring support problems into more durable ecosystem improvements. Summary of RQ4. RQ4 shows that problem–solution flow in nf-core is strongly traceable within GitHub but weakly connected across GitHub and the Seqera Community Forum. Direct-link analysis identified dense repository-internal connections, especially pull request-to-issue references (7,599 links), showing that GitHub is the main space where reported problems are converted into implementation work. In contrast, explicit Forum–GitHub links were rare, with only five forum-to-GitHub and six GitHub-to-forum links, despite substantial technical-signal overlap across these spaces. Semantic similarity revealed additional implicit issue–pull request relationships, including 5,985 candidate issue-to-pull-request flows with a median lag of 18.27 days. Overall, nf-core has strong issue–pull request traceability, but user-facing support knowledge from forum discussions often enters repository maintenance indirectly through recurring technical concerns rather than explicit cross-platform links.

5 Discussion Our findings show that sustaining nf-core requires more than workflow engines, standardized templates, and automated testing. Maintenance and support are distributed across several artifact types that play different roles in the ecosystem. GitHub issues surface problems and coordination needs, pull requests implement and validate 33

changes, and forum discussions expose user-facing execution barriers that often depend on local infrastructure. This section discusses the implications of these findings for nf-core, for community-driven scientific pipeline ecosystems, and for empirical research on software maintenance in scientific computing.

5.1 Maintenance and Support Are Distributed Across Artifact Types A central finding of this study is that nf-core maintenance is distributed across complementary socio-technical spaces. Issues, pull requests, and forum discussions do not simply provide different samples of the same activity. They capture different stages and forms of ecosystem work. Issues function as a repository-centered space for reporting problems, requesting features, tracking migrations, coordinating module work, and formalizing maintenance tasks. Pull requests represent the implementation and integration layer, where changes are reviewed, tested, standardized, and merged. Forum discussions reveal practical support problems that arise when users run workflows across local machines, HPC clusters, cloud platforms, containers, and managed execution services. This division of work is important for understanding scientific pipeline sustainability. Scientific workflow research often emphasizes portability, reproducibility, and execution across heterogeneous infrastructure. Our results show that these properties are not maintained by workflow specifications alone. They require continuous work on modules, subworkflows, sample sheets, test datasets, templates, containers, dependency versions, execution profiles, documentation, and user support. In this sense, nf-core should be understood not only as a collection of reusable pipelines, but also as a maintained infrastructure whose sustainability depends on coordinated repository work and community support. This finding also supports the value of a cross-artifact study design. An analysis limited to GitHub issues and pull requests would capture repository-centered maintenance but miss many operational barriers encountered by users. An analysis limited to forum discussions would reveal user difficulties but miss how durable repositorylevel changes are implemented. Studying these spaces together provides a more complete account of how scientific pipeline ecosystems are sustained.

5.2 Resolution Depends on Actionability, Coordination, and Diagnostic Evidence Across issues, pull requests, and forum discussions, resolution outcomes were associated with actionability, coordination, and diagnostic evidence. Issues were more likely to close, and closed faster, when they had assignees, comments, milestones, bug labels, error mentions, and version information. Pull requests were more likely to merge when they included review-readiness signals such as checklists, fix/test framing, linked issues, requested reviewers, and contributor or maintainer authorship. Forum discussions were more likely to receive accepted answers when they included code blocks, concrete technical evidence, and sustained interaction. These patterns should not be interpreted causally. Features such as assignees, comments, requested reviewers, replies, or likes often emerge during the handling of an artifact and may reflect maintainer attention, artifact priority, or community engagement. They are therefore process signals, not necessarily independent causes of resolution. Nevertheless, their consistent association with resolution across artifact types suggests that nf-core artifacts are easier to resolve when they provide enough context for maintainers or community members to understand the problem and act on it. This has practical implications for issue templates, pull request checklists, and forum posting guidelines. These mechanisms are not merely administrative. They help transform ambiguous reports into actionable maintenance objects. For scientific pipelines, this is especially important because failures may involve tool versions, input files, reference datasets, profiles, containers, executors, scheduler policies, storage systems, and cloud credentials. Templates and guidelines that prompt users to provide commands, versions, profiles, logs, executor settings, container details, and minimal reproducible examples could improve diagnosability and reduce repeated clarification work.

5.3 Infrastructure-Specific Support Remains a Persistent Boundary The forum results highlight a persistent boundary in scientific workflow support: many difficult problems arise from the interaction between workflows and execution environments rather than from pipeline code alone. Cloud, HPC, container, configuration, and scheduler-related discussions were prominent in the forum and were less consistently resolved through accepted answers. These questions often depend on local information that maintainers cannot easily reproduce, such as institutional scheduler policies, storage permissions, private registries, cloud credentials, queue limits, memory constraints, and executor-specific behavior. This suggests that documentation focused only on pipeline parameters is insufficient. Users also need infrastructure-oriented guidance, including tested execution profiles, examples for common HPC schedulers, cloud deployment recipes, storage and permission checklists, container troubleshooting guides, and guidance on collecting diagnostic logs. Forum discussions can help identify where such guidance is missing. Even when a forum thread 34

does not correspond to a pipeline defect, it may reveal a recurring usability or infrastructure pain point that can be addressed through better documentation, examples, templates, or profile validation. The finding also suggests that accepted-answer status should be interpreted cautiously. Some unresolved forum discussions may still be useful to later users because they contain logs, partial explanations, workarounds, or infrastructure-specific context. Thus, the absence of an accepted answer does not necessarily mean the discussion has no value; rather, it indicates that the forum did not reach a formally marked resolution.

5.4 Automation Helps When It Aligns with Review Workflows Automation is central to nf-core maintenance, but our results show that automated maintenance is not uniformly successful. Renovate pull requests had very high merge rates, while Dependabot and other bot-authored pull requests were less consistently integrated and were more often closed without merge. This difference suggests that automation is most useful when its output is scoped, predictable, compatible with nf-core validation workflows, and easy for maintainers to review. This finding has broader implications for scientific software ecosystems that rely on automated dependency updates, template propagation, and continuous integration. Automation should not be evaluated only by the number of pull requests it creates. Its value depends on whether it produces reviewable and context-aware changes. Automated updates that are noisy, obsolete, poorly scoped, or difficult to validate may increase maintainer workload rather than reduce it. Ecosystems such as nf-core may benefit from automation policies that distinguish routine low-risk updates from higher-risk changes, provide clearer evidence for automated updates, and route automation-generated pull requests to appropriate maintainers or validation workflows.

5.5 Cross-Artifact Traceability Is a Missing Layer of Support Infrastructure RQ4 shows that nf-core has strong repository-internal traceability but weak explicit traceability between GitHub and the Seqera Community Forum. Pull request-to-issue links provide a visible pathway from reported problems to implementation work inside GitHub. In contrast, explicit links between forum discussions and GitHub artifacts were rare, despite substantial technical-signal overlap across forum discussions, issues, and pull requests. This creates an important maintenance gap. Forum discussions often contain maintenance-relevant knowledge about recurring execution failures, documentation gaps, confusing errors, cloud and HPC configuration, container behavior, and pipeline usability. However, when these discussions are not linked to GitHub issues, pull requests, or documentation updates, the knowledge may remain local to the support thread. In such cases, forum support may help individual users without necessarily becoming durable ecosystem improvement. Semantic similarity analysis suggests that related maintenance work may occur even without explicit links, but these pairs should be interpreted only as candidate implicit relationships. Textual similarity and temporal ordering do not prove that one artifact caused or informed another. The stronger and more actionable finding is therefore the lack of visible forum–GitHub traceability. Lightweight linking practices could help close this gap. For example, recurring forum discussions could be periodically triaged into documentation issues, infrastructuresupport issues, or template-improvement tasks. Forum posts could encourage users or maintainers to link related GitHub issues, and GitHub issue templates could include prompts for related forum discussions. Such mechanisms would make support knowledge more discoverable and easier to convert into repository-level maintenance.

5.6 Implications for nf-core and Similar Scientific Workflow Ecosystems Although this study focuses on nf-core, the findings are relevant to other scientific workflow ecosystems that combine reusable workflows, shared components, community support, and heterogeneous execution infrastructure. Ecosystems such as Galaxy, Snakemake, Pegasus, and related community-maintained workflow platforms face similar sustainability challenges: workflows must remain executable as dependencies, containers, reference data, schedulers, cloud services, and user environments change. The results suggest three broader lessons. First, community support spaces should be treated as maintenancerelevant evidence, not only as help channels. Support discussions can reveal recurring problems before they become formal issues. Second, resolution mechanisms should be designed to improve actionability by encouraging structured diagnostic evidence and clear routing. Third, cross-artifact traceability should be considered part of ecosystem infrastructure. Without links between support discussions and repository-level changes, recurring user problems may remain visible but unresolved at the ecosystem level.

5.7 Actionable Recommendations Based on these findings, we identify five actionable recommendations for nf-core and similar community-driven scientific pipeline ecosystems. 35

Table 22: Actionable recommendations derived from the cross-artifact analysis. Area

Recommendation

Issue reporting

Strengthen issue templates with prompts for pipeline version, command, profile, executor, container runtime, logs, relevant files, and minimal reproducible examples. Preserve checklist-based review readiness, but distinguish routine updates from coordination-intensive changes requiring domain-specific review. Evaluate automated pull requests by mergeability, scope, validation evidence, and maintainer burden, not only by update frequency. Add structured forum prompts for cloud, HPC, container, and executor-related questions, including scheduler, storage, credential, profile, and log details. Encourage lightweight links between forum discussions, GitHub issues, pull requests, and documentation updates when support threads reveal recurring problems.

Pull request review Automation Forum support Traceability

These recommendations follow directly from the observed patterns. Artifacts with clearer diagnostic information were more often resolved; review-ready pull requests were more consistently integrated; infrastructure-specific questions were harder to answer; and forum knowledge was weakly linked to repository maintenance. Improving structure, routing, and traceability can therefore help convert recurring support needs into durable ecosystem improvements. Overall, this study shows that maintaining reusable scientific pipelines is a continuous coordination problem. Workflow engines, templates, automated tests, and containers provide essential technical foundations, but they do not eliminate the need for ongoing maintenance and user support. nf-core remains sustainable because contributors and users collectively report problems, review changes, update dependencies, maintain templates, troubleshoot infrastructure, and share knowledge. The main challenge is to make this distributed work more actionable and traceable. Stronger diagnostic templates, review-aware automation, infrastructure-specific guidance, and lightweight links between support and repository artifacts can help scientific pipeline ecosystems turn recurring user problems into maintainable, reusable, and durable improvements.

6 Threats to Validity Threats to validity are factors that may affect the accuracy, reliability, or generalizability of study findings. They concern how research conclusions may diverge from reality [77]. In this study, we acknowledge the following potential threats to validity.

6.1 Construct Validity A threat to construct validity concerns whether our measures accurately capture maintenance, support, resolution, and problem–solution flow [78]. We used issue closure, pull request merge or closed-without-merge status, and forum accepted-answer status as observable resolution outcomes. These measures follow the conventions of each artifact type, but they may not capture all forms of resolution. For example, a closed issue may not fully solve the underlying problem, a merged pull request may address only part of a larger maintenance task, and a forum discussion may be useful even without an accepted answer. Textual and technical-signal features also introduce measurement risk. Signals such as cloud, HPC, containers, configuration, testing, and dependency updates were detected using keyword-based rules, which may miss relevant cases or include false positives. Similarly, BERTopic clusters summarize recurring themes but do not perfectly separate artifacts that contain multiple concerns. We mitigated these risks by using domain-informed signal definitions, modeling each artifact type separately, tuning topic-model parameters, and manually inspecting representative artifacts before assigning topic labels.

6.2 External Validity Our findings are based on nf-core, a mature and highly structured ecosystem of standardized Nextflow pipelines. The exact topic distributions, resolution rates, and traceability patterns may not generalize to smaller projects, less formal workflow communities, or ecosystems with different governance and review practices. However, many challenges observed in nf-core, including dependency updates, container failures, cloud and HPC execution, input validation, documentation gaps, and user support, are common across scientific workflow ecosystems. Thus, while the numeric results are nf-core-specific, the broader implications may apply to ecosystems such as Galaxy, Snakemake, Pegasus, and related community-maintained workflow platforms.

6.3 Internal Validity This study is observational, so the reported associations should not be interpreted as causal effects. Features such as assignees, comments, milestones, requested reviewers, checklists, or code blocks may be associated with resolution because they improve actionability, but they may also reflect unobserved factors such as artifact priority, maintainer availability, contributor expertise, or pipeline maturity. For example, assigned issues may close faster because assignment improves accountability, or because maintainers assign issues that are already more actionable. Temporal interpretation also requires caution. Some maintenance and support work may occur outside the observed artifacts, such as private communication, local debugging, or informal coordination. For forum discussions, accepted-answer timestamps were unavailable, so we used activity span as a lifecycle proxy rather than exact time-to-answer. For RQ4, semantic-flow pairs indicate textual relatedness and plausible temporal ordering, but they do not prove that one artifact directly caused or informed another. We therefore interpret them as candidate implicit flows, not definitive problem–solution links.

6.4 Conclusion Validity Large repository-mining datasets can produce statistically significant results even when effects are small. To reduce this threat, we reported odds ratios, hazard ratios, median differences, and effect sizes where appropriate, and applied Benjamini–Hochberg correction for multiple comparisons. We also interpreted findings based on consistency across descriptive statistics, bivariate tests, regression models, lifecycle curves, and qualitative inspection. Some models required feature pruning or regularization because the data contained sparse categories, correlated predictors, and skewed distributions. Regularized model coefficients should therefore be read as adjusted directional associations rather than formal causal estimates. We avoid overinterpreting individual coefficients and focus on patterns that recur across analyses.

7 Conclusion This study examined maintenance and support in nf-core through a cross-platform analysis of 15,760 GitHub issues, 35,411 GitHub pull requests, and 895 Seqera Community Forum discussions. The findings show that nf-core maintenance is distributed across complementary spaces: issues capture problem reporting and coordination, pull requests capture implementation and integration, and forum discussions capture user-facing execution support. Across these spaces, resolution was associated with actionability, coordination, and diagnostic evidence. Issues closed more effectively when they included maintainer attention and concrete technical details; pull requests merged more consistently when they were review-ready, traceable, and supported by tests or checklists; and forum discussions were more likely to receive accepted answers when they included code, interaction, and sufficient diagnostic context. However, infrastructure-specific problems involving cloud, HPC, containers, and workflow semantics remained harder to resolve. The problem–solution flow analysis showed strong traceability within GitHub, especially through pull requestto-issue links, but weak explicit linkage between forum discussions and repository artifacts. This suggests that user-facing support knowledge often informs maintenance indirectly rather than through visible cross-platform connections. Strengthening links between forum discussions, GitHub issues, pull requests, and documentation updates could help convert recurring support problems into durable ecosystem improvements. Overall, sustaining community-driven scientific pipeline ecosystems requires not only workflow engines, templates, containers, and tests, but also coordinated maintenance practices, actionable support processes, and stronger traceability across development and user-support spaces. Future work can extend this study by comparing nf-core with other scientific workflow ecosystems and by evaluating traceability mechanisms that connect recurring forum support problems to GitHub issues, pull requests, and documentation updates.

Acknowledgments This research is supported in part by the Natural Sciences and Engineering Research Council of Canada (NSERC), and by the industry-stream NSERC CREATE in Software Analytics Research (SOAR).

Data Availability Statements Our replication package can be found in our online appendix [79].

Conflict of Interest We have no conflict of interest.

References [1] Ewels, P.A., Peltzer, A., Fillinger, S., Patel, H., Alneberg, J., Wilm, A., Garcia, M.U., Di Tommaso, P., Nahnsen, S.: The nf-core framework for community-curated bioinformatics pipelines. Nature biotechnology 38(3), 276–278 (2020) [2] Liu, J., Pacitti, E., Valduriez, P., Mattoso, M.: A survey of data-intensive scientific workflow management. Journal of Grid Computing 13, 457–493 (2015) [3] Alam, K., Roy, B.: Analyzing github issues and pull requests in nf-core pipelines: Insights into nf-core pipeline repositories. arXiv preprint arXiv:2601.09612 (2026) [4] Di Tommaso, P., Chatzou, M., et al.: Nextflow enables reproducible computational workflows. Nature biotechnology 35(4), 316–319 (2017) [5] Sansone, S.-A., McQuilton, P., Rocca-Serra, P., Gonzalez-Beltran, A., Izzo, M., Lister, A.L., Thurston, M., Community, F.: Fairsharing as a community approach to standards, repositories and policies. Nature biotechnology 37(4), 358–367 (2019) [6] Wilkinson, M.D., Dumontier, M., Aalbersberg, I.J., Appleton, G., Axton, M., Baak, A., Blomberg, N., Boiten, J.-W., Silva Santos, L.B., Bourne, P.E., et al.: The fair guiding principles for scientific data management and stewardship. Scientific data 3(1), 1–9 (2016) [7] Cohen-Boulakia, S., Belhajjame, K., et al.: Scientific workflows for computational reproducibility in the life sciences: Status, challenges and opportunities. FGCS 75, 284–298 (2017) [8] Wratten, L., Wilm, A., Göke, J.: Reproducible, scalable, and shareable analysis pipelines with bioinformatics workflow managers. Nature methods 18(10), 1161–1168 (2021) [9] Barker, M., Chue Hong, N.P., Katz, D.S., Lamprecht, A.-L., Martinez-Ortiz, C., Psomopoulos, F., Harrow, J., Castro, L.J., Gruenpeter, M., Martinez, P.A., et al.: Introducing the fair principles for research software. Scientific data 9(1), 622 (2022) [10] Alam, K., Roy, B., Roy, C.K., Mittal, K.: An empirical investigation on the challenges in scientific workflow systems development. Empirical Software Engineering 30(5), 151 (2025) [11] Köster, J., Rahmann, S.: Snakemake—a scalable bioinformatics workflow engine. Bioinformatics 28(19), 2520– 2522 (2012) [12] Goecks, J., Nekrutenko, A., et al.: Galaxy: a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences. Genome biology 11, 1–13 (2010) [13] Deelman, E., Vahi, K., et al.: Pegasus, a workflow management system for science automation. FGCS 46, 17–35 (2015) [14] Oinn, T., Addis, M., Ferris, J., Marvin, D., Senger, M., Greenwood, M., Carver, T., Glover, K., Pocock, M.R., Wipat, A., et al.: Taverna: a tool for the composition and enactment of bioinformatics workflows. Bioinformatics 20(17), 3045–3054 (2004) [15] Suter, F., Coleman, T., Altintaş, İ., Badia, R.M., Balis, B., Chard, K., Colonnelli, I., Deelman, E., Di Tommaso, P., Fahringer, T., et al.: A terminology for scientific workflow systems. Future Generation Computer Systems 174, 107974 (2026) [16] Leipzig, J.: A review of bioinformatic pipeline frameworks. Briefings in bioinformatics 18(3), 530–536 (2017) [17] Da Silva, R.F., Filgueira, R., Pietri, I., Jiang, M., Sakellariou, R., Deelman, E.: A characterization of workflow management systems for extreme-scale applications. Future Generation Computer Systems 75, 228–238 38

(2017) [18] Langer, B.E., Amaral, A., Baudement, M.-O., Bonath, F., Charles, M., Chitneedi, P.K., Clark, E.L., Di Tommaso, P., Djebali, S., Ewels, P.A., et al.: Empowering bioinformatics communities with nextflow and nf-core. Genome Biology 26(1), 228 (2025) [19] Jansen, S., Finkelstein, A., Brinkkemper, S.: A sense of community: A research agenda for software ecosystems. In: 2009 31st International Conference on Software Engineering-Companion Volume, pp. 187–190 (2009). IEEE [20] Manikas, K.: Revisiting software ecosystems research: A longitudinal literature study. Journal of Systems and Software 117, 84–103 (2016) [21] Storey, M.-A., Zagalsky, A., Figueira Filho, F., Singer, L., German, D.M.: How social and communication channels shape and challenge a participatory culture in software development. IEEE Transactions on Software Engineering 43(2), 185–204 (2016) [22] Preston-Werner, T.: GitHub Issue Tracker! GitHub Blog. Updated: January 4, 2019; Accessed: 2026-04-09 (2009). https://github.blog/news-insights/github-issue-tracker/ [23] Tomayko, R.: Pull Requests 2.0. https://github.blog/news-insights/pull-requests-2-0/. Updated: 2019-12-16; Accessed: 2026-05-30 (2010) [24] Seqera: Seqera Community. https://community.seqera.io/. Accessed: 2026-04-21 (2026) [25] Tsay, J., Dabbish, L., Herbsleb, J.: Influence of social and technical factors for evaluating contribution in github. In: Proceedings of the 36th International Conference on Software Engineering, pp. 356–366 (2014) [26] Gousios, G., Pinzger, M., Deursen, A.v.: An exploratory study of the pull-based software development model. In: Proceedings of the 36th International Conference on Software Engineering, pp. 345–355 (2014) [27] Kalliamvakou, E., Gousios, G., Blincoe, K., Singer, L., German, D.M., Damian, D.: An in-depth study of the promises and perils of mining github. Empirical Software Engineering 21(5), 2035–2071 (2016) [28] Hata, H., Novielli, N., Baltes, S., Kula, R.G., Treude, C.: Github discussions: An exploratory study of early adoption. Empirical Software Engineering 27(1), 3 (2022) [29] Hellman, J., Chen, J., Uddin, M.S., Cheng, J., Guo, J.L.: Characterizing user behaviors in open-source software user forums: an empirical study. In: Proceedings of the 15th International Conference on Cooperative and Human Aspects of Software Engineering, pp. 46–55 (2022) [30] Rahman, M.S., Codabux, Z., Roy, C.K.: Investigating the understandability of review comments on code change requests. In: 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR), pp. 539–551 (2025). IEEE [31] Kalliamvakou, E., Gousios, G., Blincoe, K., Singer, L., German, D.M., Damian, D.: The promises and perils of mining github. In: Proceedings of the 11th Working Conference on Mining Software Repositories, pp. 92–101 (2014) [32] Rahman, M.M., Roy, C.K.: An insight into the pull requests of github. In: Proceedings of the 11th Working Conference on Mining Software Repositories, pp. 364–367 (2014) [33] Djaffardjy, M., Marchment, G., Sebe, C., Blanchet, R., Belhajjame, K., Gaignard, A., Lemoine, F., CohenBoulakia, S.: Developing and reusing bioinformatics data analysis pipelines using scientific workflow systems. Computational and Structural Biotechnology Journal 21, 2075–2085 (2023) [34] Alam, K., Roy, B., Serebrenik, A.: Reusability challenges of scientific workflows: A case study for galaxy. In: 2023 30th APSEC, pp. 289–298 (2023). IEEE [35] Goble, C., Cohen-Boulakia, S., Soiland-Reyes, S., Garijo, D., Gil, Y., Crusoe, M.R., Peters, K., Schober, D.: Fair computational workflows. Data Intelligence 2(1-2), 108–121 (2020) 39

[36] Alam, K., Roy, B.: Challenges of provenance in scientific workflow management systems. In: 2022 IEEE/ACM Workshop on Workflows in Support of Large-Scale Science (WORKS), pp. 10–18 (2022). IEEE [37] Braga, P.H.P., Hébert, K., Hudgins, E.J., Scott, E.R., Edwards, B.P., Sánchez Reyes, L.L., Grainger, M.J., Foroughirad, V., Hillemann, F., Binley, A.D., et al.: Not just for programmers: How github can accelerate collaborative and reproducible research in ecology and evolution. Methods in Ecology and Evolution 14(6), 1364–1380 (2023) [38] Tan, S.H., Li, Z., Yan, L.: Crossfix: Resolution of github issues via similar bugs recommendation. Journal of Software: Evolution and Process 36(4), 2554 (2024) [39] Soares, D.M., Lima Júnior, M.L., Murta, L., Plastino, A.: Acceptance factors of pull requests in open-source projects. In: Proceedings of the 30th Annual ACM Symposium on Applied Computing, pp. 1541–1546 (2015) [40] Lenarduzzi, V., Nikkola, V., Saarimäki, N., Taibi, D.: Does code quality affect pull request acceptance? an empirical study. Journal of Systems and Software 171, 110806 (2021) [41] Han, J., Shihab, E., Wan, Z., Deng, S., Xia, X.: What do programmers discuss about deep learning frameworks. Empirical Software Engineering 25, 2694–2747 (2020) [42] Li, H., Khomh, F., Openja, M., et al.: Understanding quantum software engineering challenges an empirical study on stack exchange forums and github issues. In: ICSME, pp. 343–354. IEEE, ??? (2021). IEEE [43] Yang, Z., Wang, C., Shi, J., Hoang, T., Kochhar, P., Lu, Q., Xing, Z., Lo, D.: What do users ask in opensource ai repositories? an empirical study of github issues. In: 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR), pp. 79–91 (2023). IEEE [44] Jelodar, H., Wang, Y., Yuan, C., Feng, X., Jiang, X., Li, Y., Zhao, L.: Latent dirichlet allocation (lda) and topic modeling: models, applications, a survey. Multimedia Tools and Applications 78, 15169–15211 (2019) [45] Asuncion, H.U., Asuncion, A.U., Taylor, R.N.: Software traceability with topic modeling. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 1, pp. 95–104 (2010) [46] Bagheri, A., Saraee, M., De Jong, F.: Adm-lda: An aspect detection model based on topic modelling using the structure of review sentences. Journal of Information Science 40(5), 621–636 (2014) [47] Gethers, M., Poshyvanyk, D.: Using relational topic models to capture coupling among classes in objectoriented software systems. In: 2010 IEEE International Conference on Software Maintenance, pp. 1–10 (2010). IEEE [48] Nadi, S., Krüger, S., Mezini, M., Bodden, E.: Jumping through hoops: Why do java developers struggle with cryptography apis? In: Proceedings of the 38th International Conference on Software Engineering, pp. 935–946 (2016) [49] Scoccia, G.L., Migliarini, P., Autili, M.: Challenges in developing desktop web apps: a study of stack overflow and github. In: 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR), pp. 271–282 (2021). IEEE [50] Kahani, N., Bagherzadeh, M., Dingel, J., Cordy, J.R.: The problems with eclipse modeling tools: a topic analysis of eclipse forums. In: Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems, pp. 227–237 (2016) [51] Barker, H.A., Lee, H.S., Kellogg, S., Anderson, R.: The viability of topic modeling to identify participant motivations for enrolling in online professional development. Online Learning 28(1), 175–195 (2024) [52] Dhasade, A.B., Venigalla, A.S.M., Chimalakonda, S.: Towards prioritizing github issues. In: Proceedings of the 13th Innovations in Software Engineering Conference on Formerly Known as India Software Engineering Conference, pp. 1–5 (2020) [53] Jokhio, M.: Mining github issues for bugs, feature requests and questions. ” (2021)

[54] Wang, X., Lee, M., Pinchbeck, A., Fard, F.: Where does lda sit for github? In: 2019 34th IEEE/ACM International Conference on Automated Software Engineering Workshop (ASEW), pp. 94–97 (2019). IEEE [55] Blei, D.M., Ng, A.Y., Jordan, M.I.: Latent dirichlet allocation. Journal of machine Learning research 3(Jan), 993–1022 (2003) [56] Grootendorst, M.: Bertopic: Neural topic modeling with a class-based tf-idf procedure. arXiv preprint arXiv:2203.05794 (2022) [57] Langer, B.E., Amaral, A., et al.: Empowering bioinformatics communities with nextflow and nf-core. bioRxiv, 2024–05 (2024) [58] Hardeniya, N., Perkins, J., Chopra, D., Joshi, N., Mathur, I.: Natural Language Processing: Python and NLTK. Packt Publishing Ltd, ??? (2016) [59] Vasiliev, Y.: Natural Language Processing with Python and spaCy: A Practical Introduction. No Starch Press, San Francisco, CA 94103, USA (2020) [60] Reimers, N., Gurevych, I.: Sentence-bert: Sentence embeddings using siamese bert-networks. In: Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), pp. 3982–3992 (2019) [61] Sentence Transformers community: Sentence Transformers — Hugging Face Hub. https://huggingface.co/ sentence-transformers. Accessed: 2025-10-07 (2025) [62] Community, H.F.: Hugging Face Models. https://huggingface.co/models. Accessed: 2025-10-07 (2025) [63] McInnes, L., Healy, J., Melville, J.: Umap: Uniform manifold approximation and projection for dimension reduction. arXiv preprint arXiv:1802.03426 (2018) [64] McInnes, L., Healy, J., Astels, S., et al.: hdbscan: Hierarchical density based clustering. J. Open Source Softw. 2(11), 205 (2017) [65] Röder, M., Both, A., Hinneburg, A.: Exploring the space of topic coherence measures. In: Proceedings of the Eighth ACM International Conference on Web Search and Data Mining, pp. 399–408 (2015) [66] Abdellatif, A., Costa, D., Badran, K., Abdalkareem, R., Shihab, E.: Challenges in chatbot development: A study of stack overflow posts. In: MSR, pp. 174–185 (2020) [67] Agresti, A.: Categorical Data Analysis. John Wiley & Sons, Hoboken, New Jersey. (2013) [68] Fagerland, M., Lydersen, S., Laake, P.: Statistical Analysis of Contingency Tables. Chapman and Hall/CRC, Boca Raton, Florida (2017) [69] Benjamini, Y., Yekutieli, D.: The control of the false discovery rate in multiple testing under dependency. Annals of statistics, 1165–1188 (2001) [70] Hosmer Jr, D.W., Lemeshow, S., Sturdivant, R.X.: Applied Logistic Regression. John Wiley & Sons, Hoboken, New Jersey. (2013) [71] Kalbfleisch, J.D., Schaubel, D.E.: Fifty years of the cox model. Annual Review of Statistics and Its Application 10(1), 1–23 (2023) [72] Friedman, J.H., Hastie, T., Tibshirani, R.: Regularization paths for generalized linear models via coordinate descent. Journal of statistical software 33, 1–22 (2010) [73] D’Arrigo, G., Leonardis, D., Abd ElHafeez, S., Fusaro, M., Tripepi, G., Roumeliotis, S.: Methods to analyse time-to-event data: The kaplan-meier survival curve. Oxidative medicine and cellular longevity 2021(1), 2290120 (2021) [74] Openja, M., Adams, B., Khomh, F.: Analysis of modern release engineering topics:–a large-scale study using

stackoverflow–. In: 2020 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 104–114 (2020). IEEE [75] Yang, X.-L., Lo, D., Xia, X., Wan, Z.-Y., Sun, J.-L.: What security questions do developers ask? a large-scale study of stack overflow posts. JCST 31, 910–924 (2016) [76] Bagherzadeh, M., Khatchadourian, R.: Going big: a large-scale study on what big data developers ask. In: Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pp. 432–442 (2019) [77] Bean, C.J.: Qualitative research design: An interactive approach. Organizational Research Methods 10(2), 393 (2007) [78] Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in software engineering. Springer Science & Business Media (2012) [79] Anonymous: Artifact of the Paper “Maintenance and Support in Community-Driven Scientific Pipeline Ecosystems: A Cross-Platform Empirical Study of Nf-core”. https://doi.org/10.5281/zenodo.21324489 . https://doi.org/10.5281/zenodo.21324489

Record · ID 363332 · SHA-256 0f93a4d85e125ffa
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.