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.
\nFirst I will review how I have seen Apache (Pluto in particular) operate.
\nIn Apache only committer votes count.
\nIn 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.
\nIn 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.
\nIn Sakai, this is the rough procedure:
\nIf it comes down to a “count” – the votes that “count” are the folks with long-term commitment to the particular element in question.
\nIn 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.
\nAny 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.
\nNegative votes should include what it would take to make the vote positive.
\nIt 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.
\nSummary
\nWe 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.
\nThis 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.
\nWithout 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.
\nWe 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”.
\nSo 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.
\nFolks 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.
\nWe 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”.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-337","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/comments?post=337"}],"version-history":[{"count":1,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/337\/revisions"}],"predecessor-version":[{"id":2420,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/337\/revisions\/2420"}],"wp:attachment":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/media?parent=337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/categories?post=337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/tags?post=337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}