You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2013/11/06 04:28:47 UTC
Project voting guidelines
Hi,
Despite Alex's efforts this seem to have stalled:
http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cCE743D6A.14A96%25aharui@adobe.com%3e
With a few voting issues coming up recently I think it time to consider having our own guidelines.
Here some I put together from other Apache projects in combination how we have been working as a project:
https://cwiki.apache.org/confluence/display/FLEX/Draft+Guidelines
Recent changes include:
- removed any mention of what defines an "active" committer or PMC member as it's controversial and can be easily gamed
- put in some expected (but not required) committer responsibilities
- filled in what are the default the voting rules
There are some difference from the "default" Apache guidelines
- Committers can veto checkins (seems a better match to me - not that there have been many veto's)
- Release candidate votes can be carry over to the next RC by a release manager if they so desire
- I also put the length of the Chair as a year with the option of them to stand for another year as that to me seem the fairest way to share that responsibility.
Feedback is welcome.
Thanks,
Justin
RE: Project voting guidelines
Posted by Gordon Smith <go...@adobe.com>.
If it's going to take a Lazy 2/3 Majority to change the rules, then I think it should take a Lazy 2/3 Majority to approve them in the first place.
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Tuesday, November 05, 2013 7:29 PM
To: dev@flex.apache.org
Subject: Project voting guidelines
Hi,
Despite Alex's efforts this seem to have stalled:
http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cCE743D6A.14A96%25aharui@adobe.com%3e
With a few voting issues coming up recently I think it time to consider having our own guidelines.
Here some I put together from other Apache projects in combination how we have been working as a project:
https://cwiki.apache.org/confluence/display/FLEX/Draft+Guidelines
Recent changes include:
- removed any mention of what defines an "active" committer or PMC member as it's controversial and can be easily gamed
- put in some expected (but not required) committer responsibilities
- filled in what are the default the voting rules
There are some difference from the "default" Apache guidelines
- Committers can veto checkins (seems a better match to me - not that there have been many veto's)
- Release candidate votes can be carry over to the next RC by a release manager if they so desire
- I also put the length of the Chair as a year with the option of them to stand for another year as that to me seem the fairest way to share that responsibility.
Feedback is welcome.
Thanks,
Justin
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 1. Do we really want to allow +0.5 or -0.5 etc.?
Yes as it allowed and people do vote that way.
> does two 0.5 votes make a +1 vote, does two -0.5 constitute a veto, etc
Answer is no to both. only -1 are a vert and only full +1 are counted when releasing:
"Only a -1 is considered a veto and releases require 3 full +1 votes."
Changing to this should make it clearer?
"Only a full -1 is considered a veto and releases require 3 full +1 votes."
> 2. We need to specify that the approval type (consensus vs. lazy vs. etc.)
> should be mentioned upfront when a VOTE thread starts.
Good point. I'll add something.
> And that it should not be changed in the middle of a VOTE series. We should probably have a
> default of Lazy Majority unless otherwise specified.
Default is generally Lazy Consensus but I guess how important is it.
> 3. That brings up the question of what determines the approval type? Do
> we need a set of guidelines to determine this? Or is it up to the person
> who starts the VOTE thread?
This is specified in the guideline for most common situations, voting in committers, PMC members etc etc, but there are going to be situations when it's not covered and in that case it would be up to the person starting the vote - unless someone objects to the voting method used I guess. If we get to the stage of having a vote to decide what voting system to use I think we're gone too far down the rabbit hole. :-)
> And I dont think a 2/3 majority of our PMC is possible.
It's possible, it a lazy majority eg it's 3 +1 votes and twice as many +1 votes as -1 votes.
Thanks,
Justin
Re: Project voting guidelines
Posted by OmPrakash Muppirala <bi...@gmail.com>.
A couple of things:
1. Do we really want to allow +0.5 or -0.5 etc.? This has a potential to
lead to confusion (does two 0.5 votes make a +1 vote, does two -0.5
constitute a veto, etc) We should probably eliminate this.
2. We need to specify that the approval type (consensus vs. lazy vs. etc.)
should be mentioned upfront when a VOTE thread starts. And that it should
not be changed in the middle of a VOTE series. We should probably have a
default of Lazy Majority unless otherwise specified.
3. That brings up the question of what determines the approval type? Do
we need a set of guidelines to determine this? Or is it up to the person
who starts the VOTE thread?
And I dont think a 2/3 majority of our PMC is possible. We rarely get so
many PMC members to participate in any VOTE thread. A lazy majority should
be good.
Thanks,
Om
On Wed, Nov 6, 2013 at 4:11 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> Anyone else? Do people think they are in a good enough start to start a
> VOTE? And would Lazy 2/3 majority of PMC members be the voting system to
> use?
>
> Thanks,
> Justin
Re: Project voting guidelines
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/13 11:53 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> And the only difference between this and voting.html is that we allow
>> committers to veto as well as PMC members?
>
>There's one or two other minor differences, for example:
>"However, the basic rule is that only PMC members have binding votes, and
>all others are either discouraged from voting (to keep the noise down) or
>else have their votes considered of an indicative or advisory nature
>only."
>
>Were as we have encouraged non binding voters to vote and in fact that
>something that may be considered in becoming a committer
I was just asking about the language around commit vetos. I know there
are (and should be) other differences like the "discouraged from voting"
language.
Thanks,
-Alex
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> And the only difference between this and voting.html is that we allow
> committers to veto as well as PMC members?
There's one or two other minor differences, for example:
"However, the basic rule is that only PMC members have binding votes, and all others are either discouraged from voting (to keep the noise down) or else have their votes considered of an indicative or advisory nature only."
Were as we have encouraged non binding voters to vote and in fact that something that may be considered in becoming a committer
Thanks,
Justin
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> And the only difference between this and voting.html
Well voting.html doesn't clearly explain what lazy consensus and review and commit actually means is practise ie changes are right away and stay until vetoed.
> is that we allow committers to veto as well as PMC members?
Yes that's is the main difference as voting.html states "Only votes by PMC members are considered binding on code-modification issues". I believe we're been under the assumption that it was committers and PMC members. I don't see any harm in it and in fact is seems useful to the project for a committer to be able to veto a check in. If enough people feel otherwise it can be changed.
Thanks,
Justin
Re: Project voting guidelines
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/13 11:17 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> It means that every commit is lazily approved by all the committers. If
>> someone has a problem with any commit, they have to explicitly veto it.
>
>I've also added that no formal vote need to be taken in this case,
>basically it's assumes the committer has voted +1 and it passes right
>away (commit then review) unless someone vetoes it.
And the only difference between this and voting.html is that we allow
committers to veto as well as PMC members?
-Alex
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It means that every commit is lazily approved by all the committers. If
> someone has a problem with any commit, they have to explicitly veto it.
I've also added that no formal vote need to be taken in this case, basically it's assumes the committer has voted +1 and it passes right away (commit then review) unless someone vetoes it.
Thanks,
Justin
Re: Project voting guidelines
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Nov 6, 2013 at 4:42 PM, Gordon Smith <go...@adobe.com> wrote:
> I don't understand this part:
>
> ---
> Code changes
>
> A change made to a codebase of the project and committed by a committer.
> This includes source code, documentation, website content, etc
>
> Lazy Consensus approval of committers.
> ---
>
> Are you talking about when there is a controversy over a code change?
>
> - Gordon
>
>
It means that every commit is lazily approved by all the committers. If
someone has a problem with any commit, they have to explicitly veto it.
Thanks,
Om
>
>
> -----Original Message-----
> From: Justin Mclean [mailto:justin@classsoftware.com]
> Sent: Wednesday, November 06, 2013 4:12 PM
> To: dev@flex.apache.org
> Subject: Re: Project voting guidelines
>
> Hi,
>
> Anyone else? Do people think they are in a good enough start to start a
> VOTE? And would Lazy 2/3 majority of PMC members be the voting system to
> use?
>
> Thanks,
> Justin
>
RE: Project voting guidelines
Posted by Gordon Smith <go...@adobe.com>.
I don't understand this part:
---
Code changes
A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc
Lazy Consensus approval of committers.
---
Are you talking about when there is a controversy over a code change?
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Wednesday, November 06, 2013 4:12 PM
To: dev@flex.apache.org
Subject: Re: Project voting guidelines
Hi,
Anyone else? Do people think they are in a good enough start to start a VOTE? And would Lazy 2/3 majority of PMC members be the voting system to use?
Thanks,
Justin
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The default should be the strictest (Consensus, if I have my
> terminology correct)
Changed. We can always revisit if votes start getting too few votes.
> Also, I think for releases and committers/PMC members, LAZY shouldn't
> be an option. If you can't find 3 votes, something is up ;-)
Agree and changed.
Thanks,
Justin
Re: Project voting guidelines
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Nope on the default to [LAZY]. When reading it I assumed that was the
technical term for the way we've been voting: at least 3 +1 and no -1.
My bad.
The default should be the strictest (Consensus, if I have my
terminology correct) and if someone wants to deviate, it should be
clearly marked in the subject of the vote email (i.e. with [LAZY]
added).
Also, I think for releases and committers/PMC members, LAZY shouldn't
be an option. If you can't find 3 votes, something is up ;-)
EdB
On Thu, Nov 7, 2013 at 7:04 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/6/13 9:32 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> I thought most votes to approve committers were consensus, not lazy
>>>consensus.
>>It varies but more lazy than not I believe. But no issue either way as
>>far as I'm concerned. We've not have a vote that's had less than 3 +1 so
>>it not been an issue, the last couple of votes I called were "Lazy" and
>>there were no comments about that.
> I didn't see [LAZY] in the vote subject so I didn't realize they were
> lazy. In the one lazy vote to approve a donation, I didn't get any +1
> votes. I want folks to realize that if they confirm the draft as written,
> we won't have results that show who and how many vote +1, we'll only know
> that nobody objected or somebody had the energy to vote +1. I'd rather we
> ask folks to vote one way or another when approving committers and pmc
> membership. Thoughts from others?
>
>>
>>> That seems to be the default for the HTTP project and what we've done
>>>in the past.
>>It's unclear what we done in the past because no one was sure of the
>>voting system in operation, but it's not been an issue (see above).
>>Serval other projects use lazy consensus for both committers and PMC eg
>>Hive, Pig, Ant, clouldstack and others. Clouldstack bylaws only have 3
>>types of voting not omit consensus.
>>
>>HTTP project also have a "or by not contributing in any form to the
>>project for over six months." clause as well, but that seems more
>>controversial here.
>>
>>Basically each project is slightly different is the only conclusion you
>>can come to.
> Yes, but supposedly, HTTP project is the default unless I can ever get new
> language approved for Voting.html. There's been way too much noise on
> board@ and members@ so I haven't pushed the issue on incubator because I
> think folks on all three lists are overwhelmed.
>>
>>Thanks,
>>Justin
>>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I'd rather we ask folks to vote one way or another when approving committers and pmc
> membership.
I think that's fair so I'll change it, and having less than 3 votes hasn't been an issue in any committer or PMC vote we had so far.
> Yes, but supposedly, HTTP project is the default unless I can ever get new
> language approved for Voting.html. There's been way too much noise on
> board@ and members@
IMO really would be better if that conversation was where PMC members could read and comment - but that's another issue.
Thanks,
Justin
Re: Project voting guidelines
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/13 9:32 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> I thought most votes to approve committers were consensus, not lazy
>>consensus.
>It varies but more lazy than not I believe. But no issue either way as
>far as I'm concerned. We've not have a vote that's had less than 3 +1 so
>it not been an issue, the last couple of votes I called were "Lazy" and
>there were no comments about that.
I didn't see [LAZY] in the vote subject so I didn't realize they were
lazy. In the one lazy vote to approve a donation, I didn't get any +1
votes. I want folks to realize that if they confirm the draft as written,
we won't have results that show who and how many vote +1, we'll only know
that nobody objected or somebody had the energy to vote +1. I'd rather we
ask folks to vote one way or another when approving committers and pmc
membership. Thoughts from others?
>
>> That seems to be the default for the HTTP project and what we've done
>>in the past.
>It's unclear what we done in the past because no one was sure of the
>voting system in operation, but it's not been an issue (see above).
>Serval other projects use lazy consensus for both committers and PMC eg
>Hive, Pig, Ant, clouldstack and others. Clouldstack bylaws only have 3
>types of voting not omit consensus.
>
>HTTP project also have a "or by not contributing in any form to the
>project for over six months." clause as well, but that seems more
>controversial here.
>
>Basically each project is slightly different is the only conclusion you
>can come to.
Yes, but supposedly, HTTP project is the default unless I can ever get new
language approved for Voting.html. There's been way too much noise on
board@ and members@ so I haven't pushed the issue on incubator because I
think folks on all three lists are overwhelmed.
>
>Thanks,
>Justin
>
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I thought most votes to approve committers were consensus, not lazy consensus.
It varies but more lazy than not I believe. But no issue either way as far as I'm concerned. We've not have a vote that's had less than 3 +1 so it not been an issue, the last couple of votes I called were "Lazy" and there were no comments about that.
> That seems to be the default for the HTTP project and what we've done in the past.
It's unclear what we done in the past because no one was sure of the voting system in operation, but it's not been an issue (see above). Serval other projects use lazy consensus for both committers and PMC eg Hive, Pig, Ant, clouldstack and others. Clouldstack bylaws only have 3 types of voting not omit consensus.
HTTP project also have a "or by not contributing in any form to the project for over six months." clause as well, but that seems more controversial here.
Basically each project is slightly different is the only conclusion you can come to.
Thanks,
Justin
Re: Project voting guidelines
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/13 6:01 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> Is there a reason why you are proposing Lazy forms of voting for most
>> actions?
>Because that's generally the Apache default for voting in committers, PMC
>members etc etc. Although it does vary somewhat with projects with
>guidelines/bylaws. Being able to veto the voting in of a committer or PMC
>member seems reasonably important (to me anyway). Otherwise it could be
>little more than a popularity or voting bloc contest - not that that has
>happened yet. As always a valid veto needs a good reason.
>
>> I kind of like seeing how many folks vote +1 and who they are.
>> Doesn't Lazy essentially only solicit vetos?
>Hasn't stopped people voting +1 or +0 on previous consensus votes we've
>taken.
I thought most votes to approve committers were consensus, not lazy
consensus. That seems to be the default for the HTTP project and what
we've done in the past. Or are we not on the same page as to what "Lazy
Consensus" means?
-Alex
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Is there a reason why you are proposing Lazy forms of voting for most
> actions?
Because that's generally the Apache default for voting in committers, PMC members etc etc. Although it does vary somewhat with projects with guidelines/bylaws. Being able to veto the voting in of a committer or PMC member seems reasonably important (to me anyway). Otherwise it could be little more than a popularity or voting bloc contest - not that that has happened yet. As always a valid veto needs a good reason.
> I kind of like seeing how many folks vote +1 and who they are.
> Doesn't Lazy essentially only solicit vetos?
Hasn't stopped people voting +1 or +0 on previous consensus votes we've taken.
> Can you check whether it should be "[VOTE][RESULT]" or
> "[RESULT][VOTE]"
Will do.
Thanks,
Justin
Re: Project voting guidelines
Posted by Alex Harui <ah...@adobe.com>.
I found time for a quick read. Thanks for taking the time to put together
this document.
Is there a reason why you are proposing Lazy forms of voting for most
actions? I kind of like seeing how many folks vote +1 and who they are.
Doesn't Lazy essentially only solicit vetos?
Did you/Can you check whether it should be "[VOTE][RESULT]" or
"[RESULT][VOTE]" I think someone is creating a vote monitoring tool that
scans subject lines.
Thanks,
-Alex
On 11/6/13 4:59 PM, "Alex Harui" <ah...@adobe.com> wrote:
>I haven't had a chance to read it. I will in about 4 hours.
>
>I'd say the Voting.html only requires majority vote, but I'd rather
>iterate on the proposal to see if we can get consensus.
>
>On 11/6/13 4:11 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>Anyone else? Do people think they are in a good enough start to start a
>>VOTE? And would Lazy 2/3 majority of PMC members be the voting system to
>>use?
>>
>>Thanks,
>>Justin
>
Re: Project voting guidelines
Posted by Alex Harui <ah...@adobe.com>.
I haven't had a chance to read it. I will in about 4 hours.
I'd say the Voting.html only requires majority vote, but I'd rather
iterate on the proposal to see if we can get consensus.
On 11/6/13 4:11 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Anyone else? Do people think they are in a good enough start to start a
>VOTE? And would Lazy 2/3 majority of PMC members be the voting system to
>use?
>
>Thanks,
>Justin
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Anyone else? Do people think they are in a good enough start to start a VOTE? And would Lazy 2/3 majority of PMC members be the voting system to use?
Thanks,
Justin
Re: Project voting guidelines
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Yes, that captures the spirit without sounding too legalese ;-)
EdB
On Wed, Nov 6, 2013 at 6:15 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> I would suggest that we add something like: "and if it's
>> uncontroversial to do so." Where uncontroversial means: no one
>> objects.
> People could object by voting -1 right away but point taken. How about ading "when there is minimal changes between release candidates"?
>
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Project voting guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would suggest that we add something like: "and if it's
> uncontroversial to do so." Where uncontroversial means: no one
> objects.
People could object by voting -1 right away but point taken. How about ading "when there is minimal changes between release candidates"?
Justin
Re: Project voting guidelines
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
"- Release candidate votes can be carry over to the next RC by a
release manager if they so desire"
I would suggest that we add something like: "and if it's
uncontroversial to do so." Where uncontroversial means: no one
objects. Otherwise a release manager could conceivably get the votes
he needs for one RC, then cut another one with undesirable changes in
it and release with the votes from the first one...
EdB
On Wed, Nov 6, 2013 at 4:38 AM, Mark Kessler
<ke...@gmail.com> wrote:
> Looks reasonable. It's nice to have it all down in one place as well.
>
> -Mark
>
>
> On Tue, Nov 5, 2013 at 10:28 PM, Justin Mclean <ju...@classsoftware.com>wrote:
>
>> Hi,
>>
>> Despite Alex's efforts this seem to have stalled:
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cCE743D6A.14A96%25aharui@adobe.com%3e
>>
>> With a few voting issues coming up recently I think it time to consider
>> having our own guidelines.
>>
>> Here some I put together from other Apache projects in combination how we
>> have been working as a project:
>> https://cwiki.apache.org/confluence/display/FLEX/Draft+Guidelines
>>
>> Recent changes include:
>> - removed any mention of what defines an "active" committer or PMC member
>> as it's controversial and can be easily gamed
>> - put in some expected (but not required) committer responsibilities
>> - filled in what are the default the voting rules
>>
>> There are some difference from the "default" Apache guidelines
>> - Committers can veto checkins (seems a better match to me - not that
>> there have been many veto's)
>> - Release candidate votes can be carry over to the next RC by a release
>> manager if they so desire
>> - I also put the length of the Chair as a year with the option of them to
>> stand for another year as that to me seem the fairest way to share that
>> responsibility.
>>
>> Feedback is welcome.
>>
>> Thanks,
>> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Project voting guidelines
Posted by Mark Kessler <ke...@gmail.com>.
Looks reasonable. It's nice to have it all down in one place as well.
-Mark
On Tue, Nov 5, 2013 at 10:28 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> Despite Alex's efforts this seem to have stalled:
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cCE743D6A.14A96%25aharui@adobe.com%3e
>
> With a few voting issues coming up recently I think it time to consider
> having our own guidelines.
>
> Here some I put together from other Apache projects in combination how we
> have been working as a project:
> https://cwiki.apache.org/confluence/display/FLEX/Draft+Guidelines
>
> Recent changes include:
> - removed any mention of what defines an "active" committer or PMC member
> as it's controversial and can be easily gamed
> - put in some expected (but not required) committer responsibilities
> - filled in what are the default the voting rules
>
> There are some difference from the "default" Apache guidelines
> - Committers can veto checkins (seems a better match to me - not that
> there have been many veto's)
> - Release candidate votes can be carry over to the next RC by a release
> manager if they so desire
> - I also put the length of the Chair as a year with the option of them to
> stand for another year as that to me seem the fairest way to share that
> responsibility.
>
> Feedback is welcome.
>
> Thanks,
> Justin