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 Thu, 09 May 2013 15:48:46 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message