The new contribution policy I'm considering for my open-source projects:
"PRs are only accepted for trivial fixes (documentation typos, fixing broken links, that sort of thing), but not for code. Please file an issue instead, if you've found a problem with the software. And if you wish to become a contributor, please reach out to me."
The reason for this approach: "one-off" PRs often cost more time to review and coordinate changes on, than it would take to just do it myself. Which would be fine, *if* there was a reasonable chance of the contributor sticking around, and putting the newly learned things into practice on future contributions.
But they almost never do, and it's not sustainable to put this kind of effort into an endless stream of one-off contributors who I will never see again. The whole point is to distribute the workload, not increase it. Having long-term contributor relationships also makes things like funding (of contributor work) much easier to deal with.
Thoughts?
That said, given the assumption that you're going to do everything through Github, an Issue is probably better than a Pull Request, just because it goes onto their list of issues webpage. (Which here, is analagous to using a tag like #issue)
