Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision making; some 
new roles and minor changes"):
> [proposal]

Thanks.  I've reviewed this and it looks generally good but I have
some specific comments.


Throughout you use "gage" where I think you should use "gauge".
(AFAICT from Wiktionary this is not a US/UK spelling thing.)

> +Voting is conducted in line with the following rules:
> +
> +-   Project leadership team members vote for (**+1**) or against (**-1**) a 
> +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.
> +-   The resolution passes, if a 2/3 majority of active votes is in favour of 
> +it. 

Quorums like this should count only positive votes.  Otherwise someone
who opposes a proposal has to guess whether it is more likely to fail
quorum, or to fail the 2/3 majority.  If it is likely to fail quorum,
they should refrain from voting.

For example with a team of 6, with two people having alread voted yes,
and the remaining three having expressly declined to vote because they
don't have an opinion, a leadership team member who votes "no" would
move the outcome from "quorum not met since only 2 out of 6 active
voters - fail" to "quorum met with 3 active voters, 2 votes in favour,
one against, 2/3 majority met - pass".

I suggest changing the quorum threshold to count only explicit
abstentions and votes in favour; either 1/3 or 50% would do.


> -### Conflict Resolution
> +    Let me express this as an algorithm.
>  
> -    
> -------------------------------------------------------------------------------------
> -    ISSUES TO BE ADDRESSED LATER: 
> -    - Generalise refereeing in terms of Project Leadership instead of 
> specific roles
> -    - Also some examples for sPecific situations that have happened in the 
> past may be 
> -      useful
> -    
> -------------------------------------------------------------------------------------
> +      treshhold=2/3;

         threshold

> +      active='number of active members'; (7 for the Hypervisor project; IanC 
> is inactive)

                                                                         ^
                                                   at the time of writing, 
2016-09-20

> -#### Refereeing
> +    One open question is what to do with 0-votes. We could introduce a rule 
> discounting 
> +    0 votes (let's call it 0-rule). If someone votes 0, we assume they 
> really don't care
> +    about the outcome and are considered inactive for the purpose of the 
> vote. 

With my proposal you can delete this because 0-votes do not affect
quorum.

> +    The other question is whether to treat -2-votes different than -1-votes. 
> We could
> +    say there should not be more than 20% -2-votes. That would mean that

No.  Formal decisonmaking of this sort should not count some votes
double.

> +    The entire last resource section goes, because it is essentially not 
> needed any more, 
                       ^^^^^^^^
                       resort

> +#### Committer, Security Team Member and other Project Leadership Elections
...
>  -   Nomination: Community members should nominate candidates by posting a 
>  proposal to *appointments at xenproject dot org* explaining the candidate's 
> @@ -299,74 +606,123 @@ review all proposals, check whether the nominee would 
> be willing to accept the
>  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. Voting will be done by committers for that project 
> privately 
> -using a voting form that is created by the community manager. Should there 
> be a 
> -negative vote the project lead and community manager will try and resolve 
> the 
> -situation and reach consensus. Results will be published on the public 
> mailing 
> -list.
> +outlined earlier. In other words, the decision is delegated to the [project 
> +leadership team](#leadership).

This misses out appointments to the security team.  I suggest that
they should usually be made by the team itself according to lazy
consensus.

> +  
> -----------------------------------------------------------------------------------------
>    
> +  **Proposal**                  **Who reviews?**              **Who votes?**
> +  ----------------------------- ----------------------------- 
> -----------------------------   
> +  Creating, graduating,         Members of developer mailing  Leadership 
> teams of 
> +  completing/archiving of       lists of qualifying projects  **mature** 
> sub-projects, 
> +  sub-projects                                                with the 
> exception of the 
> +                                                              project which 
> is being 
> +                                                              reviewed (e.g. 
> for an 
> +                                                              archivation 
> review, the 
> +                                                              leadership 
> team of the 
> +                                                              project under 
> review, cannot 
> +                                                              vote).
> +
> +  Global Process Changes        Members of developer mailing  Leadership 
> teams of  
> +                                lists of qualifying projects  **mature** 
> sub-projects, 
> +                                                              within the 
> scope described 
> +                                                              above. 

> +-   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 
> +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, 
> +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 
> +communiuty manager.
> +-   For each qualifying project with a quorum, the percentage of votes in 
> +favour and against is calculated (e.g. if 5 people voted in favour, 2 
> against 
> +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. 
> +Otherwise it fails.

This is a rather complex approach but I don't have a clearly better proposal.


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel