On Thu, Sep 18, 2025 at 2:56 AM Eliot Lear <[email protected]> wrote: > My recent experience in modpod suggests that there are limits to what > suggestions can accomplish. We just had to close a PR and start again > because it became quite difficult to figure out what we were actually > landing. This leads me to two points: > > 1. The RPC should consider breaking up each change into an issue. > 2. One or more PRs can close one or more issues (and anyone can open a > PR, but the authors/ADs may need to approve, along with the RPC). > > There are two kinds of PRs in play:
1. PRs from the RPC which enact their changes during the editing process. Hopefully any suggestions to those should be clear because they're not really workshopping ideas but just wordsmithing. These PRs need to be approved by the authors just like any other Auth48 changes. 2. PRs from the authors as part of their review, e.g., if stuff is found in Auth48. These may need more workshopping, but will also hopefully be more targeted, and smaller. As you say, these need to be approved by the RPC and maybe the AD. -Ekr > > Eliot > > > On 18.09.2025 04:54, Richard Barnes wrote: > > > > On Wed, Sep 17, 2025 at 4:44 PM Eric Rescorla <[email protected]> wrote: > >> >> On Wed, Sep 17, 2025 at 7:27 PM Paul Hoffman <[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. >> > > For those who might not have worked much with PRs before, Github > suggestions allow the author to suggest precise changes, which the PR > creator (the RPC) can then accept. > > > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request > > For example, if an author didn't like one of the RPC's changes, the > process would be: > > * RPC proposes change in PR > * Author makes a Github suggestion reverting the change > * RPC accepts and commits the suggestion > > The third step is one click in the Github UI, or the RPC can commit a > batch of suggestions all at once. > > --Richard > > > 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] > >
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
