Re: Wait, What?
My point here, is that a pull request comes pretty close to the end of a proper change management process, not the start. If someone wants to contribute to a project, surely the first point would be to raise an issue and get agreement on the maintainer (or maintainers) on what that issue should cover and its acceptance criteria, and then agree on who is going to do the work, before writing a single line of code, let alone putting in a PR for it. GitHub should make it easy for that to be the default process, not the "anything goes, here's a hundred pull requests from random strangers" approach.
I don't maintain public repos (my personal projects are private, and my work ones are private to the organisation I work for), and I do understand that open-source projects might like to encourage contributors in a less formal and process-driven way than commercial ones. However, they should make doing things "properly" the default way of doing things, or at least offer the option when creating a repository for how pull requests should be managed.
What I have done in the past, is to raise a bug report with a publicly maintained repository, which involved clicking a link on an error message in that application, which automatically filled in the issue details in GitHub (after logging in); this shows that this is obviously possible to do, and to automate. Even though the error in question included a stack trace, and it as clearly written in a language I am familiar with, I still wouldn't have dreamed of downloading the source, finding the bit of code in question, modifying it, and submitting a change in a PR, simply because of the number of assumptions I would have had to make about the intended function of that code. As it happens, it would have been wasted time as well, as the maintainer had already fixed the bug in a nightly build.