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 do not have to insist people discuss and/or approve your plan, and you certainly do not 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 (git), 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 be raised.

Avoiding Unnecessary Discussion

The key thing about lazy consensus is that it is 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 is not sure that there will be consensus and may not wish to proceed 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.

Proposals should be sent to list, preferably the development list. It is common to indicate proposals by including the string [#proposal] at the beginning of the subject to make it easier for the community to identify that the mail contains an important proposal.

This triggers the Lazy Consensus mechanism, by which the proposal is considered accepted if no one objects within 72 hours after the proposal submission. The period of 72 hours is chosen because it accounts for different timezones and any non-Opencast commitments the community members may have.

In this approach the original proposer is not insisting that there is a discussion around the proposal, nor is it requested that the community explicitly supports their actions. 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.