Just a review of the way we vote (like Apache) on decisions that need to be made. Vote have two purposes: (a) make a decision and (b) stimulate disucssion on complex issues.
First I will review how I have seen Apache (Pluto in particular) operate.
In Apache only committer votes count.
In practice in Apache – generally the trend is toward forward progress. Working code that does not break stuff is generally allowed to move forward. When a proposal is voted down – usually it means something is “broken” or will break something. Generally when something is shown or discovered to be broken or is a generally bad idea, the proposers don’t even wait for more -1 votes – they simply withdraw the proposal and go back and fix what they have.
In the case where there is one or a small number of -1 votes – there is generally four cases: (1) there is really something wrong that is quickly relaized by the whole goup in short disucssion and the proposal is withdrawn, (2) it turns out to be a misunderstanding or something that a quick discussion resolves and the -1 vote turns to a +1, (3) there is some technical ickiness in the approach – the -1 voter volunteers to quickly help fix the problem in a week or so, or (4) it is an interesting opinion from someone not really in the mainstream and after some examination – it is ignored and things move forward.
In Sakai, this is the rough procedure:
If it comes down to a “count” – the votes that “count” are the folks with long-term commitment to the particular element in question.
In Sakai the “project team” is more than just developers – it includes designers, usability experts, developers, etc. The key is that the counted vote is amongst the people with a history of and plans to continue directly working on the particular part of Sakai that is being discussed.
Any one in the community is very much encouraged to vote and comment and the project team of the element in question are encouraged to listen to and strongly consider the community votes.
Negative votes should include what it would take to make the vote positive.
It is the responsibility of the project lead and project team for the component to evaluate the votes/comments, etc and make the “wise” choice given the discussion.
Summary
We want more votes to happen and more exploratory development to happen in branches with votes before the merge. This gives the community a better chance of catching things that might destabilize the product or cause harm in other ways.
This approach is designed to give project teams a safe way to have discussion about issues and get community input while maintaining the project team’s control over their own destiny.
Without the rule that the project team gets the final say, it tacitly encourages project teams to quietly make their changes in trunk and then we all get surprised at release time.
We have a number of examples in our past history of these “trunk release surprises” – they are not so much fun – because we are faced with the decision “do we keep the flawed stuff we have in trunk – or go way back and lose all the neat new features”.
So to encourage open discussion it is important to remember that people outside the project team do not have veto power with a single negative vote.
Folks who want things done differently should get involved in producing the solutions to problems – not just sending out -1 votes when a vote call is being done.
We have to remember tht project teams often spend weeks or months of work to get something working well enough in a branch to propose a vote. When the work is complete and being voted on – it can be very costly to delay the merge of the work significantly because as time passes the merge becomes harder and harder. So we need to make sure that we have a solid reason to tell a project team to “go back to the drawing board”.