The Apache Software Foundation

Community > Code


The concept of “lazy consensus” is very important in your project. Lazy consensus means that when you are convinced that you know what the community would like to see happen, you can assume that you have consensus in favor of the proposed work and and get on with it. 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 or Git). As long as you commit (or submit patches) early and often, the community has plenty of opportunity to indicate disapproval or point out issues. 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 someone raise a valid objection.

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 them to propose an alternative. This has two effects: first, people are less likely to object for the sake of objecting and, second, it cuts down on the amount of unnecessary email traffic and discussion.

Lazy consensus lets us avoid having to wait for a community-based decision before proceeding. However, it does require everyone who cares about the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, while 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 project but is not sure that there will be consensus. They may not wish to proceed with the work without giving the community an opportunity to provide feedback. In these circumstances they can make the proposal and state that lazy consensus is in operation, like this:

In this approach the the proposer does not insist that the developer community discuss or explicitly support the proposal. However, it allows space and time to express support or objections or propose corrections to the proposal before work begins.

People may choose to indicate their support for the proposal with a +1 mail - quick and easy to read and reassuring for the implementer. However, remember, in a lazy consensus world silence is equivalent to support.