You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2011/08/25 18:46:42 UTC

[migration] Decision making

On Thu, Aug 25, 2011 at 11:58 AM, Terry Ellison <te...@apache.org> wrote:

<snip>

> We seem to have a Catch-22 here, and this email is about how we break this
> and move these aspects of the project forward.  My interpretation of this
> Catch-22 is that whilst our current interactions on the DL are a good basis
> for individuals articulating views on a particular thread (and some seem to
> generate hundreds of viewpoints) we have no functioning mechanism to move
> to, and adopt some form of, a consensus policy or decision.  The exact

I've noticed this as well.  I think the catch-22 is caused by our
collective lack of experience with Apache-style lazy consensus.  This
fact, combined with the us having more list participants with opinions
than list participants able and willing to help with migration, easily
leads to bikeshedding.   This is easy to work through by applying lazy
consensus.

The term "lazy consensus" perhaps is misunderstood.  It doesn't mean
that everyone agrees with you.  It does it even mean that every
project committer agrees with you.  It means that no committer is
strongly opposed to your proposal and is willing to back up their
opposition with technical arguments and the willingness to implement
an alternative solution.

Lazy consensus does not even mean that you propose the idea first on
the list.  If something is reversalable and you are convinced that no
one would object, then JFDI.  That is the basis of Commit Then Review
(CTR).  Try to avoid unnecessary discussions on the list.  That helps
us all focus on the things that actually require discussion.

However, if you think the idea might be controversial, then go ahead
and post a new [Proposal] thread.  State what *you* would like to do,
and say that you will assume Lazy Consensus if no objects arrive in
72-hours.  But again, objections must be from committers, backed with
technical arguments and the willingness to implement alternatives.

With a list of this many subscribers (over 200 now, I believe) it is
inevitable that every proposal will garner a range of response.  Some
might be even voiced as  +1 or -1.  But these notation are often
misused as well.  +1 should mean, "I strongly agree and am willing to
help".  -1 should mean, "I strongly oppose and am willing to help with
the alternative approach".  Intermediate values like +.5 or -0 or
whatever express various softer opinions [1].

So let's work through this by:

1) Don't ask questions unless you really think something requires a
discussion.  You are a committer.  We voted you in because we trust
you.

2) If you think something requires discussion then post a new
[PROPOSAL] thread, preferably one per separate proposal, and state
that you will assume lazy consensus in 72-hours (or some longer time
period at your discretion).  If you don't get any legitimate -1's by
that point, or get other insights that make you want to reconsider
your proposal, then do it.

3) Those who comment on the proposals should try to respect the
meaning of +1 and -1 and use fractional values to express intermediate
positions.  They should also consider saying nothing.  "Silence is
consent".  You might have what seems to you to be a brilliant insight.
 But is it really so important that you should distract us all with it
right now?  Does it really matter.  Does it matter enough to hold back
the progress of migration, or can we deal with it later?  (I'm as
guilty of this as anyone)

Regards,

-Rob


[1] http://www.apache.org/foundation/voting.html

Re: [migration] Decision making

Posted by Ross Gardler <rg...@opendirective.com>.
It's wonderful to see this project getting to this stage so quickly.

In my experience a grasp of the lazy consensus approach is a really
significant step in becoming a viable ASF style community. It's fantastic to
see these issues being raised and clearly addressed by the community.

>From what I have read so far this thread fully reflects decision making in
an ASF project (both Rob's initial response and subsequent clarifications).

If folk want to hear my version of this thread take a look at my ODF
Plugfest presentation and accompanying video (
http://www.slideshare.net/rgardler/the-apache-way-and-openofficeorg video
linked from comments).

Ross

On Thursday, 25 August 2011, Rob Weir <ro...@robweir.com> wrote:
> On Thu, Aug 25, 2011 at 2:49 PM, Donald Whytock <dw...@gmail.com>
wrote:
>> On Thu, Aug 25, 2011 at 12:46 PM, Rob Weir <ro...@apache.org> wrote:
>>> But again, objections must be from committers, backed with
>>> technical arguments and the willingness to implement alternatives.
>>
>> The Apache voting policy page you linked agrees that binding votes are
>> from committers, and that "all others are either discouraged from
>> voting (to keep the noise down) or else have their votes considered of
>> an indicative or advisory nature only."
>>
>> But some things may require noise.  I for one am essentially lurking
>> here as a user, watching the progress of the product on its way to
>> becoming once again current and viable.  I'm technical, but have never
>> touched the guts of OOo.
>>
>> So if you bring up a change, presented as a lazy-concensus proposal,
>> and I think it would adversely affect my experience as a user, I'd
>> very much like to be able to object, even if my objection is
>> non-binding.  I can't stop you, but on the other hand I'd rather you
>> not stop me.
>>
>
> The distinction here is between decision making with lazy consensus
> versus voting.  Voting is a formal procedure, and something we do only
> when required by the process (voting in new committers, approving
> releases, etc.) or in other (hopefully) rare occasions.  A formal vote
> would occur in its own [VOTE] thread, but would be preceded first by a
> [DISCUSS] thread on the same topic.  So your feedback is always
> welcome, especially in the [DISCUSS] thread.
>
> This distinction may not be obvious, since we've only had private
> votes in this project so far, for voting in new committers.  Apache
> requires these be private votes.
>
> A [PROPOSAL] thread is not a vote.  It is someone saying what they'd
> like to do and seeing if there are any strong objections.  If there
> are not, then the proposer will go forward.  Anyone can comment on the
> proposal thread, but my previous comments apply: please comment
> judiciously.  If you think the proposer has goofed or is about to
> goof, and this is a big problem, then by all means, speak up.  The
> project benefits from that.  But with 200 subscribers to the list, if
> we all make minor comments based on slight preferences, then we end up
> with a mess.  Best (IMHO) if we hold back and only comment where and
> when it matters most.
>
>> Don
>>
>

-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: [migration] Decision making

Posted by Rob Weir <ro...@robweir.com>.
On Thu, Aug 25, 2011 at 2:49 PM, Donald Whytock <dw...@gmail.com> wrote:
> On Thu, Aug 25, 2011 at 12:46 PM, Rob Weir <ro...@apache.org> wrote:
>> But again, objections must be from committers, backed with
>> technical arguments and the willingness to implement alternatives.
>
> The Apache voting policy page you linked agrees that binding votes are
> from committers, and that "all others are either discouraged from
> voting (to keep the noise down) or else have their votes considered of
> an indicative or advisory nature only."
>
> But some things may require noise.  I for one am essentially lurking
> here as a user, watching the progress of the product on its way to
> becoming once again current and viable.  I'm technical, but have never
> touched the guts of OOo.
>
> So if you bring up a change, presented as a lazy-concensus proposal,
> and I think it would adversely affect my experience as a user, I'd
> very much like to be able to object, even if my objection is
> non-binding.  I can't stop you, but on the other hand I'd rather you
> not stop me.
>

The distinction here is between decision making with lazy consensus
versus voting.  Voting is a formal procedure, and something we do only
when required by the process (voting in new committers, approving
releases, etc.) or in other (hopefully) rare occasions.  A formal vote
would occur in its own [VOTE] thread, but would be preceded first by a
[DISCUSS] thread on the same topic.  So your feedback is always
welcome, especially in the [DISCUSS] thread.

This distinction may not be obvious, since we've only had private
votes in this project so far, for voting in new committers.  Apache
requires these be private votes.

A [PROPOSAL] thread is not a vote.  It is someone saying what they'd
like to do and seeing if there are any strong objections.  If there
are not, then the proposer will go forward.  Anyone can comment on the
proposal thread, but my previous comments apply: please comment
judiciously.  If you think the proposer has goofed or is about to
goof, and this is a big problem, then by all means, speak up.  The
project benefits from that.  But with 200 subscribers to the list, if
we all make minor comments based on slight preferences, then we end up
with a mess.  Best (IMHO) if we hold back and only comment where and
when it matters most.

> Don
>

Re: [migration] Decision making

Posted by Andy Brown <an...@the-martin-byrd.net>.
Donald Whytock wrote:
> On Thu, Aug 25, 2011 at 12:46 PM, Rob Weir<ro...@apache.org>  wrote:
>> But again, objections must be from committers, backed with
>> technical arguments and the willingness to implement alternatives.
>
> The Apache voting policy page you linked agrees that binding votes are
> from committers, and that "all others are either discouraged from
> voting (to keep the noise down) or else have their votes considered of
> an indicative or advisory nature only."
>
> But some things may require noise.  I for one am essentially lurking
> here as a user, watching the progress of the product on its way to
> becoming once again current and viable.  I'm technical, but have never
> touched the guts of OOo.
>
> So if you bring up a change, presented as a lazy-concensus proposal,
> and I think it would adversely affect my experience as a user, I'd
> very much like to be able to object, even if my objection is
> non-binding.  I can't stop you, but on the other hand I'd rather you
> not stop me.
>
> Don

Hi Don,

I will speak only for myself but as a PPMC member I know that I would 
want to see reasonable, though out, objections from the users.  That 
said, it would have to be more than "I object to such and such". 
Details is what is needed.

Andy

Re: [migration] Decision making

Posted by Donald Whytock <dw...@gmail.com>.
On Thu, Aug 25, 2011 at 12:46 PM, Rob Weir <ro...@apache.org> wrote:
> But again, objections must be from committers, backed with
> technical arguments and the willingness to implement alternatives.

The Apache voting policy page you linked agrees that binding votes are
from committers, and that "all others are either discouraged from
voting (to keep the noise down) or else have their votes considered of
an indicative or advisory nature only."

But some things may require noise.  I for one am essentially lurking
here as a user, watching the progress of the product on its way to
becoming once again current and viable.  I'm technical, but have never
touched the guts of OOo.

So if you bring up a change, presented as a lazy-concensus proposal,
and I think it would adversely affect my experience as a user, I'd
very much like to be able to object, even if my objection is
non-binding.  I can't stop you, but on the other hand I'd rather you
not stop me.

Don

Re: [migration] Decision making

Posted by Terry Ellison <Te...@ellisons.org.uk>.
Rob,

Thanks for your thoughtful and thought-provoking response on this.  I 
think that we broadly think along the same lines on this.  But the word 
that I would pick out of you reply to flag is "reversible".  There are 
two counter scenarios:  (i) something just isn't reversible so there's 
no way back (but there might be a way costly forward close to where you 
were trying to get to; and (ii) there is a way back but it's going to 
involve time, effort and therefore cost consequences.  In either of 
these, it does seem sensible to do the proposal+ 3 day lag as you 
suggest and as I have just done before hitting the "go" button.

Regards Terry

PS (i) does certainly exist.  Ask BP about Deepwater Horizon.  I've had 
to lead the fire-fighting team on a quite few IT scenarios in my career 
though the cost-consequences were usually a few 0's less in size :)

> On Thu, Aug 25, 2011 at 11:58 AM, Terry Ellison <te...@apache.org> wrote:
>
> <snip>
>
>> We seem to have a Catch-22 here, and this email is about how we break 
>> this
>> and move these aspects of the project forward. My interpretation of this
>> Catch-22 is that whilst our current interactions on the DL are a good 
>> basis
>> for individuals articulating views on a particular thread (and some 
>> seem to
>> generate hundreds of viewpoints) we have no functioning mechanism to move
>> to, and adopt some form of, a consensus policy or decision. The exact
>>
>
> I've noticed this as well. I think the catch-22 is caused by our
> collective lack of experience with Apache-style lazy consensus. This
> fact, combined with the us having more list participants with opinions
> than list participants able and willing to help with migration, easily
> leads to bikeshedding. This is easy to work through by applying lazy
> consensus.
>
> The term "lazy consensus" perhaps is misunderstood. It doesn't mean
> that everyone agrees with you. It does it even mean that every
> project committer agrees with you. It means that no committer is
> strongly opposed to your proposal and is willing to back up their
> opposition with technical arguments and the willingness to implement
> an alternative solution.
>
> Lazy consensus does not even mean that you propose the idea first on
> the list. If something is reversalable and you are convinced that no
> one would object, then JFDI. That is the basis of Commit Then Review
> (CTR). Try to avoid unnecessary discussions on the list. That helps
> us all focus on the things that actually require discussion.
>
> However, if you think the idea might be controversial, then go ahead
> and post a new [Proposal] thread. State what *you* would like to do,
> and say that you will assume Lazy Consensus if no objects arrive in
> 72-hours. But again, objections must be from committers, backed with
> technical arguments and the willingness to implement alternatives.
>
> With a list of this many subscribers (over 200 now, I believe) it is
> inevitable that every proposal will garner a range of response. Some
> might be even voiced as +1 or -1. But these notation are often
> misused as well. +1 should mean, "I strongly agree and am willing to
> help". -1 should mean, "I strongly oppose and am willing to help with
> the alternative approach". Intermediate values like +.5 or -0 or
> whatever express various softer opinions [1].
>
> So let's work through this by:
>
> 1) Don't ask questions unless you really think something requires a
> discussion. You are a committer. We voted you in because we trust
> you.
>
> 2) If you think something requires discussion then post a new
> [PROPOSAL] thread, preferably one per separate proposal, and state
> that you will assume lazy consensus in 72-hours (or some longer time
> period at your discretion). If you don't get any legitimate -1's by
> that point, or get other insights that make you want to reconsider
> your proposal, then do it.
>
> 3) Those who comment on the proposals should try to respect the
> meaning of +1 and -1 and use fractional values to express intermediate
> positions. They should also consider saying nothing. "Silence is
> consent". You might have what seems to you to be a brilliant insight.
> But is it really so important that you should distract us all with it
> right now? Does it really matter. Does it matter enough to hold back
> the progress of migration, or can we deal with it later? (I'm as
> guilty of this as anyone)
>
> Regards,
>
> -Rob
>
>
> [1] http://www.apache.org/foundation/voting.html
>