[jrockway]

Generally, project owners want to see a test accompany any change to demonstrate that a bug was fixed or that new behavior does what's claimed. There may also be coding standards to follow, and (ideally) some documentation for new code.

If the project owner really wants the patch, they will fix these details themselves. In my experience this is how project owners reject patches that they don't want; make the submitter do more work than he is willing to so that the patch silently dies.

Personally, I will usually ask a submitter for a test case and some docs... but if I don't hear from them (or hear, "works for me, no time"), I will just write them myself. Same for style issues; easier to just fix them myself, then I know that the style is exactly what I want.

Github, at the very least, eliminates any technical reason not to contribute. Social issues are largely the same; although back-and-forth is a lot easier when you both have access to a public repository. (Who likes attaching the 8th iteration of a patch to email? Not me.)

[durin42]

Seriously? I'd much rather get a potential repeated contributor who can follow my style than clean it up without asking him to do it. Double for tests: I frequently can't figure out exactly what the best regression test will be and the contributor needs to make it himself (though that may be a special case of my VCS work). Pull requests actively make commenting on a patch harder than a patchbomb in email. The fork queue (imnsho) is even worse, as I've had people just assume I'll see it and just take it from the fork queue page.

Feel free to write me off as a cranky old fart - I've been doing OSS long enough to remember Subversion as a wonderful thing on the horizon and the pure joy of its relative speed. This is all based on my mostly-poor experiences with GH preventing a community domain forming by causing nobody to talk outside of their commit messages, which is a huge loss.