The RPC currently uses a file system for storing documents that they are editing and a manual process for creating diffs (for details, see the Current File Management, Issue Tracking, and Version Control page). The tools modernization plan includes incorporating git and GitHub for version control.

For the first phase of working with GitHub, document repos will remain private as the RPC implements and refines their internal processes for version control and publication.

Each document's source file (RFCXML or kramdown-rfc) will be placed in its own repository, which is created by the queue management system (called Purple) once the document is approved. These repos will be private and only accessible by RPC staff.

The repo will have GitHub actions that will do the following:

• Ensure the document is well formed and that basic actions can be performed on it (e.g., create output formats).
• Create output formats (HTML, PDF, text) and inline and side-by-side diff files that show the updates from the version stored in datatracker.
• Provide links to these files on a staff accessible webpage so that editors can check the files upon commit. For example:

The RPC editors will interact with the GitHub repo using DraftForge, the editing software created by the Tools Team. The editor will clone the repository locally, make changes to the document, commit those changes to their branches, and create pull requests through DraftForge.

Editors will work in branches that they have created from main, making small commits as they work. They will create pull requests on GitHub when they have completed their work on the document for the next editor in the editing process to review. The document is first edited by the Document Specialist, who does formatting, then the Citation Specialist, who checks references and links, and the Primary Editor (PE), who copyedits the document.

The PE will review the pull requests created by the Document and Citation Specialists and merge them into main when the PE is satisfied with the updates. The PE then creates branches off main for their own edits.

When the PE is done, RFC Editor (RE) will review the PE's pull requests. The RE will merge the PRs into main when their review is complete. The RE will then create branches from main for their own edits. When they have completed their editing work, they will merge their branches into main.

Questions and issues between editors can be added to the repo's issue tracker. For questions that involve suggested text, an editor can create a pull request against the working branch showing the changes. However, questions to authors will continue to be placed in the document so the authors can see the questions as they review the source file. These questions can be exported via DraftForge and placed in an email message to authors.

Interactions with authors will continue to occur via email during the first phase.

The editor who launches AUTH48 will invoke a GitHub action to make the web page that links to the formats, source, and diff files public. Another action will send an email message to the authors and other interested parties (ADs, WG chairs, etc.) to let them know that the RFC is available for final review.

The editor handling AUTH48 will create an auth48 branch and make commits for updates received by the authors.

Note that author approvals and IANA actions will be handled via Purple and not via GitHub actions.

Once the authors have approved the document, the editor merges the auth48 branch into main. They create a pre-pub branch for any updates that need to be made before publication. These edits tend to be small things like updating the date and usually do not require further author approvals.

The publishing editor reviews the pre-pub PR and makes any other updates. Occasionally, the publishing editor asks the authors a question and may update the document based on that question. The publishing editor merges the PR into main when they are ready to publish.

The publishing editor invokes a set of publication GitHub actions to run the preptool, and to place files and data with various services (rfc-editor.org, datatracker, rsync, bib.ietf.org, crossref.org).

• DraftForge with following features: GitHub support, XML validation (in progress)
• DraftForge training for editors (todo)
• Purple integration with GitHub (todo)
• GitHub actions created and functioning (todo)
• Refresh GitHub training for editors (todo)
• Migrate from the current file system to GitHub repos

For the second phase, the GitHub repo can be shared with authors, ADs, chairs, and Doc Shepherds (aka the document team), who can be made repo collaborators when the document enters AUTH48, but an author's interaction with the repo is not mandatory. Authors may choose not to interact with the GitHub repo and may continue to use the email-based AUTH48 process as GitHub is not the main workflow mechanism for the streams.

The RPC will confirm that the entire document team is willing to use GitHub when the document enters the queue. If a document team member is unwilling to work with GitHub, then the email-based process will be used.

Questions to the authors will be placed in the issue tracker. The editor will construct PRs that have suggested text updates that address issues in the issue tracker. The editor will make the repo public and available to the collaborators at the beginning of AUTH48. PRs that suggest changes to the document text will be open for author review.

Authors will review the RPC's PRs and can either merge the PR if they approve, or they can provide their own text suggestions (by either editing the branch or creating their own branch). Authors can create PRs to address open questions in the issue tracker.

A PR created by an author will be reviewed by an editor. If there are no issues, the editor will merge it. If the changes are beyond editorial, the editor will ask the stream approver to review and review the PR.

Once all PRs are merged and the authors have approved the document, the publication process continues as described in the first phase. An action will be available to help the authors merge the RPC's edits into their document repo if they have one so they can have both their repo's history and the RPC repo's history of their document.

• Team comfort with GitHub processes - estimated to take 3 months time after Phase 1 complete (todo)
• GitHub actions created and functioning (todo)
• Experimentation with a few documents first before opening more widely (todo)

For more information about RPC projects, please see:

• RPC Roadmap
• RPC Community Calls