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]
