New RFC: New nf-core RFC system for major initiatives

[ewels]

Note

This is the first ever nf-core RFC and a bit of a special case. This issue comes after discussion with the @nf-core/core and some initial drafting work in Google Docs. I have copied out relevant chunks of what we have written into this issue and will port over the rest of the details into a PR once the issue is approved - as per the new proposed RFC procedure!

Summary

The nf-core ‘Request for Comment’ (RFC) process is designed to give the community a voice and visibility to large projects that affect the entire community.

RFC (Request for Comment):

A formal proposal submitted for discussion, typically involving significant changes or new features. An RFC outlines the motivation, requirements, and steps necessary for implementation, and invites feedback and collaboration from the community before a final decision is made.

Proposal champion:

An individual who takes ownership of advancing a proposal through the RFC process. This role is self-nominated and open to anyone, including both project maintainers and other community members. The champion may be the original author of the proposal or someone who joins later. Responsibilities include drafting the detailed RFC, managing and integrating community feedback, and helping to guide the implementation of the proposal.

Champion

@ewels

Background & Motivation

Until now, major nf-core projects have been discussed and agreed upon by the @nf-core/core team, sometimes reaching out to @nf-core/maintainers and other groups as necessary. Once approved, work proceeds and in some cases those who are affected in the community only find out about projects once the changes go live.

We want to improve visibility and transparency around such projects so that community members are aware of potential upcoming projects and have the ability to comment, contribute and shape them before they come into effect.

Not every project in nf-core requires an RFC. The process should only be used for efforts that will affect a significant proportion of community members. For example:

• Changes to established development / code standardisation
• Creation of new nf-core fundamental product / initiative
• Changes to base dependencies and requirements that span many pipelines

To help give a better idea of the scale that a request should reach to require an RFC, here are a few real-life examples (from before we had an RFC procedure):

• We would like to add a new ‘product’ offered by and for the community in the form of standardised analysis notebooks for routine post-pipeline analyses that require more user experimentation. This would require new subcommands of nf-core/tools, a new template, new repositories, and a new section on the top bar of the nf-core website.
• I would like to propose a new subcommand to the nf-core tools package, called nf-core testdatasets. The purpose of this subcommand is to make it easier for developers to search through the very large and convoluted nf-core/test-datasets repository for suitable test-data files to promote reuse of existing data files.
• There is a deficiency within the nf-core/modules specifications regarding standardised use of the ext.args variable. The use of the naming scheme args, args2, args3 are not intuitive for developers to know which arg goes to which command in the module. We propose to update the specifications to use the command/subcommand as a suffix instead e.g., args_samtoolssort. This would require a change to every module in the repository and improved documentation support.

As a rule of thumb, if a proposal will require changes across two or more different repositories, it is a good candidate for an RFC. Projects that are smaller in scope should typically be raised as a new issue on the relevant GitHub repository instead.

Goals

• Improve visibility of upcoming nf-core projects that affect much of the community
• Provide venue for open feedback and discussion before implementation of projects

Non-Goals

• Excess bureaucracy where it is not warranted
• Increased barriers for contribution

References

• Slack discussion (core-team channel)
• Prototype: Google docs (will post in a PR shortly once approved here)

[maxulysse]

I approve this proposal

[maxulysse]

/approve

[jfy133]

/approve

[sateeshperi]

/approve

[lescai]

I definitely /approve and commend this initiative! :)

[mirpedrol]

/approve

[JoseEspinosa]

/approve

[ewels]

Bump - new comment here should trigger new automation: #33

Let's see what it does 😬

[nvnieuwk]

/approve