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

[Lars Kurth]

On 20/09/2016 18:01, "Ian Jackson"  wrote:

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

Will fix.


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

I think probably the term quorum is leading to some confusion here and
should probably be changed. Basically what

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


is trying to encode is a turnout threshold of >50% (discounting spoilt
ballot papers: in other words a **0** votes would be the equivalent of a
spoilt ballot paper). My thinking was that
A) The rules would encourage team members to vote for or against a
proposal, rather than abstain
B) The minimum threshold is there to ensure that we don't have to manage
disappearing leadership team members tightly and that decisions have
enough legitimacy
C) The 2/3 majority would only apply to the people that have voted for or
against a proposal

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

This is wrong. With a team of 6, at least 4 people would need to vote
"yes" or "no" to pass the 50% threshold. If more than "2" decline to vote,
the threshold wont be achieved. Amongst the 4 votes, 3 would need to be in
favour.

But you are right, this does open the door to tactical voting in some
boundary cases. So if there were 2 active "0" votes and 3 "+1" votes, the
last voter could shoot down the proposal by voting "0". If the vote had
been secret, that person would probably vote "-1" and the proposal would
pass. The same applies, if we were close to the voting deadline and 3
people had voted "+1" and 2 had not.

I am not quite sure I understand what you mean by "otherwise someone who
opposes a proposal has to guess whether it is more likely to fail quorum,
or to fail the 2/3 majority", but I guess it is what I outlined above. I
suppose the whole issue would go away, if there was a secret vote. But
introducing this, would be a bit heavyweight.
 
>I suggest changing the quorum threshold to count only explicit
>abstentions and votes in favour; either 1/3 or 50% would do.

I am not suggesting this is a bad idea, but I don't think I fully
understand what you mean and how your proposal avoids the issue above.

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

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

[Ian Jackson]

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

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

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH v2 3/3] Significant changes to decision making; 
some new roles and minor changes"):
> Almost everyone else has reviewed this series already: Jan, Stefano, Wei,
> Tim and I think Konrad.
> That leaves you and George amongst the committers: so I am not sure
> whether there is much point in doing so. But I am not against it.

I will review it as is, too, then.

Ian.

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

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

[Lars Kurth]

On 19/09/2016 15:01, "Ian Jackson"  wrote:

>Lars Kurth writes ("Re: [PATCH v2 3/3] Significant changes to decision
>making; some new roles and minor changes"):
>> I could, but it isn't really that long. And it makes life hard for me,
>>as
>> there is only one file. Thus breaking it into bits and maintaining the
>> changes is hard in git.
>
>Are you aware of `git add -i' ?

No: will look at it next time.

>If you find it too difficult I would be happy to try to rework your
>final patch into a series of smaller changes.

I talked to George and he is happy to review this as-is.

The only sensible way to break it into smaller bits is by chapter: there
are very few dependencies across chapters (with the exception of
cross-references such as anchors and links).

Almost everyone else has reviewed this series already: Jan, Stefano, Wei,
Tim and I think Konrad.
That leaves you and George amongst the committers: so I am not sure
whether there is much point in doing so. But I am not against it.

Lars

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

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

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH v2 3/3] Significant changes to decision making; 
some new roles and minor changes"):
> I could, but it isn't really that long. And it makes life hard for me, as
> there is only one file. Thus breaking it into bits and maintaining the
> changes is hard in git.

Are you aware of `git add -i' ?

Breaking multiple changes to a single file, into separate patches, is
routine for us git users.  We'd be happy to help...

If you find it too difficult I would be happy to try to rework your
final patch into a series of smaller changes.

Ian.

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

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

[Lars Kurth]

On 13/09/2016 17:46, "George Dunlap"  wrote:

>On 12/09/16 17:20, Lars Kurth wrote:
>> Added RTC Policy
>> Added +2 ... -2 scheme for votes
>> Clarified lazy consensus (tallying and lazy voting)
>> Added Informal Votes/Surveys
>> Added Project Team Leadership role and Decision making
>> Added Community Decisions with Funding and Legal Implications
>> Changed Project Wide Decision making: per project based scheme
>> Clarified scope of Decision making
>
>Hey Lars,
>
>Would it be possible to break some of these down into separate patches?
>This is an awfully long "patch" to review all at once; and it seems like
>it would be nice for you as well to be able to get Acked / Reviewed-by's
>for some of the smaller and/or less contentious items as you go along.

I could, but it isn't really that long. And it makes life hard for me, as
there is only one file. Thus breaking it into bits and maintaining the
changes is hard in git.

Also, it is unclear whether we need to follow the regular process, as
technically we need to have a vote on the final proposal.

>There are a number of sections of this that I have read and basically
>approve of; a number that I have read and am still thinking about or
>some comments on; and a number that I haven't grokked yet and will want
>to do later.  (I'll think for a bit and maybe come back to this later
>this week.)

Thanks

Lars

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

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

[George Dunlap]

On 12/09/16 17:20, Lars Kurth wrote:
> Added RTC Policy
> Added +2 ... -2 scheme for votes
> Clarified lazy consensus (tallying and lazy voting)
> Added Informal Votes/Surveys
> Added Project Team Leadership role and Decision making
> Added Community Decisions with Funding and Legal Implications
> Changed Project Wide Decision making: per project based scheme
> Clarified scope of Decision making

Hey Lars,

Would it be possible to break some of these down into separate patches?
This is an awfully long "patch" to review all at once; and it seems like
it would be nice for you as well to be able to get Acked / Reviewed-by's
for some of the smaller and/or less contentious items as you go along.

There are a number of sections of this that I have read and basically
approve of; a number that I have read and am still thinking about or
some comments on; and a number that I haven't grokked yet and will want
to do later.  (I'll think for a bit and maybe come back to this later
this week.)

 -George


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

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

[Lars Kurth]

Added RTC Policy
Added +2 ... -2 scheme for votes
Clarified lazy consensus (tallying and lazy voting)
Added Informal Votes/Surveys
Added Project Team Leadership role and Decision making
Added Community Decisions with Funding and Legal Implications
Changed Project Wide Decision making: per project based scheme
Clarified scope of Decision making

Modified sections which have dependencies on changes about

Signed-off-by: Lars Kurth 
---
 governance.pandoc | 773 --
 1 file changed, 581 insertions(+), 192 deletions(-)

diff --git a/governance.pandoc b/governance.pandoc
index 86e4433..04a1dc6 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,6 +1,5 @@
-
 This document has come in effect in June 2011 and will be reviewed 
periodically 
-(see revision sections). The last modification has been made in July 2016.
+(see revision sections). The last modification has been made in September 2016.
 
 Content
 ---
@@ -12,8 +11,10 @@ Content
 -   [Making Contributions](#contributions)
 -   [Decision Making, Conflict Resolution, Role Nominations and 
 Elections](#decisions)
--   [Formal Votes](#formal-votes)
+-   [Project Wide Decision Making](#project-decisions)
+-   [Community Decisions with Funding and Legal 
Implications](#funding-and-legal)
 -   [Project Governance](#project-governance)
+-   [Per Sub-Project Governance Specialisations](#specialisations)
 
 Goals {#goals}
 -
@@ -55,23 +56,13 @@ The Xen Project is a meritocracy. The more you contribute 
the more
 responsibility you will earn. Leadership roles in Xen are also merit-based and 
 earned by peer acclaim.
 
-
-
-
-I moved the "Roles" section up and split it into two sections with 
unmodified content
-- Xen Project Wide Roles
-- Project Team Roles
-
-
+### Local Decision Making
 
-Xen Project Wide Roles {#roles-global}
+The Xen Project consists of a number of sub-projects: each sub-project makes 
+technical and other decisions that solely affect it locally.
+
+Xen Project Wide Roles {#roles-global} 
 --
-
-
-
-MINOR ISSUES TO BE ADDRESSED LATER: 
-- Sub-projects and Teams would benefit from some forward references to 
highlight the 
-  difference between incubation mature projects.
-- Also we should clarify what assets a sub-project owns. 
-- Add the role of Community Manager as it used throughout the document
-
-
 
 ### Sub-projects and Teams
 
@@ -80,9 +71,22 @@ the [Project Governance](#project-governance) (or Project 
Lifecycle) as
 outlined in this document. Sub-projects (sometimes simply referred to as 
 projects) are run by individuals and are often referred to as teams to 
 highlight the collaborative nature of development. For example, each 
-sub-project has a [team portal](/developers/teams.html) on Xenproject.org.
+sub-project has a [team portal](/developers/teams.html) on Xenproject.org. 
+Sub-projects own and are responsible for a collection of source repositories 
+and other resources (e.g. test infrastructure, CI infrastructure, ...), which 
+we call **sub-project assets** (or team assets) in this document.
 
-### Xen Project Advisory Board
+Sub-projects can either be **incubation projects** or **mature projects** as 
+outlined in [Basic Project Life Cycle](#project-governance). In line with the 
+meritocratic principle, mature projects have more influence than incubation 
+projects, on [project wide decisions](#project-decisions).
+
+### Community Manager
+
+The Xen Project has a community manager, whose primary role it is to support 
+the entire Xen Project Community.
+
+### Xen Project Advisory Board {#roles-ab}
 
 The [Xen Project Advisory Board](/join.html) consists of members who are 
 committed to steering the project to advance its market and technical success, 
@@ -92,7 +96,7 @@ shared project infrastructure, marketing and events, and 
managing the Xen
 Project trademark. The Advisory Board leaves all technical decisions to the 
 open source meritocracy.
 
-### The Linux Foundation
+### The Linux Foundation {#roles-lf}
 
 The Xen Project is a [Linux Foundation](/linux-foundation.html) Collaborative 
 Project. Collaborative Projects are independently funded software projects 
that 
@@ -111,30 +115,60 @@ members or other distinguished community members.
 ### Sponsor
 
 To form a new sub-project or team on Xenproject.org, we require a sponsor to 
-support the creation of the new project. A sponsor can be a project lead or 
-committer of a mature project, a member of the advisory board or the community 
-manager. This ensures that a