Lazy consensus vs explicit voting

Published On: 20. Januar 2020|Categories: Tech|
Sample Caption

Imagine the following situation: You would like to drive a change in the gh#innersource repository. You already have commit access. Typically you’d make the change, post it as a pull request and wait until someone has time to review and approve.

(German version below)

There is another way that we typically choose when the change is relatively uncon­tro­versial: In the original pull request, indicate that the model for the change is a lazy consensus model where the pull request is kept open for a defined number of days — and if nobody objects, it will get merged after this period is passed. The exact time frame can be set on a per pull request purpose. At the minimum it should be large enough for everyone affected to become aware of the change and have a chance to provide feedback.

Advan­tages

With that lazy consensus model it is possible to unblock situa­tions where pull requests are fairly uncon­tro­versial. It gives people a chance to read them and move on if there’s no signi­ficant objection. It also helps putting a deadline on issues to make trans­parent if they are time sensitive or not.

In the original definition of The Apache Software Foundation the minimum period to run a lazy consensus decision is mentioned as 72 hours. This gives people the chance to parti­cipate across time zones, different work schedules and holidays while still getting to a fast decision.

Lazy Consensus in Inner­Source

For our Inner­Source projects this time frame can vary substan­tially — the goal for each decision made with Lazy Consensus should be to give people a chance to parti­cipate. Occasio­nally this can mean leaving a decision open for three weeks if it happens to occur during general holiday season. It can also mean to substan­tially reduce the time frame if the people involved with the project are focused on  that project alone and spent all of their time working on the project.

Deutsche Version

Stell Dir folgende Situation vor: Du würdest gern eine Änderung im gh#innersource Repository durch­führen. Du hast bereits Schreib­rechte im Projekt. Norma­ler­weise machst Du Deine Änderungen, reichst sie als Pull Request beim Projekt ein und wartest bis jemand Zeit hat, explizit nicht nur ein Review durch­zu­führen, sondern die Änderung auch zu bestä­tigen.

Lazy Consensus

Für Änderungen, die verhält­nis­mäßig unkon­trovers sind bietet sich ein alter­na­tives Vorgehen an: Im eigent­lich­lichen Pull Request wird als Vorgehen für die Änderung “Lazy Consensus” angekündigt. Bei dieser Art Änderungen bleibt der Pull Request für eine entweder vorde­fi­nierte oder im Pull Request selbst angegebene Zeit offen — mindestens aber solange, bis von allen von der Änderung betrof­fenen Personen angenommen werden kann, dass sie genügend Zeit für Review und mögli­cher­weise für Einsprüche hatten.

Vorteile

Mit dem Lazy Consensus Modell ist es möglich, den Bedarf an expli­ziter Zustimmung zu reduzieren — dabei aber dennoch bei relativ einfachen Änderungen anderen die Möglichkeit für Feedback einzu­räumen. Außerdem ermög­licht es das Vorgehen, Deadlines oder zeitkri­tische Änderungen als solche zu markieren.

In der ursprüng­lichen Definition von Lazy Consensus bei The Apache Software Foundation beträgt das minimale Zeitfenster für eine Lazy Consensus Entscheidung 72 Stunden. Dieses Zeitfenster ermög­licht es Personen über Zeitzo­nen­grenzen hinweg an Entschei­dungen teilzu­nehmen — auch dann, wenn die Betei­ligten in unter­schied­lichen Projekten, Unter­nehmen, Ländern arbeiten.

Inner­Source Verwendung

Für unsere Inner­Source Projekte kann die Länge des Zeitfensters ganz unter­schiedlich ausfallen — die Wahl der Länge des Zeitfensters sollte immer abhängig gemacht werden davon, wer in die Entscheidung einbe­zogen werden soll. Teilweise kann es sogar sinnvoll sein, das Zeitfenster auf drei Wochen zu strecken — z.B. dann, wenn die Entscheidung in die allge­meine Urlaubs­phase fällt. Auf der anderen Seite kann es aber auch passieren, dass das Zeitfenster deutlich kleiner ausfällt — z.B. dann, wenn alle von der Entscheidung betrof­fenen Personen fokus­siert auf ein Projekt arbeiten und die Entscheidung lokal sehr begrenzt ist.