On Wed, Sep 17, 2025 at 8:02 PM Brian E Carpenter < [email protected]> wrote:
> > Just to be clear, if the authors want to make unsolicited changes beyond > what the RPC changed, they should be generating their own PRs, not making > those changes to the RPC's PR. > > > > And if the changes are not purely editorial, they must be reported to the > WG, as long as we're talking about IETF Consensus documents. So that > changes the game. > Well, the RPC side of this is to consult the AD. With that said, it's not been my experience that the AD always asks the WG. > BTW I'm not sure the procedure that Richard outlined is complete. There's > an important step in the current procedure that he didn't list: > > 2a. Script sends RPC's specfic questions to authors in a second email > > and step 3 should read: > > 3. Authors respond to email including answering those specific questions > > So how are those questions handled via Github? And how does the RPC nag > authors that don't reply? > They should be in GitHub issues. And the document simply shouldn't publish until all issues are resolved. -Ekr > > Brian > > On 18-Sep-25 14:43, Eric Rescorla wrote: > > > > On Wed, Sep 17, 2025 at 7:27 PM Paul Hoffman <[email protected] > <mailto:[email protected]>> wrote: > > > > On 17 Sep 2025, at 19:09, Eric Rescorla wrote: > > > > > 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. > > > > How do you picture those author responses to the PR going? Simply as > comments in the PR? Text changes done as commits in the branch that created > the PR? Or something else? > > > > > > Comments to the PR that specify what the authors want clearly and/or > Github suggestions that specify the exact changes. > > > > I don't think commits in the branch that created the PR are helpful and > generally may not be permitted by the GitHub permissions model (depending > on exactly how things are specified). > > > > > > I ask because I suck at commenting in PRs for documents, and when I > do so, I get wildly different advice from the authors about the proper way > to comment in a PR. It would be good if the RPC could say to authors ahead > of time how the authors should interact with the PR (just as they are told > how to respond to AUTH48 email). > > > > > > Well, hopefully this situation is clearer because the space of > reasonable comments is rather smaller, as the authors should only be > commenting on text the RPC has changed, and so mostly you should either be > saying "Please revert this change" or "Here is yet another alternate piece > of text". > > > > Just to be clear, if the authors want to make unsolicited changes beyond > what the RPC changed, they should be generating their own PRs, not making > those changes to the RPC's PR. > > > > -Ekr > > > > > > --Paul Hoffman > > > > > > _______________________________________________ > > 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]
