Page Comparison

...

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.

...

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

...

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:  As long as the submitter requires~ 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.

...

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

...

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

...