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 uncontroversial: 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.

Advantages

With that lazy consensus model it is possible to unblock situations where pull requests are fairly uncontroversial. It gives people a chance to read them and move on if there’s no significant objection. It also helps putting a deadline on issues to make transparent if they are time sensitive or not.

Origin

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 participate across time zones, different work schedules and holidays while still getting to a fast decision.

Lazy Consensus in InnerSource

For our InnerSource projects this time frame can vary substantially - the goal for each decision made with Lazy Consensus should be to give people a chance to participate. Occasionally this can mean leaving a decision open for three weeks if it happens to occur during general holiday season. It can also mean to substantially 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.

German version

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

Lazy Consensus

Für Änderungen, die verhältnismäßig unkontrovers sind bietet sich ein alternatives Vorgehen an: Im eigentlichlichen 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 vordefinierte oder im Pull Request selbst angegebene Zeit offen - mindestens aber solange, bis von allen von der Änderung betroffenen Personen angenommen werden kann, dass sie genügend Zeit für Review und möglicherweise für Einsprüche hatten.

Vorteile

Mit dem Lazy Consensus Modell ist es möglich, den Bedarf an expliziter Zustimmung zu reduzieren - dabei aber dennoch bei relativ einfachen Änderungen anderen die Möglichkeit für Feedback einzuräumen. Außerdem ermöglicht es das Vorgehen, Deadlines oder zeitkritische Änderungen als solche zu markieren.

Ursprung

In der ursprünglichen 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öglicht es Personen über Zeitzonengrenzen hinweg an Entscheidungen teilzunehmen - auch dann, wenn die Beteiligten in unterschiedlichen Projekten, Unternehmen, Ländern arbeiten.

InnerSource Verwendung

Für unsere InnerSource Projekte kann die Länge des Zeitfensters ganz unterschiedlich ausfallen - die Wahl der Länge des Zeitfensters sollte immer abhängig gemacht werden davon, wer in die Entscheidung einbezogen werden soll. Teilweise kann es sogar sinnvoll sein, das Zeitfenster auf drei Wochen zu strecken - z.B. dann, wenn die Entscheidung in die allgemeine Urlaubsphase 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 betroffenen Personen fokussiert auf ein Projekt arbeiten und die Entscheidung lokal sehr begrenzt ist.

Weitere Artikel, die in dieser Serie erschienen sind: