RFC Process

Owned by Radhakrishnan Gopalakrishnan
Last updated: Jul 15, 2024 by Craig McNally
6 min read

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 creates a PR in https://github.com/folio-org/rfcs but only populates the following sections:
    1. Metadata - Contributors, links to PRs, outcome, etc.
    2. Overview - An overview of what the RFC is about
    3. Scope - Defines the scope of what the RFC intends to cover/not cover
    4. Timing - Indicates a rough timeline of when the RFC might be ready
  2. The submitter updates the "RFC PRs" section of the metadata to link to the PRELIMINARY REVIEW pull request.
  3. The submitter should contact one of the Technical Council chairs and plan to attend a TC meeting in the near future to present the RFC Abstract.

Advancement Criteria:

  • A Pull request exists in https://github.com/folio-org/rfcs containing only the applicable sections.
  • RFC metadata contains a link to the RFC PR
  • 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 PR
    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 issues/concerns raised in the PR
  4. The submitter will be responsible for resolving all the conversations in the PR
  5. At The Technical Council meeting following the RFC Abstract presentation, The Technical Council will vote swiftly 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.
  6. If approved, all conversations must be resolved and the submitter closes (Do not merge!) the PR in its current state
  7. Rejection is unlikely at this stage unless The Technical Council and submitter reach an impasse.  
    1. If rejected, the RFC metadata is updated to indicate this (Outcome: Rejected) and the submitter merges the PR.  Some conversations may remain unresolved in this case.

Advancement Criteria:

  • All conversations have been marked as resolved
  • The PRELIMINARY REVIEW pull request has been closed (Not merged!)
  • 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 creates a new PR for the PUBLIC REVIEW stage
  3. The submitter updates the "RFC PRs" section of the metadata to link to the PUBLIC REVIEW pull request.
  4. The submitter contacts one of the Technical Council chairs when the RFC is ready for PUBLIC REVIEW.

Advancement Criteria:

  • A new pull request exists for the PUBLIC REVIEW stage
  • RFC metadata contains a link to the new PR
  • The submitter has contacted a Technical Council chair indicating that the RFC is ready for PUBLIC REVIEW.

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 submitter creates a new PR for the PUBLIC REVIEW stage
  2. The submitter updates the "RFC PRs" section of the metadata to link to the PUBLIC REVIEW pull request.

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

  4. The Technical Council and submitter determine if additional announcements should be made in other channels (e.g. #sys-ops, #folio-product-council, #development, etc.)
  5. RFC is opened up for a community-wide review. Anyone who wants to provide feedback can participate
  6. Feedback is provided as PR review comments 

  7. 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

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

  9. The community should really take this opportunity to weigh in on the changes
  10. POCs/Reference implementations are developed to identify any gaps or unforeseen challenges (Optional)
  11. The submitter and Technical Council are in contact throughout this stage and together determine when the public review stage should conclude
  12. A message is sent to the public #tc-rfc slack channel announcing the PUBLIC REVIEW stage of the RFC has concluded.
  13. The submitter closes (Do not merge!) the PR in its current state to advance the RFC to the next stage after ensuring that all conversations have been marked as resolved

Advancement Criteria:

  • All conversations have been marked as resolved
  • The PUBLIC REVIEW pull request has been closed
  • 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 submitter creates a new PR for the FINAL REVIEW stage
  3. The Technical Council does the final review and votes on whether the RFC should be Accepted or Rejected
  4. The FINAL REVIEW pull request is updated with appropriate outcome.
  5. A message is sent to the public #tc-rfc slack channel announcing the outcome of the RFC.
  6. 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

Advancement Criteria:

  • The Technical Council has decided to Accept or Reject the RFC
  • The RFC metadata has been updated to indicate the outcome
  • An announcement has been made in the #tc-rfc slack channel indicating the outcome of the RFC
  • The FINAL REVEIW is merged

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 in the PR 
  • 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