diff --git a/rfcs/README.md b/rfcs/README.md
index 16b9d039a8..38473cf4b2 100644
--- a/rfcs/README.md
+++ b/rfcs/README.md
@@ -19,6 +19,29 @@ Examples of substantial changes:
 - Impactful UX changes (new required inputs to the bootstrap process)
 - Drop capabilities (sunset an existing integration with an external service due to security concerns)
 
+## RFC Process
+
+- Before submitting an RFC please discuss the proposal with the Flux community.
+  Start a discussion on GitHub and ask for feedback at the weekly dev meeting.
+  You must find a maintainer willing to sponsor the RFC.
+- Submit an RFC by opening a pull request using RFC-0000 as template.
+  The sponsor will assign the PR to itself, will label the PR with `area/RFC` and
+  will request other maintainers to begin the review process.
+- Integrate feedback by adding commits without overriding the history.
+- At least two maintainers have to approve the proposal before it can be merged.
+  Approvers must be satisfied that an appropriate level of consensus has been reached.
+- Before the merge, an RFC number is assigned by the sponsor and the PR branch must be rebased with main.
+- Once merged, the proposal may be implemented in Flux.
+  The progress could be tracked using the RFC number (used as prefix for issues and PRs).
+- After the proposal implementation is available in a release candidate or final release,
+  the RFC should be updated with the Flux version added to the "Implementation History" section.
+- During the implementation phase, the RFC could be discarded due to security or performance concerns.
+  In this case, the RFC "Implementation History" should state the rejection motives.
+  Ultimately the decision on the feasibility of a particular implementation,
+  resides with the maintainers that reviewed the code changes.
+- A new RFC could be summited with the scope of replacing an RFC rejected during implementation.
+  The new RFC must come with a solution for the rejection motives of the previous RFC.
+
 ## RFC Template
 
 ```text