Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (nike.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged
 [DISCUSS]
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: 
 <CAJNb-9pL6LAuqb-gfVFiNg9XfExRSYBSsOp+9AderZ_wNME4TQ@mail.gmail.com>
Date: Fri, 10 May 2013 19:47:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E30B4E7-CE71-4007-A59C-C68A422C5E54@apache.org>
References: 
 <CAJNb-9pRGw11-Ajo2Tu5COrdLsVEZUEDy9q5qPAMby_zx4WLsQ@mail.gmail.com>
 <CAPaJBx79zV1JSNL5BnPF_TxYEaW-2ZpLf+WAi6wa4QA94mFSmA@mail.gmail.com>
 <CAJNb-9qWecvR3hiv9i_U0aOqqOn6yvXvEf6fmpw4DHH91LJDfQ@mail.gmail.com>
 <CAPaJBx7nE_oLQ0q1S8zUZek=RS8m2YgUfr=2QfCmEjBtEjA8ng@mail.gmail.com>
 <CAJNb-9qhPHBFiB1ocXByGCHi3=2F19PcPQHir-p5TRR15Yz1-Q@mail.gmail.com>
 <CAPaJBx6aeBgGrngZichzArr30jwBG+JDE0uqEgnHVNmngnPi1Q@mail.gmail.com>
 <CAJNb-9psGxtYHCwV9uvgD-ZjHpw2sQRyDYd5O5NawZ6+_fJO8A@mail.gmail.com>
 <CAPaJBx41gVHvcfbGkWYUFU5oFLpPVSwxvZgUpXLO=WbNAyWQ=A@mail.gmail.com>
 <CAJNb-9pL6LAuqb-gfVFiNg9XfExRSYBSsOp+9AderZ_wNME4TQ@mail.gmail.com>
To: dev@couchdb.apache.org

Maybe what is missing from this is that lazy consensus leads to things
that can never every be changed again. It is just a tool to keep a
distributed team going. If we do a thing and it gets lazy consesus=92d
and implemented and even shipped, we can still *at any time* realise
it was a mistake, make a course correction or revert and move on.

Jan
--


On May 10, 2013, at 19:30 , Benoit Chesneau <bchesneau@gmail.com> wrote:

> I'm starting to think you don't read me carefully enough.
>=20
> I don't care about giving any evidence. The topic is about giving more
> time to the discussion. The principle of using *by default* lazy
> consensus is what I consider an abuse. I explained it why third time
> in that thread. And already did it before that mail. But you refuse to
> take my arguments in consideration keeping to ask me to show you how
> thing turned out to be wrong. Which is not the topic.
>=20
> The problem by using lazily consensus over a shot time is that you
> don't let people think about it much. Which wouldn't be a problem if
> there was an intense communication between people. But this isn't the
> case today. Some ideas are still coming from nowhere without
> preparation. Don't get me wrong I don't say that these ideas are bad
> or that there wasn't any thinking behind them. No the problem is you
> expect that people are able to answer it in 72 h or so. your time.
> Which don't let  sometime the time to think much about it and give
> your opinion or possible changes to it. Sometimes you really want to
> tell a thing but finally can't do it because of timing issues.
> (Sometimes yes, you 3 days are really short). Maybe it could be just
> by saying it (like "hey I really want to answer but i don't have the
> time") which I think could work. But I clearly think that in that case
> just giving more time or simply not using lazy consensus could just
> work. This is why I propose to adapt the time asked for a lazy
> consensus depending on the context, ie. not using 72 h by convenience.
> The delays proposed were just some suggestions.
>=20
> To be clear, I strongly disagree to use the lazy consensus as *the
> default* way to take decisions. The apache way considers it as an
> important and main way to build (some kind of) consensus.  But main !=3D=

> default . It is also saying that we should try to build a consensus
> first. But not it is not saying that *lazy* consensus must be used by
> *default*. By culture I don't like anything that is lazy by default
> but I can accept its use.
>=20
> All the rest is out of topic. Though the thing wasn't a question of
> ego. You missed the point. The problem was the lack of communication.
> But this is out of topic and I won't answer to that here.
>=20
> To make it more clear since you asked it. This discussion is about
> discussing the use of the lazy consensus *by default* and for me it
> should be just an option, not something use for anything. It all
> depends on the context. And in any case think more about the delay you
> give depending on the importance of the decision or the urgency.
>=20
> To say it another way: this discussion is about the proposed policy to
> use the lazy consensus *by default*. I hope it's clear now. And this
> discussion is perfectly legal imo.
>=20
> Voila.
>=20
> - benoit
>=20
> On Fri, May 10, 2013 at 4:48 PM, Noah Slater <nslater@apache.org> =
wrote:
>> On 10 May 2013 09:39, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>=20
>>> Though I failed in this bad (imo) habit we took recently to
>>> propose decisions before discussing the foundations of this
>>> discussion.
>>=20
>>=20
>> Not everything needs to be discussed.
>>=20
>>=20
>>> All I wanted is discussing what I considered an abuse and
>>> make some proposals.
>>>=20
>>=20
>> Sure. I've invited you to make your proposals. I really hope you do!
>>=20
>>=20
>>> 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.
>>=20
>>=20
>> I am asking you to provide specific examples. We can't talk about =
this
>> meaningfully with them.
>>=20
>> Not only the problem is that some proposed threads didn't have
>>> discussions at all
>>=20
>>=20
>> Decision making does not require discussion. Sometimes discussion is =
good.
>> Sometimes it is needless.
>>=20
>>=20
>>> either purely or violently objected or simply ignored
>>=20
>>=20
>> Third time you say this without any evidence. Please provide =
evidence.
>>=20
>>=20
>>> Worst case an idea/code from an ignored thread came 1 year or
>>> 2 year after is  presented as a new thing.
>>>=20
>>=20
>> 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.)
>>=20
>>=20
>>> The problem is not to force decisions (yes I call it forcing) by =
using
>>> lazy consensus without prior discussions
>>=20
>>=20
>> One of three things must be the case:
>>=20
>> 1) You don't understand how lazy consensus works, and so you perceive =
it
>> as a way to force through decisions without discussion.
>>=20
>> 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.)
>>=20
>> 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
>> discussion.
>>=20
>> 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.
>>=20
>>=20
>>> 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.
>>=20
>>=20
>> Agree. It would be good if we got better at this.
>>=20
>> 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.
>>>=20
>>=20
>> Then I think you must misunderstand what "bureaucratic" means.
>>=20
>> Two possible definitions:
>>=20
>> 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.
>>=20
>> 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
>> done.
>>=20
>> 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.
>>=20
>> And this discussion make me think that my next proposal to go to a =
RTC
>>> policy [1] will have the same kind of reaction.
>>=20
>>=20
>> 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.
>>=20
>> I am open to having this conversation, but I am requesting that you =
make
>> things more concrete.
>>=20
>> Specifically:
>>=20
>> 1) Provided references for your statements about "certain" threads =
where
>> this abuse is happening.
>>=20
>> 2) Draft a set of by-laws that we can debate.
>>=20
>> --
>> NS