<!subteam^S044DU0NG68> (and especially <!subteam^S016E36N7TQ>) I would be grateful if people find a spare 10 minutes to look through the new-pipeline proposals: https://github.com/nf-core/proposals/issues?q=is%3Aissue%20state%3Aopen%20label%3Anew-pipeline They are starting to pile up and we need more input.

How does it work with a rejection? For example nf-core/dragen has no approvals, 4 people with concerns, and no proposed solution to that blocker from the proposer.

People with concerns should give a

/reject

Gotcha, I will make my rejection explicit now then.

TIME TO TEST!

You'd tentatively approved https://github.com/nf-core/proposals/issues/147 before I started whining James, but I think it's a no

Yeah that one is OK, you've been helpful on that one 😉 (and thank you!) You can give a /reject if so

🤖 Summary to help folks out below. I don't know enough about a lot of the applications to comment myself nf-core new-pipeline proposals — review summary Ground rule applied throughout: workflow_specificity — one pipeline per data+analysis type, no organism-specific pipelines unless the tooling genuinely can't generalise, extend existing pipelines rather than duplicate. (https://nf-co.re/docs/specifications/pipelines/requirements/workflow_specificity) CLEAR REJECTS (already actioned) ❌ #147 cl-exfoliome — https://github.com/nf-core/proposals/issues/147 Already rejected (by me), correctly. Standard bulk RNA-seq (UMI extract -> trim -> bowtie2 -> dedup -> count) on a specific sample type (exfoliated faecal material). Tool order is identical to rnaseq, the bowtie2 "optimization" is just --extra_bowtie2_align_args, bowtie2->Salmon is already a path, and the only real gap (htseq-count) is the wrong tool anyway. Textbook sample-type-specific reject. ❌ #137 dragen — https://github.com/nf-core/proposals/issues/137 Already rejected 3x. Untestable in nf-core CI (proprietary, licensed, hardware-bound; author proposes stubs only), which breaks collaboration and the Megatest/results convention. Sentieon/parabricks are testable; DRAGEN isn't. Clean reject, done. CLEAR-ISH ACCEPTS (with conditions) ✅ #142 midas (microbiome differential abundance) — https://github.com/nf-core/proposals/issues/142 Closest to a done deal — jfy133 gave a conditional approve, I backed it. Genuinely novel: the simulation-trained soft consensus (MIDASim ground truth -> per-tool scoring -> optimal weighting) has no analogue in differentialabundance, and the phyloseq input + compositional tool bundle don't fit DA. Conditions, not blockers: (1) name — "midas" collides with the famous metagenomics MIDAS; (2) split the one-giant-R-container into per-process containers; (3) keep R scripts thin. ✅ #127 shallowseq — https://github.com/nf-core/proposals/issues/127 Trending to accept. sarek lead (maxulysse) "definitively not opposed" given the agreed condition: share sarek's preprocessing as a subworkflow rather than duplicate. The sWGS CNV tooling (QDNAseq, WisecondorX, ichorCNA, Rascal/ACE) is genuinely distinct — sarek/oncoanalyser lean on depth-hungry tools that fail on shallow/FFPE. Conditions: name (shallowseq -> lowpasswgs/swgs), shared preprocessing subworkflow, drop the bespoke "Azure" process (Nextflow handles that natively). ✅ #126 transporter — https://github.com/nf-core/proposals/issues/126 One maintainer (mahesh-panchal) already approved. Real gap: reference-guided annotation transfer between related (not identical) genomes is not same-genome liftover, and nothing in the corpus does it. Published, real-world use. Conditions: name too generic ("transporter"); fold in ammaraziz's suggestion (VADR first pass, BLAST fallback, NCBI .tbl output). Caveat: author has gone quiet on the last feedback round — needs a nudge before formal approval. REJECT AS PROPOSED, BUT SALVAGEABLE ⚠️ #134 hapmal / plasmodiumhapres — https://github.com/nf-core/proposals/issues/134 As proposed (Plasmodium-specific) this is a reject on workflow_specificity — ewels/jfy133/LouisLeNezet all said so. Core tools (Minimap2, Clair3, Snippy, BBDuk) aren't organism-specific and overlap bactmap; "field deployment / naming / audience" aren't workflow-distinctness arguments. Authors have essentially conceded and now accept a -profile plasmodium approach. The one genuinely novel axis is the multiclonal layer (MOI / IBD / mixed-infection deconvolution / resistance-marker panels) — nf-core search returns nothing for those. Path: reject the organism-specific framing, accept a generic surveillance/haplotype pipeline carrying that novel layer with a plasmodium profile, if it doesn't fit a resurrected/archived bactmap. Engaged, large team — worth steering, not killing. ⚠️ #115 spatialflow — https://github.com/nf-core/proposals/issues/115 Lean reject as proposed. Heavy overlap with spatialvi, spatialxe, sopa, and the freshly-accepted scspatialmap; scope is large (author's own estimate ~12 modules). Thread surfaced a real unresolved meta-architecture question — tech-specific end-to-end pipelines with shared downstream modules (fasterius/cavenel) vs. a single tech-agnostic spatialdownstream (Zethson/heylf). Multiple maintainers lean toward "write modules/subworkflows, not a new pipeline." Shouldn't be approved until the spatial community holds the proposed call and settles the architecture. Downstream-only reframing could be OK; the current kitchen-sink proposal isn't. GENUINELY BORDERLINE — NO CLEAR CALL ❔ #148 snv-sort-and-fold — https://github.com/nf-core/proposals/issues/148 Analysis type is genuinely missing (SHAPE/DMS mutational profiling -> SNV read sorting -> signature deconvolution -> ViennaRNA folding; dartseq is m6A, riboseq is ribosome profiling). Clean on specificity. Risk is entirely sustainability: solo author, self-described new to Nextflow, starting from bash/Python scripts. nf-core's main failure mode for niche pipelines is abandonment. Not a reject on merit; needs a team + realistic scope conversation before approval. ❔ #144 cfmultiomics — https://github.com/nf-core/proposals/issues/144 Novel parts are real: fragmentomics isn't anywhere in nf-core, and cross-omics integration (genomics+methylomics+fragmentomics in one run) is the stated point. But the author concedes genomics≈sarek and methylomics≈methylseq, so it's largely an orchestration wrapper over two existing pipelines plus one novel module — the mega-pipeline shape nf-core resists. Unanswered question (jfy133 raised it): is fragmentomics a module/subworkflow added to methylseq/sarek rather than a new pipeline? Needs "what does integration actually compute" answered before a call.

Except for dragen and hapmal, where it was quite clear for me, I don't have enough background to judge.

Yeah, the general issue I have is that I have no real idea on many of them

Sure, but in most cases you can check keywords against existing pipelines and often compare the tools being proposed against similarish pipeliens

Also looking for the main devs on relevant pipelines and asking them to review, directly pinging them on GitHub and also in the slack channel

I usually check any tools they suggested; if they are already nf-cored -> if they are used in existing nf-core pipelines -> check the overlap -> decide yes, no, or add to existing pipeline I've been pretty busy these couple of weeks, but I would like to go through these today/tomorrow..in my tasks list

If only we had a technology that could do things the humans don't want to do 😉 https://gist.github.com/pinin4fjords/845bc0fc20127f18409c0fc5c31ee0b2 Seriously, since we're clearly rubbish at this, could we have an initial AI assessment?

just make a skill and we can share among us

I did- in the link 🙂

HAHAHAHAHA

I actually feel the opposite way. I think having an AI do this formally is a terrible idea. It's generally overly-verbose, doesn't understand nuance, and still has to be verified by a human.

too fishy, didnt click

Meh, I think it'll put people off. If the first thing that someone gets is a wall of inpersonal text 'review' a lot of people will go OK they don't care and leave

Somewhere invisible to users so we have something to work from?

I wouldnt let it do on its own, especially on GiHub..but us using the skill, call help keep focus on important stuff

I'd rather get an AI response (with human follow up) than tumbleweed

if deemed too shitty by their agent

Some of the proposals themselves (and PRs/issues) have already clearly been written by or with AI and I find it an effort to get through because the prose is so clunky and obvious tbh

AI response to me is the same as tumbleweed

It's still a problem if there's an AI response and no human response afterwards

We don't want to be like every company helpdesk out there, we should be better

I'm not sure we could automate it anyway, as we don't have a central pool of LLM tokens to use

Also if the automated review is triggered by a person (eg. with a comment trigger) then it feels a lot less impersonal.

Thjis is reasonable

Example here

I think reviewing code, which has very clear right/wrong is quite different from a theoretical and potentially nebulous review of a pipeline proposal

That's fair 👍🏻

And the other way around..people can first try their own review, then Jon's skill and benchmark/compare

Sure - can also just look up to see an example of the output (that was in "batch sweep" mode that did all proposals, not just one)

(actually that was an earlier version, I improved it after that 🙂 )

Could we also put some of this back onto the proposer? Yes we would still have to verify, but if they want to have a pipeline accepted perhaps the least they should be willing to do is list any existing modules they will be using in a clean list?

But.. why? When AI can do it for us basically for free, why reject that ability and instead request newcomers to jump through hoops for us?

Question. Does it need to use Claude? Can a local model be used in a GH runner instead? I have some good success with some of the higher parameter models locally, but I've not tried like a 4b model in a GH Action. Maybe it's feasible.

Different attitudes here I guess haha. I see it as the burden should be on the proposer to meet standards and furnish the necessary information, and that barrier to entry should be high. I think others see it that the process should be as easy as possible to get started and the shortfall can be made up by AI?

I think that we have more pipeline proposals than ever, use of AI and ever-expanding community size is increasing review burden across the board for all. I think that we should embrace all tools we can to help us cope with this, whilst staying true to our core values: high quality and sense of community.

Actually, maybe not a local module but this nf-core module could be use for this 👉🏻 https://github.com/nf-core/modules/tree/master/modules/nf-core/llamacpppython/run

hah, use AWS megatests. Actually not a terrible idea, I wonder if we can use our credits for bedrock 🤔

I'm ok with that. Will the response be in a thread?

Yup

Hm, should we maybe post this first review in the maintainers visible channel only instead of the public one? The VERDICT reads pretty harsh "solo maintainer", "self-proclaimed Nextflow beginner"

I guess we could for this very first one, but the automation is based around the messages that show up in #CE6SDEDAA so I don't think it's possible going forward for new proposals.

Hm, should we maybe post this first review in the maintainers visible channel only instead of the public one? The VERDICT reads pretty harsh "solo maintainer", "self-proclaimed Nextflow beginner"

Eh, I don't think that is harsh when that is what they say in the post 🤷

@Simon Pearce , I know what you mean, but “to the point” can be interpreted as harsh by some people. Talking from experience here

I think it’s also the double-whammy indignity of it coming from a robot too

Especially when "quoted" xD

Niche, solo-authored pipelines are nf-core’s main abandonment failure mode.

However I do think this point is highly accurate (for all open-source science to be frank) and I did consider saying it would be good if he could find someone in the community to help him with the development in my response, so the critique is not invalid.

Made a start on some edits this morning before getting pulled into other things: https://github.com/nf-core/slackbot/pull/17

It even takes into account comments, nice. I /approved though because I liked it

What’s going on with the embedded markdown at the bottom? How does that look rendered on GitHub?

It came from Jon's skill. I think the idea is that you can copy + paste into the GitHub issue and customise, to save you paraphrasing all of the report it generated above