jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Voting processes (was: PMC meeting agenda)
Date Mon, 12 Mar 2001 12:00:58 GMT
Ceki Gülcü wrote:
> I can see only 4 possibilities:
> 1) PMC  nominates/PMC votes (as done currently)
> 2) Committers nominate/PMC votes (seems me worst of two
>    worlds)
> 3) Committers nominate/Committers vote  (most open
>    option)
> 4) PMC nominates/Committers vote (sounds a bit like an
>    unnamed country where a Religious Counsel of Sages
>    decides if a given candidate is sufficiently loyal
>    to the state religion although the Jakarta PMC does
>    not decide on the fate of a whole nation)

A few more elements to make the set of possible permutations run wild...
subprojects and subscribers.  And a few sub-variations: polls cast in
public (like the recent PMC vote) or in private and tallied by a trusted
third party.

And I can argue for or against each of the systems I have seen.

The ASF board is completely re-elected on an annual basis.  Members
nominate/Members vote.  This is probably the system I most lean towards,
but it does have one problem: while it may elect the "wisest" people, it
does not guarantee that the people elected have any familiarity with the
issues surrounding your particular code base.

Scott Boag of Xalan fame advocates another scheme: one subproject, one
vote.  While it certainly addresses the above issue, it raises a number of
questions.  Is servletapi a separate subproject?  How about servletapi-4?
How many projects is taglibs?  When avalon split, it didn't acquire any
more code or new committers: does it suddenly deserve more representation?

The current PMC process does feel a bit "closed", but it does mimic the
current process by which one becomes a committer or a member.  Should
committers be re-elected?  Should developers that are not committers be
able to nominate and elect new committers?

A few things to think about...

- Sam Ruby

To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

View raw message