GitHub at least has a simple way of making small changes: You can simply click 'Edit' on any file, which will make a fork, commit and pull request in one operation. It's only good for single-file changes you're confident to make in a simple web text editor, though. I've only used it for typos.
I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming/<username>/<branchname>` in the original repo.
Isn't that up to the repository maintainer whether they allow pushes from other people? And sure, it litters your list with forks, but you can remove them as soon as the PR is merged. And that's the case for pretty much anything you contribute to (unless you can push there, of course).
No, there is no process in Github to allow everyone to push to a certain branch (or branches matching some regex). Github forces people without collaborator rights to use forks.
I've seen this lead to confusion where people fork a repo and send PRs even though they have contributor rights, because they didn't understand the difference. As an extreme example: https://github.com/flystack/misty/pull/101 - This is a repo with only one person with write access [1]. Yet this same person only commits to their private fork of this repo and sends himself PRs that he then immediately merges. I don't mean to blame the developer, only the Github UX.
[1] It says "6 contributors" on the mainpage of the repo, but four of these are from my team and we definitely don't have write access.
> Isn't that up to the repository maintainer whether they allow pushes from other people?
That's an orthogonal concern. What they're saying is what the essay suggests at the end, Github could maintain a list of "contributor refs" in the source repository in the same way they expose PR refs (refs/pull/*/head).
This could be managed entirely by the service provider (e.g. github) and invisible to the repository maintainer until a PR is created.
