Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

I'd suggest adopting a model that works for your workflow and your project goals, and asking contributors to adopt it as well. Github can also help accommodate this if you want. Example:

- Your project has two mainline branches, one against which development is done and the other from which releases are cut.

- The development mainline is the default branch

- this is the first thing contributors see, and the first branch PRs target

- You "adopt" PRs into the development branch, and when you feel the work is suitable, release it to the release mainline branch

View on HN

Well, the method still isn't perfect, due to the lack of easy, well formated, ability to communicate to the contributor why the PR's commits were changed. The current UI creates a default culture of really tense back and forth nitpicking comments.

Depending on the size of the nits you might be able to merge as is, then open a new issue to address the nits.

And all of these work-arounds just prove that the system could use a little bit of work.

I don't agree. If the PR you're reviewing is expected to be merged into a development branch, you can either:

1. Merge without comment. Unless the contributor is closely following development, they won't even notice what you do with the contribution between your development and release branches. 2. Merge with a comment that you'll be cleaning it up before release, and if you want the person to continue contributing explain what you'll be doing.

Differentiating stewardship from producing solutions can go a long way toward eliminating debate over minutiae.

If there's still tense back and forth, it's probably over approach, understanding of the problem, or awareness of consequences. In none of those cases should the PR be merged. If you want to engage the contribution, explain what the contributor missed and close the PR. If you don't think the contribution is going to be productive, just close it.

Reply on news.ycombinator.com