Title:     Lazy Consensus
Notice:    Licensed to the Apache Software Foundation (ASF) under one
           or more contributor license agreements.  See the NOTICE file
           distributed with this work for additional information
           regarding copyright ownership.  The ASF licenses this file
           to you under the Apache License, Version 2.0 (the
           "License"); you may not use this file except in compliance
           with the License.  You may obtain a copy of the License at
           .
             http://www.apache.org/licenses/LICENSE-2.0
           .
           Unless required by applicable law or agreed to in writing,
           software distributed under the License is distributed on an
           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
           KIND, either express or implied.  See the License for the
           specific language governing permissions and limitations
           under the License.

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 communities 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 project but are not sure that there will be consensus. In these 
circumstances they may not wish to proceed with the work without giving the 
community an opportunity to feedback. In these circumstances they can make the 
proposal and 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.

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][1] and corrections to 
the proposal before work begins. 

## Silence is consent

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.

  [1]: /committers/consensusBuilding.html