RFC 1: clarify RFC lifecycle

Author: birkenfeld

rfcs/RFC-001-RFC-process.rst

@@ -3,7 +3,7 @@
 - Submit Date: 2023-11-13
 - Authors: Alexander Zaft <[email protected]>, Enrico Faulhaber
   <[email protected]>, Georg Brandl <[email protected]>
-- Type: Meta/Protocol
+- Type: Meta
 
 Summary
 =======
@@ -22,28 +22,64 @@ the Rust and Python communities.  It is intended to be lightweight, but still
 provide a frame to handle suggestions in a structured manner.
 
 
-The Process
-===========
+Lifecycle of an RFC
+===================
 
-Here we will lay out the steps to follow to change the specification.
+1. An RFC starts as a pull request against the SECoP GitHub repository.
+
+2. First discussion happens in the form of comments on that pull request, and/or
+   in committee meetings.
+
+   It is encouraged to start adding the new feature to SECoP implementations to
+   collect real-life experience and uncover unexpected problems.
+
+3. As soon as it is agreed that the idea has merit and a chance to be accepted,
+   it gets assigned an RFC number and the pull request is merged.
+
+4. The RFC stays in state "Open" and can be further discussed.  Real-life test
+   implementation continues.
+
+   It is encouraged to start early on updating the specification to include
+   changes from the RFC.  The link to the pull request is added to the "PR"
+   header.
+
+5. When the committee feels the RFC is in a satisfactory state, it moves the RFC
+   to the "Accepted" state.  At this point, the pull request to the
+   specification must be done.  This starts a finalization period of usually a
+   month.
+
+6. If no further objections are noted during this period, the RFC is moved to
+   the "Final" state, otherwise back to "Open".
+
+7. Alternately, if the committee at any point feels the RFC is not viable, it is
+   moved to the "Rejected" state.
+
+
+How to contribute
+=================
+
+Here we lay out the steps to follow to change the specification.
 
 - If you do not have a concrete idea, come talk to us to flesh it out.
 - Copy the RFC-000-template.rst file and fill in the details. You can add
   sections freely, but try to fill out all the provided ones.
-- Take the next free number and add it to the template file.
+- Take the next free number and add it to the template file.  Renumbering might
+  happen when the PR is merged.
 - The RFC gets discussed - this should mostly happen under the RFC pull request.
   If not, please add a summary if possible.  Optimally, an implementation will
   already be done at this stage in one or more of the SECoP implementations in
   order to uncover possible problems.
+- If the proposal is sound enough and has general approval, the RFC PR is merged.
+  Further discussion can and should of course happen.
 - There may be irreconcilable problems with the RFC. In that case, the committee
   can decide to reject the RFC, and it may not be reopened.  If there are new
   developments, or a new approach, a new RFC should be opened.
 - If the RFC is in a satisfactory state, any of the SECoP committee members can
   propose to move to the finalization period.  This is a limited time of one
   month.  The RFC is broadcast on the appropriate channels to notify people of
   the last chance to comment.  If there are blocking issues uncovered in this
-  period, it moves back to being under development.  If no major issues come up
-  during the month, the RFC is accepted.
+  period, it moves back to Open.  If no major issues come up during the month,
+  the RFC is made Final.
 
 
 If you never used GitHub/Need Help