From dev-return-27188-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri May 10 19:00:45 2013
Return-Path:
X-Original-To: apmail-couchdb-dev-archive@www.apache.org
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id EC8C9F8A6
for ; Fri, 10 May 2013 19:00:44 +0000 (UTC)
Received: (qmail 82848 invoked by uid 500); 10 May 2013 19:00:44 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 82798 invoked by uid 500); 10 May 2013 19:00:44 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 82788 invoked by uid 99); 10 May 2013 19:00:44 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 19:00:44 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.219.52 as permitted sender)
Received: from [209.85.219.52] (HELO mail-oa0-f52.google.com) (209.85.219.52)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 19:00:37 +0000
Received: by mail-oa0-f52.google.com with SMTP id h1so5237959oag.25
for ; Fri, 10 May 2013 12:00:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:in-reply-to:references:date:message-id
:subject:from:to:content-type;
bh=QvRMmmI3WQoqr8LndW/qia8/Np0cnOss0HfWEFtyjqo=;
b=ZrFDSOlx3lZcvBTGmqAqHEzhMTOCWd9fMG2sLDmAtdANFrTa+pqC/e5dCAfMrjFaaO
M3WCFN9Auh10GpnCIuBbtT5883hAs7bN8vQv20OVkidYAImASqCdsSNeNq2Ikm2bqNBM
v7yF4CsmGAyQeSTOFGh264Tqmu3W1UOqW0z28oWB7TJaDTov195L+wlEgO6S6C4oi22l
PAUyJ4Ky6KwRfWt4pWujEW9/8odmz6ygBqxWsf/impMbZX8vVA/7nvIAyJrwC27dIMib
DcMNPyS/da2Jc8zeRu5lsExZgJfagRTkfbKWhLf6qbSrsjLW67bRApPOp+baGDbZQF8i
voCQ==
MIME-Version: 1.0
X-Received: by 10.182.134.231 with SMTP id pn7mr7517571obb.11.1368212415820;
Fri, 10 May 2013 12:00:15 -0700 (PDT)
Received: by 10.76.29.50 with HTTP; Fri, 10 May 2013 12:00:15 -0700 (PDT)
Received: by 10.76.29.50 with HTTP; Fri, 10 May 2013 12:00:15 -0700 (PDT)
In-Reply-To:
References:
<3E30B4E7-CE71-4007-A59C-C68A422C5E54@apache.org>
Date: Fri, 10 May 2013 12:00:15 -0700
Message-ID:
Subject: Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS]
From: Randall Leeds
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11c2c39606095f04dc61c7f9
X-Virus-Checked: Checked by ClamAV on apache.org
--001a11c2c39606095f04dc61c7f9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'll hop in to repeat my observation one more time and offer evidence of
the behavior which caused me to empathize with Benoit.
In the recent email about old releases tagged [DISCUSS] Noah said:
"If nobody objects in 72 hours, I will assume lazy consensus and proceed."
I like lazy consensus and consider it rolling and ubiquitous in the actions
of committers and in play even as we make decisions with zero discussion.
We act because we *believe* we would have consensus. In every case where
there is no formal discussion I believe I am representing my best guess at
what *would be* explicit consensus if it were discussed. This is my
understanding of lazy consensus but I'm happy to be corrected.
However, 72 hours seems antithetical to discussion. If you call for
discussion because you want feedback, please give some time, especially
when it's not urgent. I'm not sure it is necessary to say exactly how long.
That's a concrete recommendation from me. I hope that is constructive and
can help resolve this discussion.
On May 10, 2013 11:50 AM, "Noah Slater" wrote:
> It's also perfectly fine to respond saying "woah there cowboy, we need to
> discuss this first."
>
>
> On 10 May 2013 19:47, Jan Lehnardt wrote:
>
> > 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=E2=
=80=99d
> > 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 wrote=
:
> >
> > > I'm starting to think you don't read me carefully enough.
> > >
> > > I don't care about giving any evidence. The topic is about giving mor=
e
> > > 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 t=
o
> > > take my arguments in consideration keeping to ask me to show you how
> > > thing turned out to be wrong. Which is not the topic.
> > >
> > > 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 cas=
e
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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 yo=
u
> > > give depending on the importance of the decision or the urgency.
> > >
> > > To say it another way: this discussion is about the proposed policy t=
o
> > > use the lazy consensus *by default*. I hope it's clear now. And this
> > > discussion is perfectly legal imo.
> > >
> > > Voila.
> > >
> > > - benoit
> > >
> > > On Fri, May 10, 2013 at 4:48 PM, Noah Slater
> wrote:
> > >> 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 hou=
rs
> > >>> 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 th=
is
> > >> 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 evidenc=
e.
> > >>
> > >>
> > >>> 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 thin=
gs
> > 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 perceiv=
e
> 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 usefu=
l
> > >> 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.
> > >>
> > >> Please clarify which one of these is the case, and if it is 3, pleas=
e
> > >> 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. Als=
o
> > >>> listening about differences. Something that we still have to work o=
n
> > >>> 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, an=
d
> > >> streamlining policy, and removing steps you must go through to get
> > anything
> > >> done.
> > >>
> > >> Most people would say "bureaucratic" means 1. And I think most peopl=
e
> > would
> > >> say that imposing the requirement of discussion, followed by a 1 mon=
th
> > 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 R=
TC
> > >>> 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.
> > >>
> > >> Specifically:
> > >>
> > >> 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.
> > >>
> > >> --
> > >> NS
> >
> >
>
>
> --
> NS
>
--001a11c2c39606095f04dc61c7f9--