+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<[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 >
