Yeah, I dunno, the github PR 'culture' I've engaged in has often in fact been about code review. I don't see any problems with forking a repo publicaly to make a PR (what is there to hide?), am not really bothered by merge commits (and in some cases they are actually quite useful, some people prefer them, it's a point of some contention), and I don't really understand what they mean by 'Comments are sent as they are written; you cannot "draft" comment'
But to each their own -- I'm curious what alternative system (if any) of accepting patches they have. If it's emailed git patches on a listserv, then I would definitely find it a barrier to submitting patches, myself, compared to github PR's.
I think in general, github PR's have proven succesful at soliciting code contributions from a wider field, which seems to be the goal of their UI (over command line git itself). Of course, this can seem a downside too, as committers have to spend time dealing with those submissions.
Moreover, you can fork a repo, then work on the actual repo in whatever form you want. Most of my forks are just to maintain public branches, and I have any number of private or unfinished stuff on my home machine.
But to each their own -- I'm curious what alternative system (if any) of accepting patches they have. If it's emailed git patches on a listserv, then I would definitely find it a barrier to submitting patches, myself, compared to github PR's.
I think in general, github PR's have proven succesful at soliciting code contributions from a wider field, which seems to be the goal of their UI (over command line git itself). Of course, this can seem a downside too, as committers have to spend time dealing with those submissions.