cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Discuss changing the project bylaws for the PMC Chair voting process
Date Mon, 25 Feb 2013 17:36:36 GMT
On Mon, Feb 25, 2013 at 11:58 AM, Chip Childers
<chip.childers@sungard.com> wrote:
> On Fri, Feb 22, 2013 at 04:23:41PM -0500, David Nalley wrote:
>> On Fri, Feb 22, 2013 at 3:29 PM, Chip Childers
>> <chip.childers@sungard.com> wrote:
>> > Hi all,
>> >
>> > Continuing the graduation discussion (you're going to see plenty of
>> > threads like this as we head down the road), the PPMC had a discussion
>> > around how to best select the name we would recommend to the ASF board
>> > to be our PMC chair.
>> >
>> > Currently, our bylaws [1] state that we would use the Single
>> > Transferable Vote method for this selection (see section 2.4.5).  In the
>> > thread on the private list, our mentors have suggested that we may want
>> > to reconsider this position.
>> >
>> > I'll admit that we have it in our bylaws, purely because I started with
>> > the Hadoop project's document as a starting point for our own.  I
>> > believe that the Hadoop folks probably have a very good reason for this
>> > approach, but perhaps it's not right for our community.
>> >
>> > I'm proposing the following change:
>> >
>> > CURRENT:
>> >
>> >   2.4.5. If the current chair of the PMC resigns, the PMC votes to
>> >   recommend a new chair using Single Transferable Vote (STV) voting.
>> >   See http://wiki.apache.org/general/BoardVoting for specifics. The
>> >   decision must be ratified by the Apache board.
>> >
>> > PROPOSED:
>> >
>> >   2.4.5. If the current chair of the PMC resigns, the PMC votes to
>> >   recommend a new chair using a lazy 2/3 majority voting method.
>> >   This vote would be held on the cloudstack-dev mail list, after a
>> >   discussion is held on the cloudstack-private list to nominate a
>> >   candidate for the role. The decision must be ratified by the Apache
>> >   board.
>> >
>> > This is the discussion thread to see if people have any opinions.  If we
>> > don't have any big concerns, I'll start a new VOTE thread to change the
>> > bylaws (using the rules in section 3.4.9 of the bylaws themselves).
>> >
>> > Thoughts?
>> >
>> > -chip
>> >
>> > [1] https://cwiki.apache.org/CLOUDSTACK/apache-cloudstack-project-bylaws.html
>>
>>
>>
>> So here are my thoughts:
>> 1. Chair is appointed by the board, generally upon recommendation of the PMC.
>
> True.  Even as a TLP, that remains the case.
>
>> 2. There is a high likelihood that we'll continue to grow and might at
>> some point have contention for the Chair, even if it is friendly.
>> Discussing people (IMO) should not happen in public. There's a reason
>> we already do that for committers in private. Think of some of those
>> conversations that we've already had that simply have no place in
>> private. And I know your proposal calls for discussion in private, and
>> vote in public but here's the thing:
>>
>> The decision is one for the PMC to make.
>> You're effectively 'voting' by nominating someone and pushing them
>> forward - which means the 'vote' will be more of voting theatre than a
>> real vote, and really more of a ratification of the decision made in
>> private.
>
> Yes, Sebastien made that point as well.  I fear I missed the mark with
> the specifics of this proposed change.
>
>> Additionally, only votes by the (P)PMC are binding, and
>> unlike technical discussions, it would be bad form to discuss people
>> in public. So I am personally struggling to see the benefit afforded
>> by 'voting' in public. You can disagree, but if there is dissent it
>> being public would potentially be deleterious to the person it is said
>> about.
>>
>> I can see doing away with STV (or only resorting to it if clear
>> consensus isn't achieved).
>
> I'd like to modify my proposed change, but I think we still have issues
> to discuss with this modification:
>
>  2.4.5. If the current chair of the PMC resigns, the PMC votes to
>  recommend a new chair using a lazy 2/3 majority voting method.
>  This vote would be held on the private mailing list, after a
>  discussion to nominate a candidate for the role. The decision must be
>  ratified by the Apache board.
>
> The problem I see with this new version, goes to the point you
> made about contention: What happens if the discussion doesn't lead to
> a single candidate?  Do we opt for STV as a backup process?  In that case,
> does it even make sense to have that lazy 2/3 majority statement above?
>

So STV has a lot of good things - but really seems (IMO) best suited
for large groups with multiple candidates, with multiple good choices.

> The issues we have to balance are (1) fairness, (2) being as open as
> possible, (3) respect for privacy for individuals.
>

STV does a good job of 1 and 3.
Lazy consensus does a decent job of 1 and a good job of 2.

> I'd also point out, as one of our mentors did in the private list
> discussion, that the chair role is largely an administrative one.
>
> And while we're at it, the private discussion brought up the idea of
> re-introducing a rotation (or at least a "term"), which would allow
> for a regular opportunity to recommend a change to the board.  I'm not
> sure that it's required, given the nature of the job...  but does anyone
> have an opinion?
>
> -chip

I'm personally 'meh' on this.
As you noted the role is largely an administrative role than fearful
power and authority; and I am inclined to have a person, particularly
if they are bearing the job well, to continue with it until such time
as they no longer wish to bear it.

I do understand the point that 'regular' rotation can provide the
perception of the project not being 'controlled' by a single entity.
>From inside the project, I don't see that, but perhaps outside the
project that is an important consideration.

--David

Mime
View raw message