couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS]
Date Thu, 09 May 2013 00:02:44 GMT
On 7 May 2013 20:07, Benoit Chesneau <> wrote:

> Lazy consensus give this false idea that because no-one objected in
> time then it's OK to process.

This is not a false idea. This principal sites at the very core of how we
do things at Apache.

> That could be true if the expected
> response was not in a short delay or asked before a we

72 hours to gauge lazy consensus is a standard across all 130 Apache TLPs.
It strikes the balance between being able to move quickly, and being
considerate of other people's time.

So I think that something tagged [DISCUSS] should at least let 2 weeks
> or better 1 month to expect a response and make any assumption.

I think this is much too long a time to expect people to wait before they
can assume lazy consensus  We need to become *lighter* in our decision
making process, not heavier.

Having said that, you are free to try and build consensus around your idea.
Please note that unless consensus can be established to change the notice
period, the status quo will be maintained, which is 72 hours.

> If nonone object I would like to push the delay of such discussion to
> 2 weeks by default .

I am -1 on this. I do not want to slow down the decision making process. We
cannot stall our already embarrassingly slow velocity because some people
in the community only check their Apache email once a fortnight.

If you want to be involved more, check your email more. If you can't check
your email more, then recognise that some decisions are going to be made in
your absence.

> Also i really would like that such concensus
> should be optionnal not a common thing to use to pass ideas. This
> isn't natural at all.

Lazy consensus is the *default* decision making process at Apache. We do it
like this precisely because it is hard to co-ordinate a team when people
are unreliable, busy, and distributed across the globe.

As for the "abuse" of DISCUSS threads, I can only assume that
is targeted at me, as I have been doing most of the project co-ordination
the last few months. If you could provide specifics, that would be useful.

I would be happy to use the subject tag PROPOSAL when lazy consensus is
being used, to separate these threads out from general DISCUSS threads.
Please note, however, that in my mental model of how Apache works, a
DISCUSS thread *is* a discussion that will default to lazy consensus. That
is how I have always used that tag. If you think it's confusing, let's
propose a new tag.

On 8 May 2013 05:19, Benoit Chesneau <> wrote:

> Not really. People are not expected to be on their computer all the
> time. Some are disconnecting when they go in vacations for real. Some
> can't connect at all to a public network because of their customer or
> else for some time. The fact is that you can't expect that people
> distributed in the world and work synchronously with you most of the
> time.

Perhaps you're operating under the assumption that our decision making
process requires everyone to look at the proposal and give their opinion.
It does not. I am not even sure how you would define "everyone". All PMC
members? All committers? Anyone subscribed to dev@? If somebody is
traveling for three months, does the project freeze up?

Part of how we operate here is that if you want to be involved in the
decision making process you need to be engaged with the mailing list. That
is a requirement. The project will not stop functioning because someone is
too busy to check your email for two weeks. And it's important that we
operate like this so that individual circumstances do not slow the project

> Dropping a mail on the mailing-;list on big topics an expecting
> an answer in 72h is not really fear. Until you expect that people
> works in sync on that topic.

Can you clarify this point? Better yet, provide a specific example. It is
hard to reason about this stuff in the abstract.

If you're referring to Bob's recent post about BigCouch, I'd say the
community has had a fair run up to this thread. (About 18 months...)

And -1 can be properly ignored in lazy concenssus.

No, a -1 *cannot* be ignored. That's the whole point. If somebody objects,
lazy consensus fails, and it should go to a discussion, and then a vote (if

> Lazy consensus are not about looking for a consensus at all.

Yes, it is about looking for consensus.  Again, this is really foundational
stuff to how we operate at Apache. Lazy consensus is called "lazy" because
it assumes that if you don't speak up, you are giving consent. This is one
form of consensus building that we use.

A way to confirm an idea without any real discussion.

Yes. Discussion is not a _necessary_ component of decision making.

> I do think that
> lazy consensus shouldn't be use for important topics that engage all
> the community.

We need a set of project by-laws that encode what sort of decision making
process can be used for what sort of change. This is on my todo list. But
if someone wants to run with the idea, let me know, and I'll dump my notes
on you.

> And I do think that asking for a short time in recent topics was used
> as a convenience.

Of course lazy consensus is a convenience. A great one!

> They didn't require so much urgency. They could have
> been handled in the week.

No! The project already moves too slowly. This is _not_ the direction I
want to take CouchDB.

> Lot of projects outside couchdb do this way.
> Even in companies.

I don't care what other people are doing. This is how we do things at
Apache, and I believe it is beneficial for our project.

> To take an example I don't think that the merge of bigcouch should be
> done on lazy consensus, it should be a full vote. Because ii is more
> than a technical changes. It can also be considered as a switch in the
> philosophy of the project so giving more time to people to think about
> it would be interesting.

Again, we have no way of knowing, because we have no by-laws.

> Giving the possibility to veto it or to
> express their opinion too.

You still have the option to veto. Hmm. Perhaps you are misunderstanding
what lazy consensus is? When someone says they will assume they have lazy
consensus unless anybody objects, you _can_ speak up, and you _can_ object,
and that _does_ block the proposal.

On 8 May 2013 21:08, Randall Leeds <> wrote:
> I think the sensible way to do things would be to have discussion open
> for a week or two and then a lazy consensus email summarizing the
> discussion and what consensus the OP believes we have. That could be
> just 72 hours, but at that point the discussion has already happened
> and the 72 hours is a formality to ensure that people have a chance to
> quickly disagree about what the discussion yielded.

We would need to be _very_ careful about what we actually encode into our
bylaws here. I will strongly oppose any proposal that means that every
decision this project makes needs two weeks of discussion to precede it.

I might remind you that a checkin to Git would then require a patch to be
posted to the ML first, and for two weeks of discussion to happen, before
it could be pushed to the remote. (Because yep, commits are a form of

Let's take another example. I established the announce@ mailing list, with
a 72 hour lazy consensus window. That didn't need two weeks of discussion.
Same with the release archiving, etc. And same when I propose people for
committership. None of these things require two weeks of discussion!

If somebody has a *concrete* proposal here about how we can change our
decision making process, I would like to here it. But it needs to be
concrete on what sort of decision categories we are identifying, and what
sort of decision making process we want to make for each of them.

As I mention, I have this on my todo list, so if you give me a bit of time,
I'll bring it up eventually anyway. Until that happens, I think we just
have to use our judgement. I don't think anybody here is likely to do
something reckless.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message