---
title: nf-core retreat 2022
tags: meetings,core,agenda,retreat
---


> _Stockholm, September 2022_

::: info
:writing_hand: **Please add anything here that we should discuss!**

Even if it's just a heading (`## Something`) it's good to have a placeholder.
:::

::: success
:bulb: **Feel free to edit / add thoughts to anything that's already here.**

For smaller things, you can add comments on the right / in "View mode".
:::

**Table of contents**
[TOC]

# Misc Action Points

- [ ] Look into disabling permissions to fork
- [x] Protect `module` branch on test-datasets
- [ ] Investigate separate modules test-data from pipeline test-dataset?
- [x] Set up Forem
- Has been moved to a Seqera ticket for Developer Advocates to follow up. No github issue.

# ✅ Restructuring Teams / nf-core organisation

## Action points

- [ ] Make / check email forwarders (https://github.com/nf-core/nf-co.re/issues/1248)

## Examples of other projects

- [scverse](https://scverse.org/people/)

## Suggested team structure

flowchart BT
    core --> steering
    infrastructure --> core
    outreach --> core
    ambassadors --> outreach
    maintainers --> core
    safety --> steering

### Steering

Reword: "Additional responsibilities to ensure the smooth running of the project"

- Members
- Phil
- Gisela
- Harshil
- Ellen
- Evan
- Tasks
- Finance
- Personnel
- Large initiatives
- Big picture planning

### Core

- Members:
- @apeltzer: Alexander Peltzer
- @christopher-hakkaart: Chris Hakkaart
- @drpatelh: Harshil Patel
- @ewels: Phil Ewels
- @FriederikeHanssen: Friederike Hanssen
- @ggabernet: Gisela Gabernet
- @jfy133: James A. Fellows Yates
- @JoseEspinosa: Jose Espinosa-Carrasco
- @mashehu: Matthias Hörtenhuber
- @maxulysse: Maxime U. Garcia
- @mirpedrol: Júlia Mir Pedrol
- @mribeirodantas: Marcel Ribeiro-Dantas
- The core team will be responsible for:
- Day to day decisions for community.
- Decisions by committee / vote
- If there is no majority, decisions will be made by the steering committee
- Administrative access to everything
- To meet annually (before the first hackathon of each year)
- To track & decide on new pipeline requests
- Membership
- By invitation, based on merit / involvement in the community
- Representation
- Will aim to have representation that from different genders, geography, and academia + industry + clinical.

### Infrastructure

- Responsibilities
- Framework development (tools, website, megatests..)
- Members:
- Lead: Phil
- Julia
- Matthias H
- ..Fabien?

### Outreach

- Members:
- Leads
- Chris
- Marcel
- Fran
- Phil
- Maxime
- Yuk Kei
- Edmund
- Paul Cantalupo
- Abhinav
- Many current members should be ambassadors
- Responsibilities
- Bytesize
- Hackathons/Training
- Ambassador program
- Twitter by leads (bytesize,...)
- Youtube

### Safety

- Members:
- Saba Nafees
- Michael Heuer
- Cris Tuñí
- Write proper remit / responsibilities
- Term / meetings / governence etc
- Responsibilities
- Keep CoC up to date
- Available at events
- Slack conduct
- Being quick to respond
- Give recommendations to steering committee

### Maintainers

- Current situation: Big group, write access to all repos
- Members:
- [x] Harshil (core)
- [x] Maxime (core)
- [x] Rike (core)
- [x] James (core)
- [x] Gisela (core)
- [x] Alex Peltzer (core)
- [x] Matthias Hörtenhuber (core)
- [ ] Matthias de Smet
- [ ] Edmund Miller?
- [ ] Gregor Sturm
- [ ] Mahesh
- [ ] Rob Syme
- [ ] Moritz
- [ ] Daniel Lundin?
- [ ] Louisa Perelo
- [ ] Anders Jemt
- [ ] Jasmin
- [ ] Nicolas Vannieuwkerke
- [ ] Christopher Mohr?
- [ ] Adam Talbot
- [ ] Simon Thios
- [ ] Matthieu Muffato
- [ ] Daniel Straub?
- [ ] Sabrina Krakau?
- [ ] Anders Sune Pedersen?
- [ ] Simon Pearce?
- Remove write access from `@nf-core/all`
- People fork pipeline/bioconda to nf-core
- Need to figure out how to maintain the list of maintainers
- Top list of GitHub contributors from nf-core
- Top 50 in the past year
- Manual added by us; rotate every 6 months to people who don't volunteer etc.
- People request
- Responsibilities
- Review PRs
- Review release PRs (including first release)
- Module reviews
- Make sure the right people have access to the right repos (core)
- check #github-invitations
- Manage test data
- Repo access:
- nf-core members: ?
- nf-core/all write access to
- modules
- configs
- nf-core/maintainers: write access to all repos
- nf-core/core: admin access

### Ambassadors

:point_right: **Suggestion:** Trim down the outreach team to a much smaller number of active members. Move others who are keen but not engaged in organisation into a new _Ambassadors_ group and encourage them to do their own local outreach.

- Lead: outreach team
- Nextflow _and_ nf-core
- Name: _Nextflow Ambassadors_
- Report to Outreach team
- List on the nf-core website
- Tasks
- Write blog posts
- Personal / Medium / Main nf-core / Nextflow
- "Towards Data Science": Medium (Suggested by @mribeirodantas)
- Local events
- Talks (conferences)
- Training
- Manage list
- Apply on website? Slack?
- Recommended (mentorships?)
- Onboarding
- New ambassadors get an ambassador mentor
- Minimum 2 contributions per year
- Post on Forem-like platform
- Look into adding Tweets to Forem?
- Twitter HashTag `#NextflowAmbassador`
- Could be about a
- Training event
- Poster/Talk
- Deactivate if no longer active (6 months?)
- Frequency
- Meeting once every six months
- On / off activity is fine.
- Would require a 'ambassador' packet:
- Training material
- Templates (posters, slides, etc.)
- Stickers welcome pack
- Swag box after a year if did stuff
- Managed by outreach team
- Shared slack channel, no mailing list, no team e-mail
- Sign a CLA

# ✅ Governance

## Action points

- [ ] Write the teams for the website (https://github.com/nf-core/nf-co.re/issues/1249)
- [ ] Write governance (https://github.com/nf-core/nf-co.re/issues/1254)

## Reading:

- [Meritocratic Governance Model](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
- [Benevolent Dictator Governance Model](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
- [How To Draw Up A Governance Document](http://oss-watch.ac.uk/resources/governancemodels#how-to-draw-up-a-governance-document)
- scverse [teams](https://scverse.org/people/) and [roles](https://scverse.org/about/roles/)

# ✅ Guidelines

Review the nf-core guidelines.

## Action points

- [ ] Rewrite guidelines page, use ToC list with detailed paragraph for each item.
- [x] test-datasets guidelines https://github.com/nf-core/nf-co.re/pull/1253

## Possible additions

### Pipelines

- Primary development must be on the nf-core fork
- Must have the nf-core fork set as the head repo
- When forking to your org / user, issues + wiki + projects should be disabled
- All documentation must be on the nf-core repository and include at least `docs/usage.md`, `README.md` and `docs/output.md`
- Other markdown docs files in the repo are ok (soon)
- There should not docs hosted in any other locations (eg. readthedocs)
- Software/containers in the pipeline must be versioned
- ideally released, otherwise at least a git commit hash; no `latest`,`dev` etc
- `-profile test`
- It must exist and work
- It should be comprehensive as possible
- It should run as much of the pipeline as possible
- It can use tiny test data
- [ ] Add a lint test to check that `-profile test` exists (https://github.com/nf-core/tools/issues/1837)
- Bundled scripts
- Pipelines must not include scripts that were not written specifically for the pipeline
- Instead, if absolutely required, package on bioconda and pull in the container
- DOIs: Stick with Zenodo
- :point_right: Continue discussion here: https://github.com/nf-core/tools/issues/365
- [ ] Automate DOI creation for new pipelines
- [ ] [GitHub actions](https://github.com/ivotron/zenodo/)
- [ ] New lint test - check DOI exists
- [ ] Pre-reserve DOIs?
- [ ] Check if CFF file has messed up Zenodo
- DOIs for modules?
- No
- Move cloud usage to a must instead of should?
- Sounds difficult for some pipelines
- No

## Possible removals / changes

- A responsible contact person / GitHub username

## Enforcement

We have no official policy of what we will do if people don't follow these rules. It would be good to walk through this.

- Don't join nf-core in the first place
- Welcome to use tools and collaborate
- Proper citation: Don't call nf-core/pipeline and say "uses" rather than "is"
- Generate pipeline template without the nf-core branding
- Not listed on the nf-core website, but can add to awesome-nextflow
- What to do if guideline violation after adding
- Resolve with the core team through discussion
- Reserve the right to remove the pipeline from the nf-core website (or archive)
- The nf-core community / core team "owns" the repo
- Core team makes recommendations to Steering Committe, who get the final say
- Point to code of conduct

# Configs

James and Maxime to discuss - new checklists / recommendations for reviewing.

# ✅ Test data

- New requirement: YAML file in each test data directory
- Structured metadata about those files (e.g. yaml)
- Origin
- Tools (list)
- Biological sources (list)
- DOI / accession
- Licence
- Need policies on being compatible with MIT
- Marcel to investigate
- New guidelines for adding test data
- As small as possible
- Use what's there if possible
- Small genome size
- SARS-CoV2
- Human Chr 21
- Prokaryotes
- bacteroides_fragilis
- candidatus_portiera_aleyrodidarum
- haemophilus_influenzae
- If it can be _quickly_ generated by an upstream module, don't add it
- If many tests, or many steps, or heavy cpu, store the static data
- Can test a module together with a previous step module. That's ok :+1:
- Updates: In a new folder, don't modify in place
- Can we reverse map test data :point_right: modules?
- If so, we can test all affected modules when updating test data
- Don't need to keep multiple similar copies of test data :+1: https://github.com/nf-core/test-datasets/issues/626
- :point_right: Move modules to a new repo
- nf-core/modules-test-data https://github.com/nf-core/test-datasets/issues/625
- Future idea: possibility of using Refgenie for handling all test data as well

# ✅ Archiving Policies

We've never really had a formalised method for that, it'd be good to have one

## Ideas

- How to reduce risk of abandoned pipelines in the first place
- Publish then stop maintaining
- Not nice to have lots of unresolved issues/bugs
- What is the criteria to archive a pipeline?
- Time since last commit?
- Lack of issue response
- Response on slack? (i.e. lots of pipeline channels have been completely silent since last hackathon)
- How to bring an archived pipeline out of retirement if interest renewed

## Policies

- What does archived mean
- No further updates
- Users should move away to other solutions
- Manual process
- Pipelines page: Sort by activity
- Last release
- Last commit on dev
- Check manually:
- Other branches beyond dev with activity
- Slack
- Issues
- If core team decides to archive
- Try to chase down maintainers to ask (Slack, twitter, GitHub, email...)
- If no response within a month, or they agree, archive
- Archive procedure
- Archive the repo on GitHub
- Make a note on the readme for justification
- Mention if we can un-archive
- Can un-archive in the future if someone wants to resume development
- Frequency:
- Item on the new nf-core core team spring cleaning list (annual)

# ✅ Spring Cleaning Month
- Lead: James & Chris
- Yearly: March, near hackathon dates
- Everyone, not just core
- Reminders on Slack
- Clean up:
- Non-active pipelines
- Old branches
- Old pull requests
- Old issues (duplicates, already fixed)
- [ ] Establish spring clean (https://github.com/nf-core/tools/issues/1832)

# ✅ Reviewing content

- How do we scale the community when it comes to code review
- Need to keep high standards
- Need to be able to keep up
- How we split the reviewing workload amongst the community to be fair but timely at the same time.
- Bot to post a reviewer checklist?
- Include logic based on the PR
- Is it to `master`
- Look at files that have been modified etc.
- Comment if linting fails, add a reaction to run bot
- Allow linting bot with PRs coming from forks in the modules repo? It is possible 🥳

## Decisions
- Maintainers team will be responsible for initial release PRs
- Maintainers team can organise modules PR reviews
- [ ] Write documentation / guidelines for reviewing (https://github.com/nf-core/nf-co.re/issues/1250)
- Pipelines
- Modules
- (Subworkflows)
- Configs

# ✅ Publications and acknowledgements

## Actions

- [ ] Write authorship guidelines https://github.com/nf-core/nf-co.re/issues/1255

## Points

- Publications currently acknowledge only main authors of pipeline, but not nf-core community. What about adding "nf-core community" to the list of co-authors. Who should be listed there? Active contributors?:
- Who should be in there:
- Anyone who has made a commit in tools, website, respective pipeline, used modules, ?
- Example: bioconda publication https://www.nature.com/articles/s41592-018-0046-7

:point_right: write some docs
- Having increasingly more people asking for ways to somehow include grant/acknowledge statements of their work for modules, should we have explicit guidelines for this at both pipeline and/module level?
- [ ] Include grant/acknowledge statements https://github.com/nf-core/modules/pull/1833

# ✅ Hackathons and events

- Should people helping out in the events pay for it?
- Lots of people would be part of core/outreach/safety etc; can't afford hackathons without seqera support if they get a waiver
- Case-by-case basis
- This is clearly controversial 🚨, so in the future just make it free so that Maxime is happy.
- Sponsorships if money an issue (Seqera, AWS)

# ✅ Development

- Subworkflows
- [ ] black for pipelines - yes. Need to add this.
- pytest for pipelines?
- Change the confusing `check_max()` function:
- Yes, very annoying
- RENAME+UPDATE because the function copied over and used in the custom config files is there already, so we can have a new one
- Deprecate slowly the params
- `check_max()` :point_right: `dont_use_more_resources_than_this()`
- `$cpus_ceiling = { $params.max_cpus }`
- Linking pipelines
- Automatic dependencies list (to put in CHANGELOG with new/removed...)
- Global params list:
- Standardise param names, e.g `--bwa_index`, `--bwa`
- Scrape all JSON schema files and build a big list (link to it in the writing pipelines tutorial)
- Should also include global samplesheet headers
- [ ] Create param ontology https://github.com/nf-core/nf-co.re/issues/1251

# ✅ Non nf-core pipelines

Should we somehow feature pipeline using the template and linting that are not part of nf-core?

- List of nf-core approved pipelines on website
- Nextflow website (awesome-pipelines)
- Have a tag for using the nf-core template
- Link there from the nf-core webpage (nf-co.re/pipelines)

- :point_right: Seqera will take care of this
- No ticket for this but Seqera will keep everyone updated because there will be overlap.
- Good examples:
- pgsc_calc
- bactopia

# ✅ Pipeline docs

Some people want to have fully featured docs sites for their pipelines, not just usage and output.

- Sticky tab bar for pipeline page
- Reduce Usage + Output :point_right: Docs
- Under Docs, have new left sidebar
- Auto-detect markdown files (nested), e.g. FAQ, tutorials
- Use front-matter for priority etc. (see nf-co.re/docs)
- Keep template docs as barebones as possible (move to main nf-core docs)
- [ ] Create new subsections for pipeline documentation (https://github.com/nf-core/nf-co.re/issues/1252)

# :desktop_computer: Issue list
- Spring Cleaning Month: https://github.com/nf-core/tools/issues/1832
- Make / check email forwarders: https://github.com/nf-core/nf-co.re/issues/1248
- Write the teams for the website: https://github.com/nf-core/nf-co.re/issues/1249
- Write guidelines document @ewels
- Rewrite guidelines page, use ToC list with detailed paragraph for each item.
- Fix Zenodo: https://github.com/nf-core/tools/issues/365
- Create param ontology: https://github.com/nf-core/nf-co.re/issues/1251
- Create new subsections for pipeline documentation: https://github.com/nf-core/nf-co.re/issues/1252
- Include grant/acknowledge statements: https://github.com/nf-core/modules/pull/1833
- Write governance document: https://github.com/nf-core/nf-co.re/issues/1254
- Write authorship guidelines https://github.com/nf-core/nf-co.re/issues/1255
- Re-run tests of all affected modules when a given test-data file is updated/modified: https://github.com/nf-core/test-datasets/issues/626
- Move modules to a new repo nf-core/modules-test-data: https://github.com/nf-core/test-datasets/issues/625
- Add a lint test to check that `-profile test` exists (https://github.com/nf-core/tools/issues/1837)