The aim of nf-core is to have standardised best-practice pipelines. To ensure this standardisation, we maintain a set of guidelines which all nf-core pipelines must adhere to.
The following lists an overview of the guidelines. Follow links to dedicated pages for more details about a given topic.
Ask the community
The instructions below are subject to interpretation and specific scenarios.
If in doubt, please ask the community for feedback on the
#new-pipelines Slack channel.
You can join the nf-core Slack here.
All nf-core pipelines must follow the following guidelines:
- Nextflow: Workflows must be built using Nextflow.
- Identity and branding: Primary development must on the nf-core organisation.
- Workflow specificity: There should only be a single pipeline per data / analysis type.
- Workflow size: Not too big, not too small.
- Workflow name: Names should be lower case and without punctuation.
- Use the template: All nf-core pipelines must be built using the nf-core template.
- Software license: Pipelines must open source, released with the MIT license.
- Bundled documentation: Pipeline documentation must be hosted on the nf-core website.
- Docker support: Software must be bundled using Docker and versioned.
- Continuous integration testing: Pipelines must run CI tests.
- Semantic versioning: Pipelines must use stable release tags.
- Standardised parameters: Strive to have standardised usage.
- Single command: Pipelines should run in a single command.
- Keywords: Excellent documentation and GitHub repository keywords.
- Pass lint tests: The pipeline must not have any failures in the
- Credits and Acknowledgements: Pipelines must properly acknowledge prior work.
- Minimum inputs: Pipelines should be able to run with as little input as possible.
- Use nf-core git branches: Use
All nf-core pipelines should follow the following guidelines, if possible / appropriate:
- Use Bioconda: Package software using bioconda and biocontainers.
- File formats: Use community accepted modern file formats such as
- DOIs: Pipelines should have digital object identifiers (DOIs).
- Cloud compatible: Pipelines should be tested on cloud computing environments.
- Publication credit: Pipeline publications should acknowledge the nf-core community.
If the guidelines don’t fit
We appreciate that the above guidelines are relatively rigid and may not be for everyone. If that’s the case, there is still a lot of ways that you can get involved with nf-core!
We hope that the nf-core best practices, tooling and community are helpful for anyone building Nextflow pipelines, even if they are not a good fit for being listed as official nf-core pipelines. You are very welcome to use the helper tools and collaborate on modules / subworkflows / ideas. Indeed, numerous pipelines outside of nf-core now extensively use and contribute back to nf-core/modules.
If using nf-core tools and especially the template, please don’t call your pipeline
Please say that your pipeline “uses” nf-core rather than rather than “is” nf-core.
Remember that you can generate a pipeline with
nf-core create that excludes nf-core branding.
Citation and acknowledgement of the work that goes into these tools and templates is welcome.
Non nf-core pipelines can be added to nextflow-io/awesome-nextflow for added visibility.
If a pipeline is found to be violating the nf-core guidelines after it has been added to the community, we will try to address the problems via the following steps:
- First, the core team will attempt to resolve problems with the pipeline maintainers through discussion. Hopefully the pipeline can then be updated so that it adheres to the guidelines.
- If this is not possible, the core team will make a recommendation to the steering committee about what action to take. Such actions could include archiving the pipeline or removing it completely.
All members of the nf-core community must adhere to the nf-core code of conduct. The guidelines and actions within the code of conduct take precedence over the development pipelines described in this page.