Project proposals / RFCs
The nf-core RFC (Request for Comment) process provides visibility and community input on large projects.
- Got a big idea? Post it on
#rfc-suggestionsfor quick feedback. - Create an issue on nf-core/proposals using the RFC template, explaining what you want to do.
- Once approved by the core team, open a PR on nf-core/proposals with a full RFC text as markdown, extending the issue with details on how it should be implemented.
- Start development and update the RFC PR as needed.
- Once the new feature ships, the RFC PR is merged and the markdown stored for future reference.
Glossary
- 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.
If this is your first time writing an RFC or design document, our maintainers team will guide you through this process.
Scope
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 or code standardisation
- Changes to create new nf-core fundamental products or initiatives
- Changes to base dependencies and requirements that span many pipelines
Examples of changes that require an RFC (from before the procedure existed):
- nf-core/reports
- 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.
- nf-core/tools test datasets
- 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.
- I would like to propose a new subcommand to the nf-core tools package, called
- Standardise
ext.argsnaming- There is a deficiency within the
nf-core/modulesspecifications regarding standardised use of theext.argsvariable. The use of the naming schemeargs,args2,args3are not intuitive for developers to know whicharggoes 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.
- There is a deficiency within the
As a rule of thumb, if your 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.
Stages
Stage 1: Suggestion (optional)
Provide a space for informal discussions around ideas and potential improvements. Gather early feedback and assess interest from the community, maintainers, and stakeholders.
Requirements
None. Proposals should be community-wide (not pipeline-specific) and large enough to warrant an RFC.
A suggestion is optional. You can skip to Stage 2, but this step helps gauge reactions before developing a full proposal.
Location
Post your idea in #rfc-suggestions on Slack. If there is sufficient interest, you’ll be invited to submit a formal proposal.
Stage 2: Proposal
Assess feasibility with nf-core maintainers and core team. Focus on the expected effect, not implementation details.
Requirements
None. However, an existing Slack thread suggestion (Stage 1) may help.
A proposal is more likely to be accepted if it is:
- Clearly written and considered
- Supported by evidence of community interest
- Backed by one or more proposal champion
- Aligned with goal and priorities of the nf-core project
Location
Submit your proposal as a GitHub Issue in the nf-core/proposals repository using the RFC template. You can browse previous proposals there as well.
The original author has first opportunity to champion the proposal. If they decline, others may volunteer. A proposal remains open until a champion is assigned or after 2 months of inactivity.
The core team may reject proposals that are infeasible or conflict with project goals, with explanation provided.
Voting
Proposals require 80% core team approval via comments on the issue. The core team meets monthly to discuss open RFCs. Proposal champions may be invited to present. Voting typically follows discussion but may occur independently. Significant changes after voting require re-approval.
After acceptance
Once a proposal is accepted, the champion will be invited to write a formal RFC and begin initial development.
A stale, accepted proposal may be rejected retroactively if progress is not made within a reasonable timeframe.
Stage 3: RFC and development
Goal
Collect technical feedback on implementation and collaborate with maintainers and community stakeholders during development.
Requirements
A previously accepted proposal from Stage 2 and a confirmed proposal champion to author and implement the RFC.
Location
RFCs are submitted as GitHub Pull Requests to the nf-core/proposals repository.
What to expect
Create a new RFC using the stage-3--rfc-template.md template. Copy the opening sections from the accepted proposal (they match 1:1). Complete remaining sections with technical implementation and organisation planning.
Once the Stage 3 RFC pull request is opened, the corresponding Stage 2 proposal issue should be closed with a comment linking to the new RFC.
You do not need to wait for an RFC approval before beginning development. One of the best ways to validate your RFC is to prototype. Early prototyping and parallel development alongside the RFC are strongly encouraged. The RFC is a living document and evolves based on feedback during implementation.
The RFC will only be accepted and merged once both the proposal and the accompanying implementation are ready to merge.
Request feedback on RFC updates at any point. Maintainers will provide timely feedback to avoid blocking progress.
Proposal champions are encouraged to present at nf-core #bytesize talks for additional visibility and discussion, though this is optional.
Stage 4: Ship it
Finalise and approve the RFC once implementation is ready for review and merge.
Requirements
An open RFC pull request with completed content in the markdown file, including a working implementation ready for final review.
Location
Finalised RFCs are managed as pull requests in the nf-core/proposals repository:
- The Stage 3 pull request is the central discussion location during development.
- Update RFCs with design and implementation changes as needed.
- Once complete, the RFC is merged to signify completion.
Special thanks
This RFC process is adapted from the Astro Roadmap, with customisation for nf-core’s needs. Astro’s process itself draws from Remix’s Open Development, their previous RFC process, and RFC processes from Vue, React, Rust, and Ember.