On 4/7/11 6:36 AM, "Ross Gardler" <[email protected]> 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<[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 >
