incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS]
Date Thu, 09 May 2013 17:06:47 GMT
I was tempted to answer point by point to this mail but I gave up. To
summarise: you're strongly and offensively disagreeing with me. And I
strongly disagree with a lot of them.

Now still. You're saying that I consider lazy consensus invalid. I am
not. Nowhere in my mail I considered them as invalid. But I disagree with
the way they are used currently in the *couchdb* project. Especially
this convenient 72 hrs.

You're saying I didn't make any concrete proposal. I did before this
thread derived. I did it in the introduction. *I proposed to adapt the
time of lazy concensus and use them the less possible*. How is that not
concrete?

Now  I can perfectly accept that people are against this idea, I am not
trying to force anyone or to pass an idea in the silence of others.
There is no irony in that since this is exactly what I was looking for. I
was proposing/launching a discussion on that topic, that is deeply
attached to the principles I have. I can accept the decision from
others even if it's not in the sense I wanted. This is the purpose of a
decision, people don't have to agree with you each time.

Anyway I am chocked that someone can associated the idea of giving the choice
with the idea of permission culture. This is totally unrelated to say
less. Giving the choice  is about beeing open to others and let
them try to improve an idea/discussion/code. I didn't ask to
transform discussions in battlefield. No, I asked to give more time to a
discussion before taking any decision that need a discussion (if not there
is no point to request a lazy concensus if it's just as a way to make
sure you're not alone to take a decision, just do it).

To finish, in my opinion this isn't the absense of such decision that
was the problem during these last 2 years, but more or less the lack of
good discussions and concrete plans.  Also it didn't stop some to still
work on the project even in // (you should ask yourself why it was done
in // rather). I thik the issue is more complex than
that. Now that we have some plans the project is more or
less active. But this is out of topic.

- benoit

On Thu, May 9, 2013 at 5:48 PM, Noah Slater <nslater@apache.org> wrote:
> On 9 May 2013 07:10, Benoit Chesneau <bchesneau@gmail.com> wrote:
>
>> Lazy consensus aren't here to obtain a real consensus.
>>
>
> You are incorrect.
>
> Lazy consensus _is_ consensus, and is an important part of our decision
> making process at Apache.
>
> To quote a very good page on how we use lazy consensus at Apache:
>
> "Lazy Consensus means that when you are convinced that you know what the
> community would like to see happen you can simply assume that you already
> have consensus and get on with the work. You don't have to insist people
> discuss and/or approve your plan, and you certainly don't need to call a
> vote to get approval. You just assume you have the communities support
> unless someone says otherwise."
>
> "The key thing about lazy consensus is that it's easier for people to
> agree, by doing nothing, than it is to object, which requires an
> alternative to be proposed. This has two effects, firstly people are less
> likely to object for the sake of it and secondly it cuts down on the amount
> of unnecessary mail traffic and discussion.
>
> "Lazy consensus means we can avoid waiting for a community based decision
> before proceeding. However, it does require everyone who cares for the
> health of the project to watch what is happening, as it is happening.
> Objecting too far down the road will cause upset, but objecting (or asking
> for clarification of intent) early is likely to be greeted with relief that
> someone is watching and cares."
>
> - http://rave.apache.org/docs/governance/lazyConsensus.html
>
> And to quote from the Apache community development site:
>
> "Lazy consensus is the first, and possibly the most important, consensus
> building tool we have. Essentially lazy consensus means that you don't need
> to get explicit approval to proceed, but you need to be prepared to listen
> if someone objects."
>
> - http://community.apache.org/committers/decisionMaking.html
>
> Your assertion that lazy consensus is somehow "not valid" consensus is
> invalid. Lazy consensus is a very important method we use for building real
> consensus. That along with the "three-valued-vote" are our primary tools
> for consensus building.
>
> There are, approximately, two ways to build consensus and make a decision
> on this project:
>
> 1) You assume that nobody is going to object, announce your intentions, and
> wait 72 hours. If nobody objects, you can assume lazy consensus, and you
> can proceed.
>
> 2) Where it is likely that people might object, or where it is likely that
> there needs to be some discussion of the matter, you start a discussion
> thread. If it appears like there is a majority consensus on the issue, you
> call a vote. The vote formalises the consensus. And if it passes, you can
> proceed.
>
> Both of these approaches are valid, and useful ways of building consensus
> and making decisions. And they are both suited to different purposes.
>
>
>> I won't repeat myself. I will just re-quote the apache
>> documentation:
>>
>>     Reasons for Votes
>>
>>     People tend to avoid conflict and thrash around looking for
>> something to  substitute - somebody in charge, a rule, a process,
>> stagnation. None of these tend to be very good substitutes for doing
>> the hard work of resolving the conflict.
>>
>
> You have quoted that out of context. What that section actually means is
> that when people disagree on something, there is a certain point after
> which an thread becomes repetitive and unproductive. And at that point, it
> is often easier to just tie the discussion off with a vote, and move on
> with the rest of your life.
>
> Ironically, this thread is approaching that situation. From reading the
> responses on this thread, I believe you are the only person who has a
> problem with the concept of lazy consensus and how we use it. However, I
> believe that people would be interested in starting work on a set of
> by-laws that codify our expectations.
>
> So, an example of what not to do next: stop thrashing about and take some
> definitive action. Make a concrete proposal and try to get consensus around
> it. (With another discussion thread, or a formal vote, or whatever you
> think is best.)
>
> If you look at the subject of this thread, that should indicate why you are
> not likely to make much progress here. You've asked us to stop "abusing"
> lazy consensus. But this is more of a complaint than it is a proposal. And
> you can't really build consensus around a complaint. Nor can you identity
> any action that needs to be taken.
>
> A better approach would be to come up with a concrete proposal, and then
> bring that to the list. i.e. What I am asking you to produce is a draft of
> our by-laws. That would be something useful, and positive, that we could
> all discuss and vote on.
>
> Looking for consensus is harder than simply asking to a a vote where
>> you can't really object and that is not really waiting an answer.
>
>
> This is the second time in this thread you have said this. I won't repeat
> this again, but you are mistaken. The whole premise of lazy consensus is
> that it is an *invitation* for you to object. So please, stop saying this.
> It isn't true.
>
>> 72 hours to gauge lazy consensus is a standard across all 130 Apache TLPs.
>>
>> It isn't a standard, but a convenience.
>
>
> What do you mean by this?
>
> Lazy consensus is one of our *core principals*. It's really important you
> understand this!
>
> Further reading:
>
> http://community.apache.org/committers/decisionMaking.html
> http://community.apache.org/committers/consensusBuilding.html
> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
> http://rave.apache.org/docs/governance/lazyConsensus.html
> http://www.apache.org/foundation/voting.html#LazyConsensus
> http://www.apache.org/foundation/how-it-works.html
>
>
>>  > Having said that, you are free to try and build consensus around your
>> idea.
>> > Please note that unless consensus can be established to change the notice
>> > period, the status quo will be maintained, which is 72 hours.
>>
>> Sorry? I didn't ask for a lazy consensus, nor set a delay. I am trying
>> to reach a... consensus ... I will summarize what have been discussed
>> in time.
>
>
> I was trying my best to discern a concrete suggestion from your original
> set of emails. It seemed like you were wanting to increase the 72 hour
> notice period to two weeks, or one month. So, in response to that, I was
> suggesting that you make that proposal, and that you try to establish
> consensus around it. And that if you do not manage to establish consensus
> around it, then it will remain at 72 hours. Because unless you can
> establish consensus to change something, the statue quo is maintained.
>
> Again, this is one of the problems when you bring vague complaints to the
> lists instead of well defined, specific proposals for change. It's very
> hard to talk about vague complaints. (Especially when you leave out the
> details and talk in abstracts.) This is no way to make decisions. All it
> does is frustrate people, and waste time. (Valuable time. We're all
> volunteers!)
>
>
>> Lazy consensus were designed for votes on the code originally.
>
>
> Citation needed.
>
>
>> Voting on the code is only requiring a lazy consensus most of the time.
>> Voting on a decision that engage all the community shouldn't be lazy
>> most of the time.
>>
>
> Disagree strongly.
>
> But if you want to change things, then I suggest you take a look at the
> by-laws of some other projects, and you draft a set of by-laws for CouchDB.
> As I mention above, it is very hard to discuss something like this when it
> is so vague. What does "most of the time" mean, for instance? You need to
> get specific about what you're suggesting, so we can discuss it properly.
>
> Here are some examples:
>
> http://hadoop.apache.org/bylaws.html
> http://hc.apache.org/bylaws.html
> http://struts.apache.org/release/1.2.x/bylaws.html
>
> You can find more if you search for "Apache by-laws" in Google.
>
>
>> Decisions on things that engage community should be presented as a choice.
>
>
> Disagree strongly.
>
> This is a permission culture. Apache is a "do-ocracy" not a "please sir,
> can I have some more sir-ocracy". I do not want to have to come to the list
> begging for permission and opening up a discussion every time I want to do
> something. I trust every committer on this project to act in the best
> interests of this project, and I hope that they trust me in the same way.
>
> This is what is frustrating me about this thread the most, I think. We've
> just elected some new committers, and I want these people to know how we
> really operate here. I want each and every person involved in this project
> to know that they _can_ and _should_ decide what is good for the project,
> and just go do it. (Notifying us as you do it, of course...)
>
> It seriously pains me to think that there are people on this project who
> keep quiet and do not take action because they are too intimidated by the
> "old guard" or because they expect things to erupt in a a "you need my
> permission for this" thread. This is total bullshit, and I will stamp out
> this attitude every time I see it. Wanna do something? Just f-ing do it. ;)
>
> But again, if you can make your proposal more specific, then we can have a
> meaningful discussion about it.
>
> And since the objections made on lazy consensus can be properly ignored
>
>
> This is the last time I will say this. Objections to lazy consensus cannot
> be ignored. Any objection forces the lazy consensus to be abandoned, and a
> discussion, followed by a vote should follow.
>
> (at least they had in the past)
>
>
> Please cite a mailing lis thread in which an objection to a lazy consensus
> was ignored.
>
> I am going to go out on a limb and suppose that you're talking about the
> GitHub comment notification thread. (One of the most embarrassing threads
> on this list in the last six months.) May I remind you that you explicitly
> gave that a -0.9, and said "I am not happy with this but I will not block
> it." So please do not cite this as anybody ignoring your objections.
>
>
>> then it should only be used for things that doesn't require a real
>> consensus
>
>
> You misunderstand lazy consensus or what "real" consensus is.
>
>
>> Lazy consensus should be used to determine the sense of the
>> community when you estimate it doesn't require a real consensus.
>>
>
> Lazy consensus is real consensus.
>
> Please do not argue about this point any more. I have provided a lot of
> documentation. Any further debate about this is pointless, and I will not
> engage in it. Perhaps you disagree with the utility of lazy consensus. That
> is fine. But please do not continue make baseless assertions about what
> lazy consensus is, and how it is used at Apache.
>
> Lazy consensus should be used as a last resort not as a common tool to pass
>> decisions.
>>
>
> This is how we do things at Apache. If you have a problem with this, I'd
> say you have a sisyphean task on your hands.
>
> Urgent thing should be marked as is on the ml, and probably only
>> require some people.
>
>
> No. You cannot rely on other people to filter your mail for you. If you
> want to be involved in the decision making process, then you need to pay
> more attention to your mail, instead of blaming others. I'm fed up of this
> attitude.
>
> I agree that in some instances, important decisions need a lot of
> discussion, and I would like to see more than 72 hours to discuss things
> like that. But these are exceptions to the rule.
>
>> Lazy consensus is the *default* decision making process at Apache. We do
>> it
>> > like this precisely because it is hard to co-ordinate a team when people
>> > are unreliable, busy, and distributed across the globe.
>>
>> It isn't. Lazy-consensus is a way to vote.
>
>
> Yes it is. I have provided citation for this. I will not continue to argue
> this point.
>
> And lazy consensus is not a way to vote. It is a consensus building tool.
> Voting is _another_ consensus building tool.
>
>
>> - Lazy consensus : lazy consensus are generally used for a code
>> update, change a word in a page, etc but not for other things.
>>
>
> Citation needed.
>
> But votes aren't the default way to get decisions. Votes are a way to
>> ask for a decision but shouldn't be used as the default to take these
>> decisions. I won't quote the voting page again.
>
>
> You are right about this. Votes are typically a last resort. Consensus
> should be established before the vote. The vote is just a way to formalise
> it.
>
> But lazy consensus is a streamlined process for building consensus that not
> only doesn't require a vote, it doesn't require a discussion. Again, please
> study the links I provided at the top of this email.
>
> I've created this thread in the hope we go back to a more natural process.
>
>
> If by "go back to a more natural process" you mean "go back to the broken
> permission culture we had for the last three years where people were so
> intimidated by the project leads that they gave up bothering to contribute"
> then no. A thousand times no.
>
>
> On 9 May 2013 07:27, Benoit Chesneau <bchesneau@gmail.com> wrote:
>
>> And I do think that important decisions can't be done on lazy
>> consensus without to make sure you targeted most of the people that
>> needed to be aware.
>
>
> I agree that some important decisions can't be done via lazy consensus. But
> you need to get concrete about what you're proposing here Benoit, or there
> is nothing for us to discuss.
>
> I also want to correct your notion that "certain people" need to be aware.
> I will remind you that there is no such thing as a lead dev on CouchDB, or
> even lead devs. There is no code-ownership. I do not have to ask anybody's
> permission to change any part of the code. There is nobody I need to notify
> before I change such-and-such module/subsystem/file.
>
> This is more of the same "people need to clear things with me first"
> mentality. This is utterly broken, and I won't stand for it. If somebody
> wants to do something, then all they need to do is notify the dev@ list. It
> is then up to you to be monitoring that. If you can't monitor it, then you
> have to accept that decisions may be taken in your absence.
>
>
>> This how it works, even in companies that take care about people.
>>
>
> We're a decentralised group of volunteers. The way we work has to be
> adapted to that situation. Also, we have no management chain. No approvals
> process. Nobody you need to "clear stuff with". And for good reason. This
> kind of thing discourages new contribution, and introduces bus-factor and
> bottle-necks. What happens when you go on vacation? The project freezes?
>
>
>> This thread is about trying to fix the usage of the "lazy discuss
>> votes". If  they  are used as a tool to pass ideas and if they really
>> accept to be denied then I am strongly asking to adapt the delay
>> depending on the importance on what is asked. Again I'm not speaking
>> about code.
>>
>> But lazy consensus, or votes shouldn't be used as the default to make
>> decisions imo.
>>
>
> Please draft a set of concrete by-laws.
>
>
>> You're wrong. What annoyed me is the use of lazy consensus as the
>> default, and passing decisions based on silence of others.
>
>
> Again. This is fundamental to how we work.
>
>
>> Some decisions need thinking. more than 72 hours. Especially when they
>> come from nowhere.
>>
>
> I expect we disagree on the definition of "some decisions". But you are
> certainly correct when you say that lazy consensus is not suitable for all
> decision making. This is a point I have agreed with you on since the start
> of this thread.
>
>
>> > So no, I don't think anybody has "abused" anything. Unless you mean to
>> > suggest that somebody is being tricky and is trying to "slip something
>> > past". That would be a very serious allegation, so you should make that
>> > explicit if you believe it to be the case.
>> >
>> > Again, if you have some exceptions in mind (releases, new committers, new
>> > PMC members, new chairs are all good examples) please bring them to the
>> > list, and we can start our first draft of the by-laws.
>> >
>>
>> This isn't the topic of this thread and I made the intent perfectly
>> clear imo. This topic is about revisit the way lazy consensus are used
>> in the couchdb project.
>>
>
> That somebody has "abused" something is, quite lierally, the topic of this
> thread.
>
> To wit:
>
> "[DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS]"
>
> Also, I was asking you to produce something concrete that we can have a
> meaningful discussion about. At the moment, you seem to be railing against
> Apache. But it is so general and non-specific, that there is no hope of
> making meaningful progress.
>
> I would be thrilled if you were to yank another project's set of by-laws,
> and use that as the starting point for a set of CouchDB by-laws. I have had
> this on my todo list for a while. I think it would be a very beneficial
> thing to come out of this thread.
>
> --
> NS

Mime
View raw message