On 7 September 2012 22:26, Rob Weir <[email protected]> wrote: > On Sep 7, 2012, at 8:42 AM, Andrew Rist <[email protected]> wrote: > >> I'm not particularly satisfied with current PMC selection process. I think >> the first pass was actually fairly reasonable, and fairly quickly resulted >> in a list that contains the people who are serious about the project. >> Unfortunately, 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 >> better way to move forward. I think we can avoid the need to organize the >> next step around '-1' (i.e. speaking out against potential PMC members - >> discussions 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 PMC >> 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 the >> 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 >> spreadsheet - no voting - no '-1s' for now. Just an affirmative list of the >> 10 people 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 >> not exclusive) Anyone can play! PPMC members, committers, the community. >> Next we use this to produce a list of the group getting the most votes. >> (using PPMC and committer lists as more binding) We can use this to >> produce the next pass at the proposed PMC roster, hopefully a PMC of around >> 20 members. >> > > 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. == 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. == 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.]
