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<[email protected]> 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
