This is from the C4 chapter of Social Architecture by Pieter Hintjens. This book was published using the Creative Commons Attribution-ShareAlike 3.0 Unported license. The sources are available from GitHub. The rest of the text on this page is a quote from pages 59–60, published under the same license.
It turns out that accepting imperfect patches rapidly, which I call “optimistic merging”, works better all-round than insisting that contributors deliver perfect work.
Standard practice (Pessimistic Merging, or PM) is to wait until continuous integration testing (CI) is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as “I don’t like how you do this” or “this doesn’t fit with our project vision.”
In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation.
PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates:
- It tells new contributors, “guilty until proven innocent,” which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse.
- It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will.
- It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die.
- It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move.
- It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. “I don’t like this code.” Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors.
- It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we’re told to fix our work alone.
Now let’s see how this works when we use Optimistic Merging, or OM. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects:
- Good contributors who know the rules and write excellent, perfect patches.
- Good contributors who make mistakes, and who write useful yet broken patches.
- Mediocre contributors who make patches that no-one notices or cares about.
- Trollish contributors who ignore the rules, and who write toxic patches.
PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2).
Let’s see how each scenario works, with PM and OM:
- PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project.
- PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project.
- PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it’ll happen rapidly. Contributor loses interest and eventually the patch is reverted.
- PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.
In each case, OM has a better outcome than PM.
In the majority case (patches that need further work), Optimistic Merging creates the conditions for mentoring and coaching.