/
RFC Process

RFC Process

Owned by Radhakrishnan Gopalakrishnan
Last updated: May 01, 2025 by Joshua Greben

Process Overview

The RFC process is comprised of several stages which happen in sequence.  The purpose, steps, and advancement criteria for each stage is detailed below.

ABSTRACT PREPARATION  

Purpose:  The submitter prepares the RFC abstract and brings it to the attention of the Technical Council.

Timebox:  Approximately 16-17 weeks when incorporating review windows and accounting for administrative overhead, making adjustments, etc.

Steps:

  1. The submitter copies the RFC Template page and saves it to the RFC Log. (This can be done by clicking the “…” on the upper right of the page [i.e. “More actions“] selecting Copy, and under Parent type in “RFC Log.”)

  2. The submitter populates each of the template sections as described on the template.

  3. The submitter should contact one of the Technical Council chairs to let them know that a new RFC was created, and plan to attend a TC meeting in the near future to present the RFC Abstract.

Advancement Criteria:

  • A page exists in the RFC Log with all of the applicable sections filled out.

  • The submitter has contacted a Technical Council chair and has scheduled a TC meeting in which the RFC Abstract will be presented and discussed.

NOTE:  If applicable, abstracts for closely related RFCs should be presented together at The Technical Council.  This would give The Technical Council insight into how a larger topic is being split up into smaller more digestible, related RFCs.  It will provide an opportunity to discuss the expected timing and sequence of RFC submissions.

PRELIMINARY REVIEW

Purpose:  Discuss and agree to the scope and general direction of the RFC.  The intent is to have a conversation between The Technical Council and the submitter, adjusting the RFC direction and scope as needed, prior to investing time in writing the full RFC.

Timebox:  ~ 2 weeks

Steps:

  1. The PRELIMINARY REVIEW stage begins once the submitter presents an RFC Abstract at a Technical Council meeting. 

    1. The presentation should be brief (~5 minutes max) and focus solely on the general direction and scope. 

    2. It's the responsibility of the meeting convener to ensure the presentation and subsequent discussion remains on topic and doesn't delve into details.

  2. One week will be given for TC members to consider the scope and general direction

    1. During this time, TC members are encouraged to provide feedback/questions relating to the scope/general direction of the RFC in the RFC Log.

    2. There shouldn't be feedback on details of the RFC at this stage.

  3. If necessary, the submitter may organize ad-hoc meetings/conversations to resolve any issues/concerns raised.

  4. At The Technical Council meeting following the RFC Abstract presentation, The Technical Council will vote in a timely manner on whether there is any merit to the RFC.

    1. If the submitter requires more time to make necessary adjustments, they should inform a Technical Council chair, and The Technical Council vote will be rescheduled.

  5. If approved, the submitter or a TC Council member will change the status in the page header to “closed.” The status will be updated by a TC member during the process to reflect the current status.

  6. Rejection is unlikely at this stage unless The Technical Council and submitter reach an impasse.  

    1. If rejected, the RFC status is updated to indicate this (status: Rejected).  Some conversations may remain unresolved in this case.

Advancement Criteria:

  • The RFC is presented at a TC meeting.

  • The Technical Council has voted to proceed.

RFC PREPARATION

Purpose:  Submitter and other contributors flesh out the rest of the RFC and notifies the Technical Council when it's ready for public review.  Submitters are encouraged to reach out to the TC and/or other community stakeholders during this stage as needed to get feedback on certain aspects of the RFC which may be controversial or confusing.

Timebox:  ~ 1 month may be a good starting point, but if deviating significantly from the timeline indicated in the RFC Abstract, The Technical Council should be notified.

Steps:

  1. The submitter works on the content of the RFC, staying true to the general direction and agreed upon scope.

  2. The submitter contacts one of the Technical Council chairs when the RFC is ready for PUBLIC REVIEW.

  3. The submitter or a TC member updates the RFC Log page status to PUBLIC REVIEW.

Advancement Criteria:

  • The submitter has contacted a Technical Council chair indicating that the RFC is ready for PUBLIC REVIEW.

  • Status is updated to PUBLIC REVIEW stage.

PUBLIC REVIEW

Purpose: Gather feedback from and discuss with any/all FOLIO community members

Timebox:  ~ 1 month may be a good starting point. TODO: think about the periodic reminders indicating how much time remains in the feedback window.

Steps:

  1. The RFC Log page has been updated to reflect the status: PUBLIC REVIEW.

  2. A message is sent to the public #tc-rfc slack channel announcing the PUBLIC REVIEW stage of the RFC.

  3. The Technical Council and submitter determine if additional announcements should be made in other channels (e.g. #sys-ops, #folio-product-council, #development, etc.)

  4. RFC is opened up for a community-wide review. Anyone who wants to provide feedback can participate.

  5. Feedback is provided as comments on the RFC Log page.

  6. All questions/concerns/suggestions provided as part of the public review feedback will be addressed. The submitter of the RFC will take the responsibility of facilitating discussions to address the comments provided.

  7. There will be a bias towards not changing the scope of the RFC at this stage as it would likely be disruptive. 

  8. The community should really take this opportunity to weigh in on the changes.

  9. POCs/Reference implementations are developed to identify any gaps or unforeseen challenges (Optional).

  10. The submitter and Technical Council are in contact throughout this stage and together determine when the public review stage should conclude.

  11. A message is sent to the public #tc-rfc slack channel announcing the PUBLIC REVIEW stage of the RFC has concluded.

  12. The submitter or a TC member updates the RFC Log page to reflect the FINAL REVIEW status to advance the RFC to the next stage after ensuring that all public feedback has been addressed.

Advancement Criteria:

  • All public feedback has been addressed.

  • The RFC Log page is updated to status: FINAL REVIEW

  • The Technical Council and submitter have together agreed that the RFC is ready for final review.

FINAL REVIEW

Purpose: Final review and discussion by Technical Council, leading to a decision.

Timebox:  This may not be needed. This stage seems to move quickly. If consistency is desired, a short duration (e.g., 1 week) could be chosen.

Steps:

  1. The Technical Council will review and deliberate over the comments from the community.

  2. The Technical Council does the final review and votes on whether the RFC should be Accepted or Rejected.

  3. A message is sent to the public #tc-rfc slack channel announcing the outcome of the RFC.

  4. The Technical Council should really work towards getting a consensus on this final vote or at least have an overwhelming majority in favor of the RFC.

  5. The RFC Log page is updated to one of the statuses: ACCEPTED or REJECTED.

Advancement Criteria:

  • The Technical Council has decided to Accept or Reject the RFC.

  • The RFC Log page has been updated to indicate the outcome.

  • An announcement has been made in the #tc-rfc slack channel indicating the outcome of the RFC.

POST REVIEW

  • To help us learn, a retrospective will be performed regardless of the outcome of the RFC.  

  • N.B. A formal decision should be logged in the Technical Council's Decision Log.  This is one of the primary deliverables of this process and should not be overlooked.  

    • If needed, the Technical Council can help the submitter with this.

    • Adding a list of keywords to the bottom of the DR would make it easier to find information via search.

General Guidelines

  • Dedicated time slot for RFC review (Once every 2 weeks, as needed)

  • When submitting new RFCs, it is highly recommended to have a smaller scope. In case of a large scale change, consider breaking up the RFCs into smaller RFCs. This greatly helps the RFC get through the review process quickly.

  • When there are exceptional cases that results in a stalemate (when there is no clear path even after extension period for a given review phase), The Technical Council will force a vote to decide on the fate of RFC. TC could negotiate with the stakeholders and strike compromise to keep the RFC moving forward or it could end up rejecting the RFC citing an appropriate reason

  • Feedback from anyone interested MUST be taken into consideration by the submitter at any stage during the review process as long as it is appropriately documented along the way.

  • RFCs should be technically focused.  However, RFC feedback is not limited to technical questions and concerns.  It is both expected and acceptable for non-technical aspects to be raised and discussed throughout the RFC process.

Resources