Consensus Building (was Re: Bootstrapping Rave code: choice of build engine)

[Ross Gardler <rg...@apache.org>]

Every now and again I'll put my mentor hat on and attempt to communicate 
some of the "good practice" stuff I've seen in other ASF projects. 
Here's one such post on consensus building.

# Making Decisions

In ASF projects we don't like to vote. We reserve that for things that 
need official approval for legal or process reasons (e.g. a release, a 
new committer). Most of the time we work with consensus building.

## Lazy Consensus

What this means is that if you are convinced you know what the 
communities consensus on an issue is you just assume that you already 
have consensus and get on with the work. This is called "lazy 
consensus." You don't have to call a vote to get approval you just 
assume you have it unless someone says otherwise.

We have a time machine (SVN) so as long as you commit early and often 
the community has plenty of opportunity to indicate that they do not 
agree with the approach. When you believe you can operate on lazy 
consensus just get on with it, but be prepared to roll back work if a 
valid objection is raised.

The key thing about lazy consensus is that it's easier for people to 
agree by doing nothing than it is for them to object by providing an 
alternative. This has two effects, firstly people are less likely to 
object just for the sake of it and secondly it cuts down on the amount 
of unnecessary traffic.

Lazy consensus stops us waiting for a decision before proceeding. 
However, it does require everyone who cares to watch what is happening. 
Objecting to 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 checking on our work.

People may choose to indicate their support for the actions taken with a 
+1 mail - quick and easy to read and reassuring for the implementer, 
However, remember, in a lazy consensus world silence is support, noise 
is objection.

## Consensus Building

In some cases there is no obvious path to take, or you might be a new 
community, or a new member of an existing community. In these cases 
people will often need to build consensus by making proposals and 
eliciting responses. This is just fine too.

The confusing thing in the ASF is that some people (like me) when given 
one or more options will use the same notation to indicate their 
preferences as they would use in a formal vote. Knowing when something 
is a vote and when it is a preference is important. It's easy to tell 
though, if the subject does not have "[Vote]" at the start then it's 
just an opinion.

The notation used is "+1", "-1" and "0". It's also common to see "+0" 
and "-0".

So, what do these notations mean?

+1 means "I agree with this and will help make it happen"

+0 means "I agree with this but probably won't make it happen, so my 
opinion is not that important"

-0 means "I don't agree with this, but I'm offering no alternative so my 
opinion is not that important"

-1 means "I don't agree and I am offering an alternative that I am able 
to help implement"

Many people will use fractions to indicate the strength of their 
feelings, e.g. "+0.5". Some will even indicate this is a "no brainer" 
with something like "+1000".

The important thing is that this is not an exact science. It's just a 
shorthand way of communicating strength of feeling.

Not everyone does this, but I do. the reasons I like it is because when 
someone wants to summarise a thread discussing the proposal they can 
mentally add up the strength of feeling of the community and decide if 
there is consensus.

Once there is a consensus building people can proceed with the work 
under the lazy consensus model.

## Stating Lazy Consensus

Sometimes you will believe a specific action to be the correct one for 
the community but are not sure enough to proceed with the work under the 
lazy consensus model. In these circumstances you can state Lazy 
Consensus is in operation.

What this means is that you make a proposal and state that you will 
start implementing it in 72hours unless someone objects.

In this approach you are not requiring people to explicitly support your 
actions but are still allowing space for objections and corrections to 
the proposal. Again, most people are happy for you to do their work for 
them and thus in many cases there will be no objection.

People may choose to indicate their willingness to help implement the 
proposal with a +1 mail - quick and easy to read and reassuring for the 
proposer, However, remember, in a lazy consensus world silence is 
support, noise is objection.

## Voting

Very occasionally a "feel" for consensus is not enough. Sometimes we 
need to have a measurable consensus. For example, when voting in new 
committers or releases. We use the same system of notation for this. the 
only difference is you can't use fractions or "+/-0".

In a vote things mean:

+1 - yes I agree
  0 - I have no strong opinion
-1 - I object on the following grounds

If you object you must support your objection and provide an alternative 
course of action that you are willing and able to implement (where 
appropriate).

## Putting it to the test

I propose making this a "good practice" guide for the Rave project. I 
stress is different from a required behaviour - individuals will find 
their own way, but I suggest this practice has been shown to work in a 
great many ASF projects and thus is a model I will be using here.

If nobody objects in the next 72 hours or so I will put an (edited) 
version of this mail on your website on a "consensus building" page.

Ross

On 07/04/2011 10:36, Ross Gardler wrote:
> My preference is Ant/Ivy (maybe EasyAnt not used that yet). It is much more flexible than Maven (or is that just because I know I well).   But...
>
> I do not object to Maven as long as someone else is available to maintain it and use it properly. I can maintain Ant, I need to learn about Maven.
>
> So,
> -0 Maven
> +0 Ant + Ivy (EasyAnt?)
>
> Ross
>
> Sent from my mobile device.
>
> On 7 Apr 2011, at 09:50, Ate Douma<at...@douma.nu>  wrote:
>
>> As we're about to bootstrap the new Rave code base, it would be good to decide now what build engine we will use. This choice will have impact on how we structure and configure our source tree, build, test and integration environments.
>>
>> As a Java based project I think we have three options:
>> - Ant
>> - Ant/Ivy
>> - Maven
>>
>> OSEC is Ant based, OGCE, SURFNet and Shindig are Maven based, Wookie uses Ant/Ivy.
>>
>> I have a strong preference to use Maven as I'm using that for almost every other project already and IMO has nowadays the strongest (automated) ASF infrastructure support. But for those not accustomed to Maven this might require some learning curve to get used to as Maven does have specific restrictions and requirements, not the least concerning structure and layout of the source tree itself.
>>
>> So I'd like to hear the preference of the other developers.
>> If Ant or Ant/Ivy turns out to have the biggest support, I'm fine with that as well.
>>
>> Ate

Re: Consensus Building (was Re: Bootstrapping Rave code: choice of build engine)

[Hadrian Zbarcea <hz...@gmail.com>]

+1 on Maven
+1 on the Good Practice guide.

Thanks Ross :),
Hadrian

On Apr 7, 2011, at 6:36 AM, Ross Gardler wrote:

> Every now and again I'll put my mentor hat on and attempt to communicate some of the "good practice" stuff I've seen in other ASF projects. Here's one such post on consensus building.
> 
> # Making Decisions
> 
> In ASF projects we don't like to vote. We reserve that for things that need official approval for legal or process reasons (e.g. a release, a new committer). Most of the time we work with consensus building.
> 
> ## Lazy Consensus
> 
> What this means is that if you are convinced you know what the communities consensus on an issue is you just assume that you already have consensus and get on with the work. This is called "lazy consensus." You don't have to call a vote to get approval you just assume you have it unless someone says otherwise.
> 
> We have a time machine (SVN) so as long as you commit early and often the community has plenty of opportunity to indicate that they do not agree with the approach. When you believe you can operate on lazy consensus just get on with it, but be prepared to roll back work if a valid objection is raised.
> 
> The key thing about lazy consensus is that it's easier for people to agree by doing nothing than it is for them to object by providing an alternative. This has two effects, firstly people are less likely to object just for the sake of it and secondly it cuts down on the amount of unnecessary traffic.
> 
> Lazy consensus stops us waiting for a decision before proceeding. However, it does require everyone who cares to watch what is happening. Objecting to 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 checking on our work.
> 
> People may choose to indicate their support for the actions taken with a +1 mail - quick and easy to read and reassuring for the implementer, However, remember, in a lazy consensus world silence is support, noise is objection.
> 
> ## Consensus Building
> 
> In some cases there is no obvious path to take, or you might be a new community, or a new member of an existing community. In these cases people will often need to build consensus by making proposals and eliciting responses. This is just fine too.
> 
> The confusing thing in the ASF is that some people (like me) when given one or more options will use the same notation to indicate their preferences as they would use in a formal vote. Knowing when something is a vote and when it is a preference is important. It's easy to tell though, if the subject does not have "[Vote]" at the start then it's just an opinion.
> 
> The notation used is "+1", "-1" and "0". It's also common to see "+0" and "-0".
> 
> So, what do these notations mean?
> 
> +1 means "I agree with this and will help make it happen"
> 
> +0 means "I agree with this but probably won't make it happen, so my opinion is not that important"
> 
> -0 means "I don't agree with this, but I'm offering no alternative so my opinion is not that important"
> 
> -1 means "I don't agree and I am offering an alternative that I am able to help implement"
> 
> Many people will use fractions to indicate the strength of their feelings, e.g. "+0.5". Some will even indicate this is a "no brainer" with something like "+1000".
> 
> The important thing is that this is not an exact science. It's just a shorthand way of communicating strength of feeling.
> 
> Not everyone does this, but I do. the reasons I like it is because when someone wants to summarise a thread discussing the proposal they can mentally add up the strength of feeling of the community and decide if there is consensus.
> 
> Once there is a consensus building people can proceed with the work under the lazy consensus model.
> 
> ## Stating Lazy Consensus
> 
> Sometimes you will believe a specific action to be the correct one for the community but are not sure enough to proceed with the work under the lazy consensus model. In these circumstances you can state Lazy Consensus is in operation.
> 
> What this means is that you make a proposal and state that you will start implementing it in 72hours unless someone objects.
> 
> In this approach you are not requiring people to explicitly support your actions but are still allowing space for objections and corrections to the proposal. Again, most people are happy for you to do their work for them and thus in many cases there will be no objection.
> 
> People may choose to indicate their willingness to help implement the proposal with a +1 mail - quick and easy to read and reassuring for the proposer, However, remember, in a lazy consensus world silence is support, noise is objection.
> 
> ## Voting
> 
> Very occasionally a "feel" for consensus is not enough. Sometimes we need to have a measurable consensus. For example, when voting in new committers or releases. We use the same system of notation for this. the only difference is you can't use fractions or "+/-0".
> 
> In a vote things mean:
> 
> +1 - yes I agree
> 0 - I have no strong opinion
> -1 - I object on the following grounds
> 
> If you object you must support your objection and provide an alternative course of action that you are willing and able to implement (where appropriate).
> 
> ## Putting it to the test
> 
> I propose making this a "good practice" guide for the Rave project. I stress is different from a required behaviour - individuals will find their own way, but I suggest this practice has been shown to work in a great many ASF projects and thus is a model I will be using here.
> 
> If nobody objects in the next 72 hours or so I will put an (edited) version of this mail on your website on a "consensus building" page.
> 
> Ross
> 
> On 07/04/2011 10:36, Ross Gardler wrote:
>> My preference is Ant/Ivy (maybe EasyAnt not used that yet). It is much more flexible than Maven (or is that just because I know I well).   But...
>> 
>> I do not object to Maven as long as someone else is available to maintain it and use it properly. I can maintain Ant, I need to learn about Maven.
>> 
>> So,
>> -0 Maven
>> +0 Ant + Ivy (EasyAnt?)
>> 
>> Ross
>> 
>> Sent from my mobile device.
>> 
>> On 7 Apr 2011, at 09:50, Ate Douma<at...@douma.nu>  wrote:
>> 
>>> As we're about to bootstrap the new Rave code base, it would be good to decide now what build engine we will use. This choice will have impact on how we structure and configure our source tree, build, test and integration environments.
>>> 
>>> As a Java based project I think we have three options:
>>> - Ant
>>> - Ant/Ivy
>>> - Maven
>>> 
>>> OSEC is Ant based, OGCE, SURFNet and Shindig are Maven based, Wookie uses Ant/Ivy.
>>> 
>>> I have a strong preference to use Maven as I'm using that for almost every other project already and IMO has nowadays the strongest (automated) ASF infrastructure support. But for those not accustomed to Maven this might require some learning curve to get used to as Maven does have specific restrictions and requirements, not the least concerning structure and layout of the source tree itself.
>>> 
>>> So I'd like to hear the preference of the other developers.
>>> If Ant or Ant/Ivy turns out to have the biggest support, I'm fine with that as well.
>>> 
>>> Ate
> 

Re: Consensus Building (was Re: Bootstrapping Rave code: choice of build engine)

["Franklin, Matthew B." <mf...@mitre.org>]

On 4/7/11 6:36 AM, "Ross Gardler" <rg...@apache.org> wrote:

>Every now and again I'll put my mentor hat on and attempt to communicate
>some of the "good practice" stuff I've seen in other ASF projects.
>Here's one such post on consensus building.
>
># Making Decisions
>
>In ASF projects we don't like to vote. We reserve that for things that
>need official approval for legal or process reasons (e.g. a release, a
>new committer). Most of the time we work with consensus building.
>
>## Lazy Consensus
>
>What this means is that if you are convinced you know what the
>communities consensus on an issue is you just assume that you already
>have consensus and get on with the work. This is called "lazy
>consensus." You don't have to call a vote to get approval you just
>assume you have it unless someone says otherwise.
>
>We have a time machine (SVN) so as long as you commit early and often
>the community has plenty of opportunity to indicate that they do not
>agree with the approach. When you believe you can operate on lazy
>consensus just get on with it, but be prepared to roll back work if a
>valid objection is raised.
>
>The key thing about lazy consensus is that it's easier for people to
>agree by doing nothing than it is for them to object by providing an
>alternative. This has two effects, firstly people are less likely to
>object just for the sake of it and secondly it cuts down on the amount
>of unnecessary traffic.
>
>Lazy consensus stops us waiting for a decision before proceeding.
>However, it does require everyone who cares to watch what is happening.
>Objecting to 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 checking on our work.
>
>People may choose to indicate their support for the actions taken with a
>+1 mail - quick and easy to read and reassuring for the implementer,
>However, remember, in a lazy consensus world silence is support, noise
>is objection.
>
>## Consensus Building
>
>In some cases there is no obvious path to take, or you might be a new
>community, or a new member of an existing community. In these cases
>people will often need to build consensus by making proposals and
>eliciting responses. This is just fine too.
>
>The confusing thing in the ASF is that some people (like me) when given
>one or more options will use the same notation to indicate their
>preferences as they would use in a formal vote. Knowing when something
>is a vote and when it is a preference is important. It's easy to tell
>though, if the subject does not have "[Vote]" at the start then it's
>just an opinion.
>
>The notation used is "+1", "-1" and "0". It's also common to see "+0"
>and "-0".
>
>So, what do these notations mean?
>
>+1 means "I agree with this and will help make it happen"
>
>+0 means "I agree with this but probably won't make it happen, so my
>opinion is not that important"
>
>-0 means "I don't agree with this, but I'm offering no alternative so my
>opinion is not that important"
>
>-1 means "I don't agree and I am offering an alternative that I am able
>to help implement"
>
>Many people will use fractions to indicate the strength of their
>feelings, e.g. "+0.5". Some will even indicate this is a "no brainer"
>with something like "+1000".
>
>The important thing is that this is not an exact science. It's just a
>shorthand way of communicating strength of feeling.
>
>Not everyone does this, but I do. the reasons I like it is because when
>someone wants to summarise a thread discussing the proposal they can
>mentally add up the strength of feeling of the community and decide if
>there is consensus.
>
>Once there is a consensus building people can proceed with the work
>under the lazy consensus model.
>
>## Stating Lazy Consensus
>
>Sometimes you will believe a specific action to be the correct one for
>the community but are not sure enough to proceed with the work under the
>lazy consensus model. In these circumstances you can state Lazy
>Consensus is in operation.
>
>What this means is that you make a proposal and state that you will
>start implementing it in 72hours unless someone objects.
>
>In this approach you are not requiring people to explicitly support your
>actions but are still allowing space for objections and corrections to
>the proposal. Again, most people are happy for you to do their work for
>them and thus in many cases there will be no objection.
>
>People may choose to indicate their willingness to help implement the
>proposal with a +1 mail - quick and easy to read and reassuring for the
>proposer, However, remember, in a lazy consensus world silence is
>support, noise is objection.
>
>## Voting
>
>Very occasionally a "feel" for consensus is not enough. Sometimes we
>need to have a measurable consensus. For example, when voting in new
>committers or releases. We use the same system of notation for this. the
>only difference is you can't use fractions or "+/-0".
>
>In a vote things mean:
>
>+1 - yes I agree
>  0 - I have no strong opinion
>-1 - I object on the following grounds
>
>If you object you must support your objection and provide an alternative
>course of action that you are willing and able to implement (where
>appropriate).
>
>## Putting it to the test
>
>I propose making this a "good practice" guide for the Rave project. I
>stress is different from a required behaviour - individuals will find
>their own way, but I suggest this practice has been shown to work in a
>great many ASF projects and thus is a model I will be using here.
>
>If nobody objects in the next 72 hours or so I will put an (edited)
>version of this mail on your website on a "consensus building" page.

+1 

-Matt


>
>Ross
>
>On 07/04/2011 10:36, Ross Gardler wrote:
>> My preference is Ant/Ivy (maybe EasyAnt not used that yet). It is much
>>more flexible than Maven (or is that just because I know I well).
>>But...
>>
>> I do not object to Maven as long as someone else is available to
>>maintain it and use it properly. I can maintain Ant, I need to learn
>>about Maven.
>>
>> So,
>> -0 Maven
>> +0 Ant + Ivy (EasyAnt?)
>>
>> Ross
>>
>> Sent from my mobile device.
>>
>> On 7 Apr 2011, at 09:50, Ate Douma<at...@douma.nu>  wrote:
>>
>>> As we're about to bootstrap the new Rave code base, it would be good
>>>to decide now what build engine we will use. This choice will have
>>>impact on how we structure and configure our source tree, build, test
>>>and integration environments.
>>>
>>> As a Java based project I think we have three options:
>>> - Ant
>>> - Ant/Ivy
>>> - Maven
>>>
>>> OSEC is Ant based, OGCE, SURFNet and Shindig are Maven based, Wookie
>>>uses Ant/Ivy.
>>>
>>> I have a strong preference to use Maven as I'm using that for almost
>>>every other project already and IMO has nowadays the strongest
>>>(automated) ASF infrastructure support. But for those not accustomed to
>>>Maven this might require some learning curve to get used to as Maven
>>>does have specific restrictions and requirements, not the least
>>>concerning structure and layout of the source tree itself.
>>>
>>> So I'd like to hear the preference of the other developers.
>>> If Ant or Ant/Ivy turns out to have the biggest support, I'm fine with
>>>that as well.
>>>
>>> Ate
>