couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged [DISCUSS]
Date Fri, 10 May 2013 21:08:25 GMT
I am not thrilled about the idea of increasing lazy consensus time. If
you're engaged with the mailing list, then you can pitch in. If not, then
things are going to happen in your absence. I think that three days is a
fair trade-off between wanting to move quickly, and wanting to make sure
that people with day-jobs can contribute in their spare time.

Note that some projects have it in their by-laws that weekends and holidays
don't count. I think I would be +0 on that change, if somebody wanted to
propose it.

I would ask though: what problem are we actually trying to solve here? I'm
not aware of any instance when something passed on lazy consensus that was
later considered to be a mistake. And by extension, I know of zero
instances where an increased waiting period would have changed anything.

So why bother? :)

However, I do think we have some confusion about how decision-making
actually happens. Like, if I want to do X, is lazy consensus okay? Do I
need a vote? If I need a vote, what sort of vote? Majority approval?
Majority consensus? Single Transferable Vote? I think we ought to discuss
these things, and document them in a set of by-laws.

And yes, I use "NOTICE" to mean "this thing happened" or "this thing will
happen". i.e. It's not something I'm opening up for discussion or lazy
consensus. It's just a statement of intention, or fact.

I think perhaps it would be a good idea to document the tags we're expected
to use. (Though, I think, it can only ever be a recommendation. People will
forget, etc.)

I am happy to start using "PROPOSAL" to mean "this is a proposal and lazy
consensus is in effect".

Okay, so I just read this again:

Wow. What a great document.

So, it makes it clear that you can actually just *assume* lazy consensus in
everything you do. (Very important!) So no need to explicitly start a
thread to try and get it. If you're confident, you can just go ahead and do
the thing. Woop.

But, if you are a bit hesitant, then you can make your proposal and
explicitly state that lazy consensus is in operation.

To wit:

The concept of "Lazy Consensus" is very important in our project. 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. // [...] // Sometimes a member of
> the community will believe a specific action is the correct one for the
> community but are not sure enough to proceed with the work under the lazy
> consensus model. In these circumstances they can state Lazy Consensus is in
> operation. // What this means is that they make a proposal and state that
> they will start implementing it in 72 hours unless someone objects. 72
> hours is chosen because it accounts for different timezones and non-apache
> commitments.

Very well articulated.

Also, note, that there ought to be certain circumstances where it is
mandated that a proposal be made before the action is taken. For example:
small events and branding approval. I think I would want those things to be
proposed each time.

So, to summarise how I think we should document this in our by-laws:

1) Most of the time, you can assume you have consensus for whatever it is
you want to do. So have at it!

2) Some of the time, you might be a little unsure. In those instances, you
should make a proposal to the dev@ list, and tag the subject with
"PROPOSAL". Mention that lazy consensus is in effect, and after 72 hours
you can proceed.

3) There are some specific things that always need a proposal to be made.
That is, you cannot assume consensus. You must make the proposal, and give
72 hours for people to object. Those things are: [...]

And how about this for the tags we're using:

DISCUSS - This is an open discussion with no time limit

REQUEST - This is a request for some action to be taken (prepare release
notes, testing, merge, etc)

PROPOSAL - This is a concrete proposal with consensus in effect and a 72
hour time limit

VOTE - This is a formal vote with a 72 hour time limit

NOTICE - This is a notice of action taken, or action about to be taken
(i.e. no discussion or consensus needed)

ANNOUNCE - This is a project level announcement

On 10 May 2013 21:23, Randall Leeds <> wrote:

> On Fri, May 10, 2013 at 1:16 PM, Noah Slater <> wrote:
> > On 10 May 2013 20:39, Randall Leeds <> wrote:
> >
> >> So I'd prefer to see [DISCUSS] and [URGENT] used and just be mindful
> >> that discussion suggests ample allotment of time for discussion. I
> >> don't believe we need a specific tag for lazy consensus because I
> >> agree with you that it's the default operating mode.
> >
> >
> > Randall,
> >
> > My only issue here is that I think "URGENT" misses the mark also.
> >
> > There are several community / project-level things that one might want to
> > do where all you really ought to do is notify dev@ that you're about to
> do
> > it. Some examples I can think of:
> >
> > * Big changes to the website
> > * Big changes to the wiki
> > * Changes in stuff like release procedure
> > * Archiving releases
> > * Planning marketing activity
> > * Getting approval for small events
> > * Getting branding approval
> >
> > There are plenty more.
> >
> > So, I guess what I'm trying to say is that I'm more than happy only using
> > "DISCUSS" to mean "here's an open ended discussion", but I want a tag
> that
> > means "here's something I'm about to do".
> >
> > I agree that we don't need a specific tag for lazy consensus, simply
> > because lazy consensus is the default. But if "DISCUSS" is causing some
> > people to think "oh well, I'll read that next week when I have time" then
> > it would be handy to be able to explicitly tag a thread with "this is
> > something that is about to happen, so speak up now". And I don't think
> > "URGENT" is the right tag. Because archiving a release isn't urgent. But
> I
> >  _will_ be moving ahead if I don't hear any objections about it. Do you
> see
> > what I mean?
> Yes. If it's something worth bringing up to the list at all, and it's
> not urgent, then maybe one should wait longer than 72 hours before
> moving ahead.
> I know it's a small increase in workflow burden to keep a loop open for
> longer.
> How about [NOTICE]? You use that sometimes. What exactly do you use it
> for? That sounds a bit to me like "you should read this, but I'm not
> expecting discussion". Perhaps that's a better tag for this sort of
> thing than [DISCUSS]?


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