Project Management PMC

The Apache Software Foundation

Lazy Consensus

The concept of "Lazy Consensus" is very important in our project. Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. You don't have to insist people discuss and/or approve your plan, and you certainly don't need to call a vote to get approval. You just assume you have the community's support unless someone says otherwise.

We have a time machine (Subversion), this means that as long as you commit (or submit patches) early and often the community has plenty of opportunity to indicate disapproval. If you believe the community will support your action you can operate on lazy consensus as long as you are prepared to roll back any work should a valid objection is raised.

Avoiding Unnecessary Discussion

The key thing about lazy consensus is that it's easier for people to agree, by doing nothing, than it is to object, which requires an alternative to be proposed. This has two effects, firstly people are less likely to object for the sake of it and secondly it cuts down on the amount of unnecessary mail traffic and discussion.

Lazy consensus means we can avoid waiting for a community based decision before proceeding. However, it does require everyone who cares for the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, but objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is watching and cares.

Stating Lazy Consensus

Sometimes a member of the community will believe a specific action is the correct one for the community but are not sure enough to proceed with the work under the lazy consensus model. In these circumstances they can state Lazy Consensus is in operation.

What this means is that they make a proposal and state that they will start implementing it in 72 hours unless someone objects. 72 hours is chosen because it accounts for different timezones and non-apache commitments. If the 72 hours are touching a weekend it would be wise to extend the timeframe a bit. This will ensure that people can participate in the proposal even when they were offline over the weekend.

In this approach the original proposal is not insisting that there is a discussion around their proposal, nor are they requesting that the community explicitly supports their actions. However, this differs from assuming lazy consensus since it allows space and time to express support or objections and corrections to the proposal before work begins.

People may choose to indicate their support for the actions taken with a +1 mail - quick and easy to read and reassuring for the implementer. However, remember, in a lazy consensus world silence is the equivalent to support. This can take some time to get used to.

Apache Software Foundation

Copyright © 2011-2017 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 | Contact Us | Terms of Use

Apache and the Apache feather logo are trademarks of The Apache Software Foundation. and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.