| Message ID | 1474656929-3528-5-git-send-email-lars.kurth@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Lars Kurth writes ("[PATCH v3 4/4] Addressed comments on quorum and security team members"):
> Main changes
> Leadership team decisions: express quorum in terms of +1 votes
> Security Team Members: election
> Project Wide Decision Making: minor text changes
The resulting series is a little odd because your v3 4/4 patch only
changes things that are introduced in v3 3/4 and agreed to be probably
wrong there. I would have been more usual to fold these changes in,
at least if the series related to code.
> --- a/governance.pandoc
> +++ b/governance.pandoc
> @@ -410,18 +410,26 @@ resolution. There is no differentiation between **+1**/ **+2** and
> **-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as a
> vote against the resolution. The number of votes for and against a resolution
> is called **active vote**. **0** votes **are not counted** as an active vote.
> -- A **quorum of more than 50% of active votes** is required for a resolution
> -to pass. In other words, if the leadership team has 7 members, at least 4
> -active votes are required for a resolution to pass.
> +- A **quorum of at least 1/3 of +1 votes for a proposal** is required for a
> +resolution to pass. In other words, if the leadership team has 7 members, at
> +least 3 members need to vote for the resolution.
This paragraph should say `positive' rather than `+1', since as
written it appears to exclude +2. (Same in the table.)
> #### Project Lead Elections
>
> @@ -553,10 +568,10 @@ as outlined below.
> - Project leadership team members vote for or against a proposal (there is no
> differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote is not
> counted as a valid vote.
> -- A **quorum of more than 50%** of each project's leadership team members is
> -required. In other words: if more than half of a project's leadership team
> +- A **quorum of at least 50%** of each project's leadership team members is
> +required. In other words: if fewer than half of a project's leadership team
> members do not vote or abstain, the entire sub-project's vote is not counted.
> -This avoids situations where only a minority of leadership team members votes,
> +This avoids situations where only a minority of leadership team members vote,
This still has the non-monotonicity problem.
I would suggest to deal with this issue by, when calculating the
percentage, dividing all the votes by the larger of (a) the number of
people voting (including `0' votes); (b) one third of the size of the
project leadership team.
So if only two out of a 10-person leadership team vote, and they both
votes in favour, that subproject's overall vote is
2 / max(10/3, 2)
which = 2 / max(10/3, 6/3) = 2 / (max(10,6) / 3) = 2 / (10/3)
= 2 * (3/10) = 6 / 10 = 0.6 = 60%
I would add a further backstop that a successful resolution must have
positive votes from at least three (or maybe, two) separate people.
Ian.
On 03/10/2016 17:27, "Ian Jackson" <ian.jackson@eu.citrix.com> wrote: >Lars Kurth writes ("[PATCH v3 4/4] Addressed comments on quorum and >security team members"): >> Main changes >> Leadership team decisions: express quorum in terms of +1 votes >> Security Team Members: election >> Project Wide Decision Making: minor text changes > >The resulting series is a little odd because your v3 4/4 patch only >changes things that are introduced in v3 3/4 and agreed to be probably >wrong there. I would have been more usual to fold these changes in, >at least if the series related to code. I will merge the two for the next version : hopefully the last > >> --- a/governance.pandoc >> +++ b/governance.pandoc >> @@ -410,18 +410,26 @@ resolution. There is no differentiation between >>**+1**/ **+2** and >> **-1**/**-2**: in other words a **+2** is counted as a vote for, a >>**-2** as a >> vote against the resolution. The number of votes for and against a >>resolution >> is called **active vote**. **0** votes **are not counted** as an >>active vote. >> -- A **quorum of more than 50% of active votes** is required for a >>resolution >> -to pass. In other words, if the leadership team has 7 members, at >>least 4 >> -active votes are required for a resolution to pass. >> +- A **quorum of at least 1/3 of +1 votes for a proposal** is >>required for a >> +resolution to pass. In other words, if the leadership team has 7 >>members, at >> +least 3 members need to vote for the resolution. > >This paragraph should say `positive' rather than `+1', since as >written it appears to exclude +2. (Same in the table.) Agreed >> #### Project Lead Elections >> >> @@ -553,10 +568,10 @@ as outlined below. >> - Project leadership team members vote for or against a proposal >>(there is no >> differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote >>is not >> counted as a valid vote. >> -- A **quorum of more than 50%** of each project's leadership team >>members is >> -required. In other words: if more than half of a project's leadership >>team >> +- A **quorum of at least 50%** of each project's leadership team >>members is >> +required. In other words: if fewer than half of a project's leadership >>team >> members do not vote or abstain, the entire sub-project's vote is not >>counted. >> -This avoids situations where only a minority of leadership team >>members votes, >> +This avoids situations where only a minority of leadership team >>members vote, > >This still has the non-monotonicity problem. > >I would suggest to deal with this issue by, when calculating the >percentage, dividing all the votes by the larger of (a) the number of >people voting (including `0' votes); (b) one third of the size of the >project leadership team. > >So if only two out of a 10-person leadership team vote, and they both >votes in favour, that subproject's overall vote is > 2 / max(10/3, 2) >which = 2 / max(10/3, 6/3) = 2 / (max(10,6) / 3) = 2 / (10/3) > = 2 * (3/10) = 6 / 10 = 0.6 = 60% > >I would add a further backstop that a successful resolution must have >positive votes from at least three (or maybe, two) separate people. Let me play with this Originally I was planning on changing the quorum to match the one for leadership teams for consistency. Lars
Lars Kurth writes ("Re: [PATCH v3 4/4] Addressed comments on quorum and security team members"):
> Originally I was planning on changing the quorum to match the one for
> leadership teams for consistency.
Actually, that's probably a better idea. I think when I wrote my
previous mail I had confused myself into thinking that wasn't
possible.
Ian.
diff --git a/governance.pandoc b/governance.pandoc index 051317b..b1c5d87 100644 --- a/governance.pandoc +++ b/governance.pandoc @@ -410,18 +410,26 @@ resolution. There is no differentiation between **+1**/ **+2** and **-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as a vote against the resolution. The number of votes for and against a resolution is called **active vote**. **0** votes **are not counted** as an active vote. -- A **quorum of more than 50% of active votes** is required for a resolution -to pass. In other words, if the leadership team has 7 members, at least 4 -active votes are required for a resolution to pass. +- A **quorum of at least 1/3 of +1 votes for a proposal** is required for a +resolution to pass. In other words, if the leadership team has 7 members, at +least 3 members need to vote for the resolution. - The resolution passes, if a 2/3 majority of active votes is in favour of it. +The table below maps the number of leadership team members against the +required quorum: + + ------------------------------- --- -- -- -- -- -- -- -- -- + **Leadership team members** 10 9 8 7 6 5 4 3 2 + **+1 votes needed for quorum** 4 3 3 3 2 2 2 1 1 + ------------------------------- --- -- -- -- -- -- -- -- -- + The table below maps active votes against votes needed to pass: - ---------------------------- --- -- -- -- -- -- -- -- -- - **Active Votes** 10 9 8 7 6 5 4 3 2 - **+1 votes needed to pass** 7 6 6 5 4 4 3 2 2 - ---------------------------- --- -- -- -- -- -- -- -- -- + ------------------------------- --- -- -- -- -- -- -- -- -- + **Active Votes (+1 or -1)** 10 9 8 7 6 5 4 3 2 + **+1 votes needed to pass** 7 6 6 5 4 4 3 2 2 + ------------------------------- --- -- -- -- -- -- -- -- -- ### Conflict Resolution {#conflict} @@ -463,11 +471,11 @@ new maintainer. Discussion should happen on the mailing list using the normal decision making process. If there is disagreement or doubt, the decision is handled by the project leadership. -#### Committer, Security Team Member and other Project Leadership Elections +#### Committer and other Project Leadership Elections Developers who have earned the trust of committers in their project can through -election be promoted to Committer, Security Team Member or Project Leadership -(if not covered otherwise). A two stage mechanism is used +election be promoted to Committer or Project Leadership (if not covered otherwise). +A two stage mechanism is used - Nomination: Community members should nominate candidates by posting a proposal to *appointments at xenproject dot org* explaining the candidate's @@ -479,7 +487,14 @@ nomination and publish suitable nominations on the project's public mailing list for wider community input. - Election: A committer will be elected using the decision making process outlined earlier. In other words, the decision is delegated to the [project -leadership team](#leadership). +leadership team](#leadership). + +#### Security Team Members + +Developers who have earned the trust of other security team members can +be promoted to be on the security team. Due to the specific needs of the +security team, promotions are typically made by the security team itself +and confirmed by lazy consensus within the team. #### Project Lead Elections @@ -553,10 +568,10 @@ as outlined below. - Project leadership team members vote for or against a proposal (there is no differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote is not counted as a valid vote. -- A **quorum of more than 50%** of each project's leadership team members is -required. In other words: if more than half of a project's leadership team +- A **quorum of at least 50%** of each project's leadership team members is +required. In other words: if fewer than half of a project's leadership team members do not vote or abstain, the entire sub-project's vote is not counted. -This avoids situations where only a minority of leadership team members votes, +This avoids situations where only a minority of leadership team members vote, which would skew the overall result. If it becomes clear, that a sub-project is not likely to meet the quorum, the voting deadline can be extended by the community manager. @@ -572,7 +587,7 @@ and 1 abstains, the share is 5/7th and 2/7th respectively). - Votes in favour are averaged as percentages across all projects (say we have per project figures of 50%, 80%, 70% in favour, then the total vote in favour is 66.67%). -- If the total vote is more than 2/3rds in favour, the proposal passes. +- If the total vote achieves a 2/3rd majority in favour, the proposal passes. Otherwise it fails. Community Decisions with Funding and Legal Implications (#funding-and-legal)