But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.
Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change.
Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?
And yes, I do appreciate the rare cases when I can just make the change in the web interface of the original project. But most one-time changes I make involve compiling (or at least running) something.
I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.
This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.