Why Optimistic Merging Works Better - Hintjens.com
Hintjens.com
Moving Pieces
Front
ZeroMQ
Community
Unprotocols
Psychopaths
Create account or Sign in
Pieter Hintjens
Biography | Portfolio | GitHub
Books | Videos | Slides | Stories | Wiki
Contact
Thank you for the gifts
Kind people already sent donations that will make my childrens' lives easier, when I'm not there any more. Thank you enormously! :-)
Podcasts/Interviews
Software Engineering Daily
Interview by Adam Dymitruk
Ruby Rogues #188, Community Building
Talks on video
"De afspraak", VRT, May 2016 (panel discussion)
RTL TV, May 2016 (panel discussion)
DomCode 2015, Nov 2015 (keynote)
Coding Serbia, Oct 2015 (keynote)
Euroscipy, Cambridge, Aug 2015 (keynote)
PyGrunn, Groningen, May 2015
Craft Conf, Budapest, Apr 2015
QCon London, Mar 2015
Code Mesh London, Nov 2014
Build Stuff, Vilnius 2014
Build Stuff, Vilnius, Nov 2014 (interview)
Coding Serbia, Nov 2014 (keynote)
Devnology, Leusden, Oct 2014 (keynote)
EuroPython, Berlin, Jul 2014 (keynote)
Build Stuff, Vilnius, Dec 2013 (interview)
Build Stuff, Vilnius, Dec 2013 (keynote)
Code Mesh London, Dec 2013
DevOps Days, London, Nov 2013
NDC Oslo, Jun 2013
CERN - Geneva, Jun 2013
Tech Mesh, London, Dec 2012
Strange Loop, St.Louis, Oct 2012
ZeroMQ@PDX part 2 - Portland, Feb 2012
ZeroMQ@PDX part 1 - Portland, Feb 2012
FLOSS Weekly, Petaliuma CA, Dec 2011
FOSDEM 2011, Brussels
Berlin Buzzwords 2010 (keynote)
FOSDEM 2009, Brussels
Hellenic FOSS Conference 2008, Athens part 1
Hellenic FOSS Conference 2008, Athens part 2
Email me at moc.snejtnih|reteip#moc.snejtnih|reteip if you'd like me to present at your event, or in your organization.
Download and read online
Legal | About | Contact
Manage | Theme | Top | Side
Why Optimistic Merging Works Better
All Articles " Why Optimistic Merging Works Better
Next >
pieterh wrote on 16 Nov 2015 15:14
I spoke at DomCode in November 2015 (excellent conference, small and beautiful city!) explaining my top rules for building open source communities. One person asked me later to explain why I recommend to merge quickly, without waiting for Continuous Integration testing to finish, and without review of the code. I'm going to call this strategy Optimistic Merging or OM. Here's the reasoning behind OM.
Standard practice (Pessimistic Merging, or PM) is to wait until 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 Merge. 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...