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.

Steps:

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
The submitter updates the "RFC PRs" section of the metadata to link to the PRELIMINARY REVIEW pull request.
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: 1 week

Steps:

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.
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.
If necessary, the submitter may organize ad-hoc meetings/conversations to resolve issues/concerns raised in the PR
The submitter will be responsible for resolving all the conversations in the PR
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.
If approved, all conversations must be resolved and the submitter closes (Do not merge!) the PR in its current state
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 refinement.

Timebox: As long as the submitter requires, but if deviating significantly from the timeline indicated in the RFC Abstract, The Technical Council should be notified.

Steps:

The submitter works on the content of the RFC, staying true to the general direction and agreed upon scope.
The submitter creates a new PR for the DRAFT REFINEMENT stage
The submitter updates the "RFC PRs" section of the metadata to link to the DRAFT REFINEMENT pull request.
The submitter contacts one of the Technical Council chairs when the RFC is ready for DRAFT REFINEMENT.

Advancement Criteria:

A new pull request exists for the DRAFT REFINEMENT 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 DRAFT REFINEMENT.

DRAFT REFINEMENT

Purpose: This stage is not about acceptance or rejection,, rather the intent is to get feedback from domain experts and refine the RFC, preparing it for public review. The aim of this stage is to ensure that the RFC is clear, complete, and contains sufficient details, examples, etc.

Steps:

The Technical Council forms a subgroup (must-have community/TC members who are experts in the area addressed by the RFC)
1. Consideration should be given to including those who might have different perspectives on this (e.g. non-technical, operational, developers, etc.)
2. Subgroup formation should happen quickly. However, draft refinement could be delayed if volunteers cannot be found (e.g. due to lack of capacity, availability, etc.). The Technical Council chairs will take whatever steps are necessary to avoid this situation.
3. The subgroup should include someone willing to act as liaison and provide regular updates to the Technical Council during meetings.
The subgroup works with the submitter to refine the RFC by providing feedback
The submitter will be responsible for resolving all the conversations in the PR
The submitter and subgroup agree that the RFC is ready for advancement.
1. There is no TC review or voting in this stage. Advancement is at the discretion of the submitter and subgroup.
2. The RFC cannot be rejected at this stage, the intent is to help the submitter refine the RFC.
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
The subgroup will provide regular (weekly?) updates on the status of the RFC during this stage at TC meetings

Advancement Criteria:

All conversations have been marked as resolved
The DRAFT REFINEMENT pull request has been closed (Not merged!)
The subgroup has informed The Technical Council that the RFC is ready for PUBLIC REVIEW

PUBLIC REVIEW

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

Steps:

The submitter creates a new PR for the PUBLIC REVIEW stage
The submitter updates the "RFC PRs" section of the metadata to link to the PUBLIC REVIEW pull request.
A message is sent to the public #tc-rfc slack channel announcing the PUBLIC REVIEW stage of the RFC
The Technical Council and submitter determine if additional announcements should be made in other channels (e.g. #sys-ops, #folio-product-council, #development, etc.)
RFC is opened up for a community-wide review. Anyone who wants to provide feedback can participate
Feedback is provided as PR review comments
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
There will be a bias towards not changing the scope of the RFC at this stage as it would likely be disruptive.
The community should really take this opportunity to weigh in on the changes
POCs/Reference implementations are developed to identify any gaps or unforeseen challenges (Optional)
The submitter and Technical Council are in contact throughout this stage and together determine when the public review stage should conclude
A message is sent to the public #tc-rfc slack channel announcing the PUBLIC REVIEW stage of the RFC has concluded.
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

Steps:

The Technical Council will review and deliberate over the comments from the community
The submitter creates a new PR for the FINAL REVIEW stage
The Technical Council does the final review and votes on whether the RFC should be Accepted or Rejected
The FINAL REVIEW pull request is updated with appropriate outcome.
A message is sent to the public #tc-rfc slack channel announcing the outcome of the RFC.
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.
The submitter should work with the Technical Council to log a decision in the Technical Council's Decision Log.
- 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

RFC Template
Slack channel: #tc-rfc