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 2AF73F765 for ; Fri, 10 May 2013 18:50:17 +0000 (UTC) Received: (qmail 45735 invoked by uid 500); 10 May 2013 18:50:16 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 45705 invoked by uid 500); 10 May 2013 18:50:16 -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 45696 invoked by uid 99); 10 May 2013 18:50:16 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 18:50:16 +0000 Received: from localhost (HELO mail-ie0-f181.google.com) (127.0.0.1) (smtp-auth username nslater, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 18:50:16 +0000 Received: by mail-ie0-f181.google.com with SMTP id x12so8563386ief.40 for ; Fri, 10 May 2013 11:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=fEwfWbn5z9ERAJDIEd487BXPmdu8qqtwtpSYq70mW2E=; b=ImBjwlbK7XhoYXZIMK1u2HRXynVyLGBISVvLHE1UO7u/r4rjKvR7uJmzFF7J0mmrgu kbxdl/U4Ga+805i6iMyjfYdYeWnrvrFv39x566BhbZArpyBeld+gTUqNn8OAX1VC3Ynb zxREpk3Ezg8KQYXuBuEVaNpQtri/zTTl3HIBxf7kXYyZLVHVUU3Mzff+orYHfOXhSmMR c6E+cgCL/7UFaOP46i9Nn67+kWd7/wpcXcZiJXRpq7BlxGOrX4Qs2h1JPZWkNqXOzIdn ezKmnzgo1CHkmeOCPjpIHafVagIN56TNfzbQbDxCU/Mc/jkZRsPFF7QSz5N+3dnEVk+D koGA== MIME-Version: 1.0 X-Received: by 10.50.119.104 with SMTP id kt8mr2992875igb.0.1368211815522; Fri, 10 May 2013 11:50:15 -0700 (PDT) Received: by 10.50.57.114 with HTTP; Fri, 10 May 2013 11:50:15 -0700 (PDT) X-Originating-IP: [178.250.115.206] In-Reply-To: <3E30B4E7-CE71-4007-A59C-C68A422C5E54@apache.org> References: <3E30B4E7-CE71-4007-A59C-C68A422C5E54@apache.org> Date: Fri, 10 May 2013 19:50:15 +0100 Message-ID: Subject: Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS] From: Noah Slater To: "dev@couchdb.apache.org" Content-Type: multipart/alternative; boundary=089e010d91563dfd3104dc61a38b X-Gm-Message-State: ALoCoQnvjeNoG64DRDvMneumDp8veCI0IF/TkfqRmyq7LVvPTusUd0iywxFEv6y/Hj2sX9O3rsTe --089e010d91563dfd3104dc61a38b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=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 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 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. > > > > 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. > > > > 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 you > > give depending on the importance of the decision or the urgency. > > > > 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. > > > > 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 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 usin= g > >>> 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 o= n > >> 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 wit= h > a > >> discussion. > >> > >> 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 > >> done. > >> > >> 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 hav= e > >> 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 ma= ke > >> things more concrete. > >> > >> Specifically: > >> > >> 1) Provided references for your statements about "certain" threads whe= re > >> this abuse is happening. > >> > >> 2) Draft a set of by-laws that we can debate. > >> > >> -- > >> NS > > --=20 NS --089e010d91563dfd3104dc61a38b--