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

[Mike Ounsworth <[e-mail]>]

RPS makes a fork and PR back to the origin when done makes sense to me too. Good suggestion Mirja.

That said:

> 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.

I do think that for a plethora of reasons, the IETF will sooner-or-later have to grapple with standardizing how we handle git repos of active WG documents. We've already had flavours of this, for example whether discussions on github issues / PRs count as "official WG activity" for the purposes of calling consensus.

I would also advocate that all adopted drafts should have their .xml / .md in git, not necessarily enforcing any specific set of build tools, but just for the purpose of having the source of the draft publicly available and easy to find -- if it's a WG document, then the WG (and not just the authors) should have a copy of the draft source. And also because github issues and PRs are an incredibly effective way for community members to do reviews and submit suggested changes.

Example: We recently had a document in ACME which was a single-author draft, then that author changed jobs and completely stopped responding, so the chairs had to assign additional authors. It was a pain to first figure out if the draft source was even on github (thank goodness it was or we would have been reconstructing the source from the datatracker copy), and then we hard-forked the repo into https://github.com/ietf-wg-acme/ and handed out write access to the new authors. But that was not ideal because the list of open and past Issues, and open and past PRs did not come with the hard-fork. Also, we now had two repos and during WG development, some people submitted issues and PRs to the old repo that got lost for months before the (new) authors noticed.

Based on this experience, I strongly advocate for standardizing how we handle ownership of the gh repos of active WG documents, and I would like to make it mandatory for authors to use the github "Transfer Ownership" functionality to move it to a gh org controlled by the chairs and RPC as part of adoption.


-Mike 

"Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.


"An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr

On Tuesday, August 4th, 2026 at 3:23 PM, Paul Hoffman <[e-mail]> wrote:

> 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
> 
>