couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS]
Date Fri, 10 May 2013 18:50:15 GMT
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 <jan@apache.org> 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’d
> 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.
> >
> > 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 !=
> > 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 <nslater@apache.org> wrote:
> >> On 10 May 2013 09:39, Benoit Chesneau <bchesneau@gmail.com> 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
> >> 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 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

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