On 3/20/15 9:04 PM, Pierre Smits wrote: > Hi all, > > If I understand the various documents/pages available regarding voting > correctly, voting a new member in can't be vetoed. Likewise is it with > respect to voting for board members. If I have missed a page somewhere, > please point me to it and I stand corrected.
Board and new Member voting at the Foundation level are clearly documented - note that these are specific procedures that are *different* from best practices for PMC voting on new committers. https://wiki.apache.org/general/MemberVoting https://wiki.apache.org/general/BoardVoting In particular since the Board voting process uses STV there are only positive votes, no negative votes for candidates (obviously, you can withhold voting from some candidates). > > The following document https://community.apache.org/newcommitter.html > states: That also notes at the top: "Each project has different approaches to managing new committers, this page describes a common process found in many Apache projects" It is important to have best practices for all projects, and for projects to document their own specific ways to make decisions. But the bigger point is to work towards a consensus among the active contributing PMC members and/or committers within a project. In many cases, a key way to make this a smoother process is ensuring you hold a [DISCUSS] thread about "hey, I'm thinking of nominating X for committer" first. IF there are objections during the discussion that some people can clearly explain, you usually put things on hold for a period to see if whatever is being objected too can be corrected. - Shane > > A positive result is achieved by Consensus Approval i.e. at least 3 +1 > votes and no vetoes. > > Any veto must be accompanied by reasoning and be prepared to defend it. > Other members can attempt to encourage them to change. > > While this document talks about getting new committers in a project, it > also seem to be applicable when it comes to getting new PMC members and > even who chairs the PMC. > > So how can it be that when it comes to projects, vetoes can be expressed > and block innovation or growth? > One of the reasons I heard when discussing this was that it establishes > control or manageability of the projects member list. > > Wouldn't a simple majority (more +1 than -1 votes) yield the same result? > If someone would feel that non-acceptance of a new person would benefit the > project, wouldn’t it be more proper/righteous that he should put in the > effort and get a majority of votes? > > It is understandable why the ASF (and its projects) have the veto principle > regarding code changes as it ensures that the(released) works of the > project are of a higher quality than the previous work, and that the works > don't change to something else than what is stated in the mission of the > project (meaning that e.g. the primary work of the Apache HTTP project - > httpd can't be converted into e.g. foo widget). > When it comes to people (and organisations), vetoes have proven that it is > a means to force consensus into a certain direction. It might have some > valid grounds when only a few have the biggest gun and they want to keep > others from getting the same gun (and thus rights/power), but in a > environment (as the ASF is) that builds on collaboration it is seems > overkill. > > What do you think? Is, when it comes to people, the veto mechanism not out > of place for an ASF project? > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com >
