To be clear, what I was trying to say was not that all the RPC's changes should be in one PR -- though I think that's easiest for the RPC at this point -- but rather that as they iterate on a given set of changes they should be in a single PR.
The basic concept here is that a PR represents a set of intentional changes to the document, so the process works like this: 1. The RPC makes some set of changes to the document. 2. Those changes are put up for review and comment by the authors as a PR. 3. In response to that review, the RPC refines the changes and updates the PR. Steps (2) and (3) continue until everyone agrees on the contents of the PR, at which point it is merged into the document. For this reason it's important that the updates in response to comments be in the same PR so it's easy to see what's changed in each revision. It's totally fine if the RPC wants to make multiple PRs (e.g., a pass for references, a pass to update figures, spell checking, etc.) but my understanding was that their process involved making all the changes more or less simultaneously so this wasn't convenient for them. Specifically, the current AUTH48 process involves a complete document revision that unifies all the changes, so I assumed it would be easiest to just put that up as one big PR, which is also fine. -Ekr On Wed, Sep 17, 2025 at 7:00 PM Martin J. Dürst <[email protected]> wrote: > Hello everybody, > > Sorry to comment from the sidelines (not having attended any meetings). > > With regards to keeping all content review work in one PR, I think in > general that should make sense. But please keep in mind that people will > have experiences with, and preferences for, various different ways of > working with git (or other version control systems). So I think it would > be a good idea to be flexible on this point. > > Also from a content point of view, sometimes different edits may affect > different aspects of the document, and it may make sense to keep these > as different PRs. > > Regards, Martin. > > On 2025-09-18 07:39, Jean Mahoney wrote: > > Richard, > > > > Thank you for the write-up. This process doesn't require much in the way > > of tooling (basically a repo template) or GH setup (add authors and AD > > as collaborators). > > > > In today's meeting [1], Ekr had recommended keeping all content review > > work in one PR. Is that your thinking with this process? Then a separate > > PR for RFCXML conversion when the content is approved as was discussed > > in last week's meeting [2]? > > > > Best regards, > > Jean > > > > [1] https://datatracker.ietf.org/meeting/interim-2025-rpc-07/session/rpc > > [2] https://datatracker.ietf.org/meeting/interim-2025-rpc-06/session/rpc > > > > On 9/17/25 4:58 PM, Richard Barnes wrote: > >> I mentioned on the call last week that I had had Gemini write up some > >> instructions based on the discussion last week. Here they are for > >> what it's worth: > >> > >> https://docs.google.com/document/ > >> d/1fEUtC9GO7y6h6rIR0ZsRRHsMBT0qq0VO3GlPwc_W-1g/edit?usp=sharing > >> <https://docs.google.com/document/ > >> d/1fEUtC9GO7y6h6rIR0ZsRRHsMBT0qq0VO3GlPwc_W-1g/edit?usp=sharing> > >> > >> As I said on the call today, I think the minimum viable thing here > >> would be even simpler than that, just replacing the email interface > >> with an interface that is actually designed for editing documents: > >> > >> OLD > >> 1. RPC receives source document > >> 2. Script sends edited document to authors in email > >> 3. Authors respond to email > >> 4. RPC copies document from email to RPC system > >> > >> NEW > >> 1. RPC receives source document > >> 2. RPC initializes GitHub repo with source document > >> 3. Script sends edited document to authors in email (authors can ignore) > >> 4. RPC copies edited document to Github repo, makes a PR, emails > >> authors link to PR > >> 5. Authors review PR; RPC merges > >> 6. RPC copies document from Github repo to RPC system > >> > >> That seems like a workflow you could deploy this afternoon. It has a > >> couple of manual steps, but they would take roughly 5 minutes more per > >> AUTH48, and you could document them in less than two pages of git > >> commands and GitHub screenshots. > >> > >> Hope that helps, > >> --Richard > >> > >> > >> _______________________________________________ > >> rfc-interest mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > rfc-interest mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > rfc-interest mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
