I would love to get everyone's opinion regarding the qc question. Initially we discussed options that included (a) not including any QC steps to limit the scope, (b) copying taxprofilers QC routines (c) using the new

fastq_shortreads_preprocess_qc

subworkflow. Thanks for implementing option C @Vini Salazar! Having now seen how monstrous the diff is, I'm worried about adding the extra overhead. In general, I prefer to keep QC steps independent of downstream tools. In our lab at least, we are always going to be using the same preprocessed data for taxprofiler, funcprofiler, mag+binning+funcscan, flux models, etc. I don't think it makes sense to add ~200 files and the burden of documenting, updating, etc to the pipeline. I see our options as follows: 1. Document how we recommend people qc their data prior to analysis. Eg "funcprofiler should be run on QC'd data; for instance, nf-core/taxprofiler could be run with the parameter

save_analysis_ready_fastqs

to output the post-qc reads, and use those reads as input to nf-core/funcprofiler. Alternatively we provide a wrapper pipeline around the nf-core/subworkflows/fastq_shortread_preprocess_qc for running quality control on your data". I took a stab at such a workflow here. 2. We continue with the process of adding qc steps, merging @Vini Salazar’s recent pr. I would greatly prefer option 1. I know pipeline chaining is currently a pain, but I would prefer that pain to the pain of supporting all the qc logic, and having the qc output mixed up with the profiler output.