Before Github, submitting a patch required reading some documentation in the project about how to submit patches, set up one's git config to properly generate the patches and email them. Then came the part of actually making the changes, generating the patches and running a git command to submit them.

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.

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.

Github and git are very different. Github is easyer to use, but doesn't cover all of git's use cases. So actually I'm all for reworking the base commands to support a workflow more similar to GitHub's, but still distributed.