Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9140771356016499359@unknownmsgid>
References: <504A3FC8.3040804@oracle.com>
	<9140771356016499359@unknownmsgid>
Date: Sat, 8 Sep 2012 03:35:56 +0100
Message-ID: 
 <CAOGo0Va0hY0wRTgoi3G0gd5zm-=GJv0hb9C47d54VUSW=jdVuA@mail.gmail.com>
Subject: Re: What is a good Project Management Committee?
From: sebb <sebbaz@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 7 September 2012 22:26, Rob Weir <rabastus@gmail.com> wrote:
> On Sep 7, 2012, at 8:42 AM, Andrew Rist <andrew.rist@oracle.com> wrote:
>
>> I'm not particularly satisfied with current PMC selection process. I thi=
nk the first pass was actually fairly reasonable, and fairly quickly result=
ed in a list that contains the people who are serious about the project.  U=
nfortunately, we haven't been able to find consensus on the next step.  I'd=
 like to propose a different way to look at this which may lead us to a bet=
ter way to move forward.   I think we can avoid the need to organize the ne=
xt step around '-1' (i.e. speaking out against potential PMC members - disc=
ussions around who to leave off), and instead create an affirmative process=
 where we identify who we want on.
>>
>> What is a good Project Management Committee?
>> Here's my start (please expand on this):
>>
>> * Representative of the diversity of tasks in the community
>>   (developers, web/wiki/forum, translators, testers, UX, release,
>>   marketing, press, ecosystem, infrastructure)
>> * Representative of the geographical diversity in the community
>> * Made up of the most involved members of the community
>> * Able and Competent to perform required ASF functions (overseeing
>>   releases and developing the community)
>> * Represents the community in the best possible light
>>
>> While on one hand I understand why so many of us want to be on the PMC, =
a large PMC is not necessarily in the best interest of the project.   The P=
MC should not be making decisions about the direction of the project and on=
 who gets to do what - the PMC should be mostly involved with voting in new=
 committers and approving releases.  The direction of the project should be=
 determined on ooo-dev, and by the people who are active in the parts of th=
e community listed above.
>>
>>
>> My Proposal for the next step in the PMC selection process:
>> I suggest that each of us provide up to 10 names for the PMC.  no spread=
sheet - no voting - no '-1s' for now.  Just an affirmative list of the 10 p=
eople you think should be doing the work of the PMC.  (the list of names we=
 have produced so far is a great place to start for your list, but it is no=
t exclusive) Anyone can play! PPMC members, committers, the community.   Ne=
xt we use this to produce a list of the group getting the most votes. (usin=
g PPMC and committer lists as more binding)   We can use this to produce th=
e next pass at the proposed PMC roster, hopefully a PMC of around 20 member=
s.
>>
>
> Interesting idea. Another way of keeping it small and focused would be
> to rotate all committers in over time, say 20 at a time for 6 months
> at a time. Everyone gets a turn, no one left out and power does not
> concentrate.

Note that PMC additions and removals require board approval (currently
via ACK request/reply and 72hr wait).
AIUI this is because the board delegates certain responsibilities to
the PMC, so the board must be involved.
Also there is a file (committee-info.txt) and LDAP group that need to
be maintained.

=3D=3D

PMC members have binding votes on releases (and can vote new
committers/PMC members), but otherwise don't have any additional
powers compared with committers.

I'm not sure I understand why a large PMC would be a problem, so I
don't see why rotation should be desirable.
AFAIK rotation does not happen in any existing TLP.

=3D=3D

Podlings with smaller numbers of committers tend to graduate with a
PMC consisting of all the still active committers, but there is no
requirement for all TLP committers to be PMC members.

Some TLPs automatically add new committers to the PMC, but some wait
until the committer has been around for a while to prove themselves -
no point adding someone to the PMC who is not going to stick around.
[In the latter case there may be a lower barrier to inviting someone
to committership.]