RFC Branching Guide

Each phase in the RFC process typically requires review from different parties. It is imperative to craft a pull request that can show accurate diffs while ensuring that the RFC submitter has control over a git repository and every RFC submitter does not require high privileges to the official RFC repository. Steps are outlined below:

1. Fork the official RFC repo at https://github.com/folio-org/rfcs . This is usually only needed once for any number of RFCs to be submitted.
2. Create a file in the text directory at the top of the forked repo. It should follow the template defined here.
   • Ensure that the file is named appropriately, taking note of the sequence numbers of existing RFCs.
3. Make edits to the file as needed for the RFC.
4. Commit edits and push changes to the forked repo.
5. In the forked repo on GitHub, create a PR comparing the branch where edited file is located to the master branch of the official RFC repo.
   • Ensure the name of the pull request has the name of the RFC phase at the beginning. e.g. "[DRAFT REFINEMENT] Java 17" or "DRAFT REFINEMENT | Java 17"
6. When the interactions on the pull requests are complete there are two options based on the current status of the RFC:
   1. There are still other phases left in the RFC process: Close the pull request and start from Step 3 in this guide.
   2. The RFC is at the last phase: The pull request will be merged by a maintainer of the official RFC repo. The RFC should be at its end with no other actions necessary.