Specifically: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
In my experience, suggestions work well when the changes in the PR are relatively small and isolated, as opposed to say rewriting whole paragraphs or sections. That has pretty high overlap with RPC edits, since the RPC is generally doing fairly localized edits, not large scale things. --Richard On Tue, Oct 7, 2025 at 4:06 AM Eliot Lear <[email protected]> wrote: > > On 07.10.2025 15:48, Michael Richardson wrote: > > Eliot Lear <[email protected]> <[email protected]> wrote: > >> The way to deal with this is GitHub suggestions. > > > I think I said this before, but in my experience, this works well for > small > > PRs, and lousy for big PRs with lots of suggestions. > > Does "suggestion" here refer to the github thing, or the things the RPC > proposes? > > Github ```suggestion > > 1. This works well when the PR has a small number of changes. > -or- > 2. This works well when the PR has a small number of author responses in the > form of github suggestions. > > Suggestions can be committed directly into a PR, and that works for simple > replacements. So long as the PRs are bite-sized, I think this should > work. But if they're lengthy, and if there are multiple authors, or worse, > others, making suggestions, it can be messy. We had this problem with one > or two PRs with modpod, where just had to close them and create new ones > (we were tripping over accepting suggestions and other commits). > > Keeping it simple and small likely avoids that. > > Eliot > > > _______________________________________________ > 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]
