An extremely common pattern that I observe, especially with first-time Open Source contributors, is that they will fork a repository, make a change on their main/master branch, and then submit a pull request from their main/master to the upstream project.
This has a number of side effects:
- If there is a minor correction that the maintainer would like (e.g., a typo in a comment/release note), the project maintainer cannot edit the PR. The maintainer must either go through the “request changes” workflow or branch of the contributor’s branch and make a new PR.
- The original contributor is put into a state where they can’t (or, it’s difficult) to have 2 PRs at the same time.
- When the PR is merged, the contributor’s main/master has diverged from upstream, so it is necessary to teach the user how to clean up their fork so that they can update their fork to track upstream and submit their next PR.
All of these problems can be resolved if you know how to drive Git and Github. However, my experience is that first-time contributors usually do not have a sophisticated working knowledge of Git and Github; every one of these problems is an impediment to the first-time contributor experience. I find that, as an Open Source maintainer, I end up spending a lot of time teaching newcomers about basic Git/Github workflow, asking for minor changes that I could easily make myself, and/or guiding them to repair their local fork and checkout in the aftermath of a contribution.
All of this could be avoided if Github would allow an option to prevent pull requests from the main/master of a fork. If a project could require all PRs to come from a feature branch on the contributor’s repository, contributors would be unable to submit PRs that the maintainer can’t edit, and wouldn’t end up with repositories in a state where repair work is required after the PR is merged.
Two related nice-to-have option would be to enable a project to set the default behavior of a fork to be “reject commits to master” (so that a contributor can’t submit their bugfix/feature code to their fork’s master; and an option in the Github GUI to bring a fork’s main/master up to date with the upstream’s main/master.
All these features are in the category of UX changes to make it easy to do the right thing, and hard to do the wrong thing. I’m sure there will always be reasons to disable these options - but if they were available to projects, and set as defaults for new forks, the friction I’ve repeatedly seen with new contributors would be significantly reduced.