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 an email to
dev@PROJECT, they state their proposal, with sufficient supporting material for someone familiar with the project to understand it.
- In the email they indicate that they will start implementing the proposal in 72 hours unless someone objects. The time period takes into account that project members are a) busy and b) in time zones around the world.
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.
Silence is consent
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.