[no_protocol]

One thing I wish GitHub made easier is responding to a pull request with a patch rather than encouraging reviewers to type up a bunch of suggestions that the original submitter will have to turn into a patch themselves.

If you have a better idea how to accomplish part of a suggested change, you can communicate that more clearly by making a patch and leaving a comment explaining why. GitHub should encourage this and allow the submitter some interface to easily incorporate that patch into his PR.

This is especially useful in situations where the only changes are in documentation or writing rather than code. Dealing with a dozen responses of "s/topy/typo/" should be as simple as clicking a few buttons to accept all the corrections. It would be less work for both sides.

[jamesmiller5]

One of the killer features of Gerrit for code review is web-ui editing that can be turned on for the author and other contributors. See a typo? Feel free to click "edit" & fix it, saving everyone time. The edits increment the patch-set number, so no information is lost.

The Gerrit maintainers are also working on the idea of comments that include a proposed fix, letting the author just click "apply" to patch the change in the editing interface.

[steveklabnik]

Have you seen https://github.com/blog/2247-improving-collaboration-with-fo... ?

[no_protocol]

Yes, that is very nice, but it doesn't help if I am not a maintainer of the upstream project.

Since I haven't used it, I'm not sure, but it seems like it would also help avoid the case of "Can you squash this before I accept it?" leading to pointless delays and extra work.

[steveklabnik]

Sorry, I thought you were speaking as a maintainer. You mean reviewing someone else's PR on a project you're not a maintainer of? Yeah that's "send a PR to their branch" right now.

> Does it help avoid the case of "Can you squash this before I accept it?" leading to pointless delays and extra work?

That's https://github.com/blog/2243-rebase-and-merge-pull-requests; lets you choose squash and/or rebase as you merge.

[vkjv]

Not sure if it's what you had in mind. But, you could comment with a diff code fence. It gets proper highlighting as well.

    ```diff
    diff goes here
    ```

[jochakovsky]

Could this be accomplished with a pull request into their feature branch?

[no_protocol]

Absolutely, and I've done that before, but the web interface doesn't really help with this. You also need to alert the original thread about it manually so others can follow the thread.

If you have five different suggestions, should that be five separate PRs to their feature branch? Probably? Or they will just need to modify or rebase out the commits they don't want.

Anyway, I just like all solutions where "doing the work" is encouraged over "talking about doing the work." Often, the doing takes less time for both sides.

[Bartweiss]

It would be great to have "PR patches" as something handled gracefully by the web interface. Even if they're just branches under the hood, a "click to accept this change" feature on open PRs would be a nice way to encourage simple fixes.

[AndyNemmity]

You could automate out half of feedback by automating a comment that says "add more tests"

Even if you added tons of tests, you'll get add more tests. It almost makes more sense to write tests and hold them, so you can respond with them.

[ben_jones]

Or my personal favorite: auto-respond to feature requests with "PR welcome"