Voting processes (was: PMC meeting agenda)

[Sam Ruby <ru...@us.ibm.com>]

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

Re: Voting processes (was: PMC meeting agenda)

[Ted Husted <ne...@husted.com>]

> > 3) Committers nominate/Committers vote  (most open option)

+1

Especially if we make this active committers (wrote to a CVS in the last
six months).

Then the PMC members elect the chair, and any other offices within the
PMC.

It would be important is that anyone nominated for the PMC affirm their
nomination before a vote, since accepting the role means accepting
additional demands on your time.

Sam Ruby wrote:
> 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.

I believe any Jakarta-level voting should revolve around "one committer,
one vote". 

Personally, I don't see that technical familiarity with a codebase is an
issue. The primary role of the PMC is to ensure each subproject "stays
within the bounds of the law". The technical decisions are specifically
left to the committers for each subproject, and Roy specially reiterated
that the PMC itself is not to make technical decisions. We're just the
suits ;-), and should leave the engineering to the engineers closest to 
the problem.

-Ted.

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

Re: Voting processes (was: PMC meeting agenda)

[Peter Donald <do...@apache.org>]

At 07:00  12/3/01 -0500, Sam Ruby wrote:
>The ASF board is completely re-elected on an annual basis.  Members
>nominate/Members vote.  This is probably the system I most lean towards,

me too ;)

>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.

"wisest" == popular ??? ;)

>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?

Interesting approach. Each project elects a "champion" for their cause. It
is nice until we look at the "bigger" projects - I guess a good example
being tomcat. Tomcat has a lot of dedicated developers a lot of whom have
strong ideas. In these cases it may be difficult to elect one-single
champion - not sure. Then there are other projects that barely make 3
committers and are less active. Should they receive equal 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?

I kinda like the idea but it would be difficult to implement. A while back
I remember visiting a site that allowed anybody to register. Registrants
could then vote for other members. The more votes a person had the more
karma they got and the more seriously their votes were taken. You could go
to summary page that listed who voted for each person and how strongly etc.
I think this would make the appointment largely self-managing.
Unfortunately it would require work to set up such a system ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


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