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 Fri, 10 May 2013 14:48:33 GMT
On 10 May 2013 09:39, Benoit Chesneau <> wrote:

> Though I failed in this bad (imo) habit we took recently to
> propose decisions before discussing the foundations of this
> discussion.

Not everything needs to be discussed.

> All I wanted is discussing what I considered an abuse and
> make some proposals.

Sure. I've invited you to make your proposals. I really hope you do!

> Also I don't have to give concrete examples since the problem I
> describe " use lazy-consensus all the time and only  propose 72 hours
> to react" is the abuse. You may disagree with that but this is what I
> call an abuse.

I am asking you to provide specific examples. We can't talk about this
meaningfully with them.

Not only the problem is that some proposed threads didn't have
> discussions at all

Decision making does not require discussion. Sometimes discussion is good.
Sometimes it is needless.

> either purely or violently objected or simply ignored

Third time you say this without any evidence. Please provide evidence.

> Worst case an idea/code from an ignored thread came 1 year or
> 2 year after is  presented as a new thing.

Why is that a bad thing? Stuff gets recycled. I'm grateful that things are
picked up eventually.(Unless your problem is with the credit. Which I don't
give two shits about. That's some meaningless ego thing.)

> The problem is not to force decisions (yes I call it forcing) by using
> lazy consensus without prior discussions

One of three things must be the case:

 1) You don't understand how lazy consensus works, and so you perceive it
as a way to force through decisions without discussion.

 2) You understand how lazy consensus works, but you disagree with it on
principal, because you believe _all decisions_ require discussion. (Please
note how broad the category of "all" is in this context.)

 3) You understand how lazy consensus works, and can see it has useful
application, but you believe that somebody on this project used lazy
consensus to ram through a decision which should have been handled with a

Please clarify which one of these is the case, and if it is 3, please
provide a reference to the thread where you believe this happened.

> working on taking all new ideas in a positive
> manner, and being open even if the idea sounds stupid at first. Also
> listening about differences. Something that we still have to work on
> imo.

Agree. It would be good if we got better at this.

That exactly my thinking about the lazy concensus *by default*: a
> buraucratic crap and a way to  not share the control with the
> community or make it harder to do it.

Then I think you must misunderstand what "bureaucratic" means.

Two possible definitions:

 1) Making it harder for people to do things by imposing rules, and policy,
adding additional steps you must go through to get anything done.

 2) Making it easier for people to do things by simplifying rules, and
streamlining policy, and removing steps you must go through to get anything

Most people would say "bureaucratic" means 1. And I think most people would
say that imposing the requirement of discussion, followed by a 1 month wait
period before _any_ decision can be made qualifies. And I think most people
would say that lazy consensus is more along the lines of 2.

And this discussion make me think that my next proposal to go to a RTC
> policy [1] will have the same kind of reaction.

I expect so. We have version control for a reason. And from what I have
seen across the rest of the foundation, RTC is imposed by sclerotic
projects paralysed by their fear.

I am open to having this conversation, but I am requesting that you make
things more concrete.


1) Provided references for your statements about "certain" threads where
this abuse is happening.

2) Draft a set of by-laws that we can debate.


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