It didn't even require that. You fixed something from the immediately-buildable tarball that you'd rebuilt and tested, or even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup. You didn't have pull 100Mb of git stuff, figure out how to rebuild the build framework, find you hadn't got the submodules, prat about with a pull request, and then whatever demands it makes of you, etc.

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.

> You fixed something from the immediately-buildable tarball that you'd rebuilt and tested

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).

Both seems non perfect to me.

Having to set up one's git config or having to fork a repo seem to be accidental complexity is both cases.

To be fair, setting up one's git config is a one time step. But there is a bit of effort required to keep one's GitHub fork up to date relative to the repository it was forked from.

git fetch upstream ; git rebase -i upstream/master isn't that hard.

It depends on whether the histories have diverged and how many conflicts there are. A lot of people aren't very proficient with the use of git and will have problems (e.g., running git pull) and creating a merge commit in their branch or having conflicts they need to resolve.

The next time they open a PR using that branch, it will have commits that will clutter the branch.