With Github, one has to fork the project, run some commands to clone the repo from the fork, make the changes, push them, and then go back to the web interface to create the pull request.
I was fine with that as a maintainer too, on three very active major projects at one time (using a 48Mb Pentium 1). A maintainer's job is partly to make it easy for contributors, not for the maintainer, but tending the contributors will help in the end.
That entirely depends on whether the necessary libraries and headers are installed on the system you're using.
> even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup
Unless someone uses emacs and gnus or something similar, email clients could end up mangling the diff unless it was sent as an attachment (which would make reviewing the code and posting an inline response more difficult).
Having to set up one's git config or having to fork a repo seem to be accidental complexity is both cases.
The next time they open a PR using that branch, it will have commits that will clutter the branch.
Moreover, I suggest you fork the project and apply your own modifications instead of worrying about a GitHub project administrator to accept your changes
Of course, for people that know how to use it. I'd argue that the heavy use of Github combined with the adoption of advanced Git workflows is currently the biggest threat to open source. There's no such thing as "submitting a patch" these days. You're expected to be a master of a project's Github workflow to contribute. Most of us (myself included, with a few exceptions) just don't bother.