**Session Date/Time:** 10 Sep 2025 21:00

# [RPC](../wg/rpc.html)

## Summary

This session focused on the RFC Production Center (RPC)'s roadmap for adopting Git and GitHub into its processes. The discussion covered the RPC's internal plans (Phase 1) for version control and issue tracking, and future interactions with authors (Phase 2). Key topics included the RPC's internal workflow with branches and pull requests, the decision to create new repositories per document rather than forking existing working group repos, and the timeline for making these repositories public. There was significant discussion regarding transparency (making repositories public from the start), the structure of pull requests for author review at the O48 stage (content vs. formatting changes), and how to best accommodate author-initiated changes during the RPC's editing process.

## Key Discussion Points

*   **RPC's Current State and Internal Git/GitHub Adoption (Phase 1):**
    *   The RPC currently lacks version control in the developer sense, relying on snapshots and file backups in a flat file system.
    *   Upcoming tools include a new queue management system (Purple), editing software (Draft Forge built on VS Code), and a new website.
    *   Phase 1 focuses on internal use of Git and GitHub for version control and issue tracking by RPC editors.
    *   Proposed workflow: Purple creates a new repo upon document approval. Editors clone, create branches for work (e.g., formatting, reference checking, copy editing), push commits, and create pull requests (PRs) upon completion of a pass.
    *   Discussion on potential merge conflicts for parallel work (e.g., formatting and ref checking edits): Jean indicated that RPC staff has GitHub training and experience with merge conflicts, and expects merges to be clean as different parts of the document are typically touched.
*   **Author and Community Interaction (Phase 2):**
    *   The RPC will create *new* repos for each document, rather than forking existing working group repos, due to a lack of consistency in how different working groups use GitHub.
    *   Phase 2 involves making these RPC repositories public. Authors would be able to view RPC pull requests and the issue tracker. A mechanism for authors to port RPC edits back to their own repositories is planned.
    *   The RPC intends to accommodate authors who submit in Markdown by providing Markdown files at the O48 stage, making it easier for them to incorporate RPC changes into their own Markdown-based repos.
*   **Transparency of Internal Processes:**
    *   The initial plan proposed by Jean was to keep Phase 1 repositories private during internal process development, then make them public at the beginning of O48 in Phase 2.
    *   Several attendees (Eker, Paul, Richard, Jay) expressed a strong sentiment that RPC repositories should be public (read-only) from the very beginning, even during internal processing. The argument was that IETF operates transparently, and there's no secret information; making it public would allow the community to see work being done and potentially offer positive feedback, without allowing interference.
    *   John voiced concerns about making O48 public even in a read-only fashion, citing risks of disruptive individuals attempting to meddle with the editorial process, which has historically been under the RFC Editor's control once a document is approved. He stressed the importance of clear boundaries.
    *   Jean clarified that even if public, only approved authors and the AD would be added as collaborators with permission to make changes.
*   **Structure of Author Interaction and PRs at O48:**
    *   Richard and Eker articulated a desire for O48 to begin with a "clean diff" – essentially one large pull request representing all RPC edits. This allows authors to review the *net changes* from their submission, rather than individual RPC commits, and to use PR tools to negotiate specific edits.
    *   Eker further suggested a two-stage PR process: a "content PR" (addressing changes in the source format like Markdown) followed by a "finalize XML PR" (for XML-specific formatting minutiae). This would allow iterative content review separate from XML details.
    *   Alice expressed concerns that a rigid separation between content and formatting could be "contrived," as these aspects often intertwine, especially when editing in Markdown (e.g., changing a paragraph to a list). She felt it might hinder a natural editing workflow.
    *   Consensus generally leaned towards prioritizing a content-focused review stage in the source format (e.g., Markdown), with the final XML formatting as a distinct, later step.
*   **Handling Author-Initiated Changes During Editing:**
    *   A question arose regarding how to manage author changes while the document is in the RPC's editing queue (pre-O48).
    *   Paul preferred that authors submit changes to the RFC editor, who then makes the commit (maintaining RPC control).
    *   Eker and Richard strongly advocated for authors to be able to make direct changes (e.g., via a pull request to the RPC repo, or queuing changes in their own repo until O48) rather than re-submitting through a different format.
    *   Jean explained the existing process: authors submit technical changes to DataTracker, the AD approves them, and then Purple/DataTracker creates a pull request on the RPC repo for the editor to review and merge. This process is already in place for pre-O48 technical updates.
*   **Timeline for Phase 2:**
    *   Jean estimated Phase 2 (public repos, author interaction) would be "late next summer" (approximately one year from now).
    *   Attendees (Richard, Eker) expressed strong concern that this timeline is too long and should be significantly accelerated.

## Decisions and Action Items

*   **Decision:** The RPC will proceed with an initial focus on internal Git/GitHub adoption (Phase 1) to establish processes and editor comfort.
*   **Decision:** The RPC will create *new*, dedicated repositories for each document during its editorial process, rather than attempting to fork existing working group repositories.
*   **Decision:** The RPC will support authors working in Markdown by providing Markdown files at the beginning of the O48 stage for documents originally submitted in Markdown.
*   **Action Item:** The RPC will schedule further discussion on accelerating the timeline for Phase 2 (making repositories public and interactive for authors) at the upcoming RPC monthly community call.
*   **Strong Community Sentiment (not a formal decision):** There was a strong sentiment among many attendees that RPC repositories should be made public (read-only) from the very beginning of the RPC's process (Phase 1), rather than kept private until the O48 stage. This is a point for the RPC to consider.
*   **Strong Community Sentiment (not a formal decision):** The O48 review process should ideally incorporate a two-stage approach, with an initial review focused on "content changes" in the source format (e.g., Markdown) followed by a separate review for final "XML formatting" details. This aims to improve the author review experience.

## Next Steps

*   The RPC will continue with internal development and editor training for Phase 1 of its Git/GitHub roadmap.
*   The RPC will hold further discussions at its next monthly community call to explore possibilities for accelerating the timeline for Phase 2 and making repositories public.
*   The RPC will consider the strong community feedback regarding transparency (making repos public from the outset) and the proposed two-stage O48 review process in its ongoing planning and implementation.