[rfc-i] Re: Minimal GitHub AUTH48

Thu, 18 Sep 2025 03:03:31 -0700

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

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 [email protected]

Attachment: OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to