On Jul 12, 2009, at 8:29 PM, David Blevins wrote:
This is a fantastic thread; great to clarify if there are doubts and
great opportunity to learn how various projects at Apache operate.
We can definitely put this up in the wiki.
Q. Do the terms of http://www.apache.org/dev/pmc.html forbid
projects from discussing "nominees for project, project committee or
Foundation membership" in public?
Not according to Ant, WebServices, Cocoon, Tapestry, Tomcat, and a
handful of other Apache projects that discuss and vote on committers
on dev@ and have been doing so with ASF Board knowledge for years.
It seems that particular section is more about giving projects a
list of things that are OK to be discussed privately as many
projects have had a problems being too closed and discussing too
many things on private lists that should not be there.
Agreed. And that's certainly in keeping with my history with Apache.
My interpretation of the PMC Guide seems to be in sync with yours...
We're likely the first project to take it to the level of "project
committee", but hopefully not the last :)
Q. Whose votes count?
Apache requires a minimum of three +1 PMC votes which have legal
significance to Apache as a corporation. That said, all votes from
the community are significant to the project and decision making and
any -1 is cause for pause and discussion. We frequently encourage
and welcome votes from anyone in the community regardless of status.
One clarification -- release votes require a minimum of 3 +1 votes
(and majority of +1 votes). Non-release votes are simple majority. In
my experience, the vast majority of votes are unanimous (or at least
without dissenting -1 votes). This is usually because, as you discuss
below, consensus has already been established.
Q. Voting on people: Is it hard to vote -1 in public / Can someone
get their feelings hurt ?
Yes and yes. Voting in public requires greater care and sensitivity
on behalf of everyone; the vote proposer, the voters, and the
votee. Prior to voting the proposer should create several
opportunities for feedback, hopefully positive and constructive.
Community members with concerns should get involved early and
actively mentor potential committers, taking opportunities for
feedback as queues to get involved, encourage, and work through
areas where they see said person needs more help. The contributor
should actively solicit and welcome all help and feedback and
encouragement and feel welcome to give it in return. Do not rush;
all parties (proposer, voters, and votee) have work to do in
grooming contributors, etc., and that work takes time. Votes that
result in one or more -1s should not be seen as a failure of any one
individual and instead be seen as an opportunity for all parties
(proposer, voters, and votee) to make improvements, be more active,
and give the process more time.
Ok, so I *think* that's all the open topics. If it isn't missing
anything major and generally captures the ideas of the group, I'll
throw it into the wiki and people can go in and make any wording
tweaks they like as well as any other cleanup. I'll give it a while
for lazy consensus before doing so.
One final note -- all community members should be encouraged to
provide legal oversight for a project, not just PMC members. Only
difference is that it is *expected* from PMC members.
--kevan
