...
Purpose: Submitter and other contributors flesh out the rest of the RFC and notifies the Technical Council when it's ready for refinementpublic 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, but if deviating significantly from the timeline indicated in the RFC Abstract, The Technical Council should be notified.
...
- 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 PUBLIC REVIEW stage
- The submitter updates the "RFC PRs" section of the metadata to link to the DRAFT REFINEMENT the PUBLIC REVIEW pull request.
- The submitter contacts one of the Technical Council chairs when the RFC is ready for DRAFT REFINEMENT PUBLIC REVIEW.
Advancement Criteria:
- A new pull request exists for the DRAFT REFINEMENT the PUBLIC REVIEW stage
- RFC metadata contains a link to the new PR
- All conversations have been marked as resolved
- The DRAFT REFINEMENT pull request has been closed (Not merged!)
- 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)
- Consideration should be given to including those who might have different perspectives on this (e.g. non-technical, operational, developers, etc.)
- 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.
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.
- There is no TC review or voting in this stage. Advancement is at the discretion of the submitter and subgroup.
- 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:
- 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
...