You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> 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!
@@ -52,82 +52,12 @@ As a rule of thumb, if a proposal will require changes across two or more differ
52
52
53
53
# Detailed Design
54
54
55
-
> [!NOTE]
56
-
> Intention is to move this text to `nf-core/website` for central documentation. It can then be linked to from this repository.
57
-
> Pasting into this RFC proposal for discussion before adoption.
58
-
59
-
## Stage 1: Suggestion (optional)
60
-
61
-
**Goal:** Provide a space for informal, low-barrier discussions around ideas and potential improvements to nf-core. This stage is useful for gathering early feedback and assessing community interest from the community, maintainers, and other stakeholders.
62
-
63
-
**Requirements:** None! Anyone can suggest anything. Proposals should be applicable to the whole community (not pipeline-specific) and large enough to warrant an RFC and associated discussion (not “fix a typo”).
64
-
65
-
> [!NOTE]
66
-
> A suggestion is optional - you can go straight to step 2, but the requirements here are very few so it can help to gauge initial reactions before putting work into a proposal.
67
-
68
-
**Location:** To submit an idea, fill out the form shared in the `#rfc-suggestions` channel on the nf-core Slack. A thread will be created for discussion. If there is sufficient interest, you’ll be invited to submit a formal proposal in the next stage.
69
-
70
-
## Stage 2: Proposal (the “what”)
71
-
72
-
**Goal:** Assess the feasibility of the proposed change with nf-core [maintainers](https://nf-co.re/governance#maintainers) and [core team](https://nf-co.re/governance#core-team). The focus is on the change's expected effect, **not necessarily the specifics of how it is expected to be implemented**.
73
-
74
-
**Requirements:** None! However, an existing Slack thread suggestion (Stage 1) may help.
75
-
76
-
A proposal is more likely to be accepted if they are:
77
-
78
-
- Clearly written and considered
79
-
- Supported by evidence of community interest
80
-
- Backed by one or more proposal champion
81
-
- Aligned with goal and priorities of the nf-core project
82
-
83
-
**Location:** Submit your proposal as a GitHub Issue in the [nf-core/proposals](https://github.com/nf-core/proposals) repository using the RFC template. You can browse previous proposals there as well.
84
-
85
-
The original author of the proposal will be given the first opportunity to act as its champion. If they decline, others may volunteer by commenting in the GitHub Issue. A proposal issue will remain open until a champion is assigned. After 2 months of inactivity, issues will be automatically marked stale and closed.
86
-
87
-
In some cases, the core team may explicitly reject a proposal if it is known to be infeasible or goes against the project's existing goals/mission. In the event of an explicit rejection, a core team member will comment on the proposal, explaining the reasoning for rejection.
88
-
89
-
**Voting:** Proposals can be approved by collecting approving votes from 80% of the core team. This is done by core team members leaving the appropriate comment on the issue. The core team has regular meetings, approximately every month. Open RFCs will be discussed and if deemed useful, the proposal champion may be invited to present their project to the core team. Voting will typically happen after such discussions, but may happen without this step. If an RFC proposal changes significantly after a vote is cast, it may be marked as “Outdated” by anyone in the core team or the proposal champion, requiring the vote to be cast again.
90
-
91
-
**After acceptance:** Once a proposal is accepted, the champion will be invited to write a formal RFC and begin initial development.
92
-
93
-
A stale, accepted proposal may be rejected retroactively if progress is not made within a reasonable timeframe.
55
+
Should be implemented primary as documentation in the nf-core/website repository.
56
+
Proposals themselves will need two new slack channels: `#rfc-suggestions` for informal early discussion,
57
+
and `#new-rfcs` for notification about issues submitted in the nf-core/proposals repository.
94
58
95
-
## Stage 3: RFC & Development (the “how”)
96
-
97
-
**Goal:** Collecting (technical) feedback on the implementation of the proposal. Collaborate closely with maintainers and other community stakeholders during development.
98
-
99
-
**Requirements:** A previously accepted proposal from Stage 2 and a confirmed proposal champion to author and implement the RFC.
100
-
101
-
**Location:** RFCs are submitted as GitHub Pull Requests to the nf-core/proposals repository.
102
-
103
-
-[See all in-progress RFCs](https://github.com/nf-core/proposals/pulls)
104
-
-[See all finished RFCs](https://github.com/nf-core/proposals/tree/main/proposals)
105
-
106
-
**What to Expect:** To begin, the proposal champion must create a new RFC using the `stage-3--rfc-template.md` markdown template provided in the repository. The opening sections of the RFC template should be copied directly from the accepted proposal (they match 1:1). All remaining sections should be completed by the champion to include the technical implementation and organisation planning.
107
-
108
-
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.
109
-
110
-
:::note
111
-
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.
112
-
:::
113
-
114
-
The RFC will only be accepted and merged once both the proposal and the accompanying implementation are ready to merge.
115
-
116
-
The proposal champion may request feedback on updates to their RFC at any point. Maintainers are expected to provide timely and constructive feedback to ensure that the RFC author is never blocked.
117
-
118
-
If possible and appropriate, proposal champions are encouraged to give a short-talk about the project at a nf-core `#bytesize` talk. This helps to give visibility to an RFC and provide an additional location for discourse around a project. It is not a requirement for RFC progression.
119
-
120
-
## Stage 4: Ship it! 🚢
121
-
122
-
**Goal**: Finalize and approve the RFC once development is complete and the implementation is ready to be reviewed and merged.
123
-
124
-
**Requirements**: An open RFC pull request with completed content in the markdown file, including a working implementation ready for final review.
125
-
126
-
**Location**: Finalized RFCs are managed as Pull Requests in the nf-core/proposals repository.
127
-
128
-
- The RFC Stage 3 pull request serves as the central place for discussion as development is underway.
129
-
- RFCs should be updated with changes to design and implementation details, as needed.
130
-
- Once the project is completed and implemented, the RFC is merged into the repository to signify completion.
59
+
In the case of this RFC, the rest of the detailed design is in the documentation.
60
+
In order to not duplicate efforts, please read and comment directly in https://github.com/nf-core/website/pull/3367
131
61
132
62
# Drawbacks
133
63
@@ -153,7 +83,4 @@ If possible and appropriate, proposal champions are encouraged to give a short-t
153
83
# References
154
84
155
85
- Slack discussion (core-team channel)
156
-
157
-
## Prior Art / Special Thanks
158
-
159
-
This process is taken and built on from the [Astro Roadmap](https://github.com/withastro/roadmap). This itself is an amalgamation of [Remix's Open Development process](https://remix.run/blog/open-development) and our previous [RFC process](https://github.com/withastro/roadmap/blob/78b736c28fe487ad02ec76bb038ad1087c471057/README.md), which had been based on the RFC processes of the Vue, React, Rust, and Ember projects.
0 commit comments