From 99a0c47277b0501a9d399b943286a3b9fda068be Mon Sep 17 00:00:00 2001 From: Stefan Prodan <stefan.prodan@gmail.com> Date: Tue, 30 Nov 2021 15:01:57 +0200 Subject: [PATCH] Add RFC process Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com> --- rfcs/README.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/rfcs/README.md b/rfcs/README.md index 16b9d039..e13b2984 100644 --- a/rfcs/README.md +++ b/rfcs/README.md @@ -19,6 +19,31 @@ 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 themselves, 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](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#decision-guidelines) + 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 -- GitLab