Re: [Ext] The RPC's roadmap regarding GitHub

[Paul Hoffman <[e-mail]>]

On Aug 4, 2026, at 09:00, Mirja Kuehlewind (IETF) <ietf=[e-mail]> wrote:
> 
> Strong +1
> 
> The right to do that could be that if a wg repo exists the RPC forks that repo, does all its work on its own fork (with the authors or not) and at the end create a PR to the original repo.

Please note that this is *not* a +1 to what Mike proposed:

>> Given this, the end-state that I would like to see is that where a WG-owned gh repo already exists, the RPC should work there not in a newly created hard-copy. I see risks of (2) that we end up with two "official" copies of the document source: one owned by the RPC and one owned by the WG. At a minimum, we probably need written-down process to make sure that those stay in-sync with each other. The path I'm envisioning probably requires standardizing how WG gh repos are run -- you probably want them all centralized under an IETF Org so that the RPC staff (and not just the WG chairs) have administrative access to them.

Mike proposed working in "someone else's" repo, while Mirja proposed working in a fork that could be later PR'd into the earlier repo. 

For many reasons, I support Mirja's proposal over Mike's. There are many ways that WGs own repos, with different ownership models. Some WG drafts still live in repos owned by one of the authors. Not everyone uses the same tooling in their repos. And so on.

The RPC should not have to deal with legacy tooling in repos.

The RPC can fork a repo and use just the .mkd/.xml file there, do what they normally do, then when finished create a pull request for the original repo. It is up to the original repo owner to deal with fighting with merge conflicts or choose to just keep the pre-RPC file separate and start fresh with the RPC output. And it is up to the original repo owner to deal with any other files in the pull request however they want.

--Paul Hoffman