[[!tag git github pull-request workflow]]
In mid-2017, I decided to experiment with using pull-requests (PRs) on Github. I've read that they make development using git much nicer. The end result of my experiment is that I'm not going to adopt a PR based workflow.
The project I chose for my experiment is vmdb2, a tool for generating disk images with Debian. I put it up on Github, and invited people to send pull requests or patches, as they wished. I got a bunch of PRs, mostly from two people. For a little while, there was a flurry of activity. It has has now calmed down, I think primarily because the software has reached a state where the two contributors find it useful and don't need it to be fixed or have new features added.
This was my first experience with PRs. I decided to give it until the end of 2017 until I made any conclusions. I've found good things about PRs and a workflow based on them:
- they reduce some of the friction of contributing, making it easier for people to contribute; from a contributor point of view PRs certainly seem like a better way than sending patches over email or sending a message asking to pull from a remote branch
- merging a PR in the web UI is very easy
I also found some bad things:
- I really don't like the Github UI or UX, in general or for PRs in particular
- especially the emails Github sends about PRs seemed useless beyond a basic "something happened" notification, which prompt me to check the web UI
- PRs are a centralised feature, which is something I prefer to avoid;
further, they're tied to Github, which is something I object to on
principle, since it's not free software
- note that Gitlab provides support for PRs as well, but I've not tried it; it's an "open core" system, which is not fully free software in my opinion, and so I'm wary of Gitlab; it's also a centralised solution
- a "distributed PR" system would be nice
- merging a PR is perhaps too easy, and I worry that it leads me to merging without sufficient review (that is of course a personal flaw)
In summary, PRs seem to me to prioritise making life easier for contributors, especially occasional contributors or "drive-by" contributors. I think I prefer to care more about frequent contributors, and myself as the person who merges contributions. For now, I'm not going to adopt a PR based workflow.
(I expect people to mock me for this.)