* [PATCH 1/3] Code motion changes to make real patches easier to read
[not found] <1470957226-18139-1-git-send-email-lars.kurth@citrix.com>
@ 2016-08-11 23:13 ` Lars Kurth
2016-08-11 23:13 ` [PATCH 2/3] Added comment sections to highight problem areas Lars Kurth
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-11 23:13 UTC (permalink / raw)
To: xen-devel; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, Lars Kurth
Added TOC
Re-arranged sections compared to previous version of document
Added new anchors where needed
Split Roles section into two sections
The actual content was not changed (with the exception of minor
typos that I spotted)
Signed-off-by: Lars Kurth <lars.kurth@citrix.com>
---
governance.pandoc | 207 +++++++++++++++++++++++++++++-------------------------
1 file changed, 113 insertions(+), 94 deletions(-)
diff --git a/governance.pandoc b/governance.pandoc
index 60fc942..2ce780c 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,9 +1,20 @@
-
-This document has come in effect in June 2011 and will be
-reviewed periodically (see revision sections). The last modification has been
-made in May 2013.
-
-Goals
+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.
+
+Content
+-------
+
+- [Goals](#goals)
+- [Principles](#principles)
+- [Xen Project Wide Roles](#roles-global)
+- [Project Team Roles](#roles-local)
+- [Making Contributions](#contributions)
+- [Decision Making, Conflict Resolution, Role Nominations and
+Elections](#decisions)
+- [Formal Votes](#formal-votes)
+- [Project Governance](#project-governance)
+
+Goals {#goals}
-----
The goals of Xen Project Governance are to:
@@ -22,7 +33,7 @@ going elsewhere
- Set clear expectations to vendors, upstream and downstream projects and
community members
-Principles
+Principles {#principles}
----------
### Openness
@@ -43,71 +54,8 @@ 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.
-### Consensus Decision Making
-
-Sub-projects or teams hosted on Xenproject.org are normally auto-governing and
-driven by the people who volunteer for the job. This functions well for most
-cases. When more formal decision making and coordination is required, decisions
-are taken with a lazy consensus approach: a few positive votes with no negative
-vote are enough to get going.
-
-Voting is done with numbers:
-
-- +1 : a positive vote
-- 0 : abstain, have no opinion
-- -1 : a negative vote
-
-A negative vote should include an alternative proposal or a detailed
-explanation of the reasons for the negative vote. The project community then
-tries to gather consensus on an alternative proposal that resolves the issue.
-In the great majority of cases, the concerns leading to the negative vote can
-be addressed.
-
-### Conflict Resolution
-
-#### Refereeing
-
-Sub-projects and teams hosted on Xenproject.org are not democracies but
-meritocracies. In situations where there is disagreement on issues related to
-the day-to-day running of the project, Committers and Project Leads are
-expected to act as referees and make a decision on behalf of the community.
-Referees should however consider whether making a decision may be divisive and
-damaging for the community. In such cases, the committer community of the
-project can privately vote on an issue, giving the decision more weight.
-
-#### Last Resort
-
-In some rare cases, the lazy consensus approach may lead to the community being
-paralyzed. Thus, as a last resort when consensus cannot be achieved on a
-question internal to a project, the final decision will be made by a private
-majority vote amongst the committers and project lead. If the vote is tied, the
-project lead gets an extra vote to break the tie.
-
-For questions that affect several projects, committers and project leads of
-mature projects will hold a private majority vote. If the vote is tied, the
-[Xen Project Advisory Board](/join.html) will break the tie through a casting
-vote.
-
-Roles
------
-
-### Maintainers
-
-Maintainers own one or several components in the Xen tree. A maintainer reviews
-and approves changes that affect their components. It is a maintainer's prime
-responsibility to review, comment on, co-ordinate and accept patches from other
-community member's and to maintain the design cohesion of their components.
-Maintainers are listed in a MAINTAINERS file in the root of the source tree.
-
-### Committers
-
-Committers are Maintainers that are allowed to commit changes into the source
-code repository. The committer acts on the wishes of the maintainers and
-applies changes that have been approved by the respective maintainer(s) to the
-source tree. Due to their status in the community, committers can also act as
-referees should disagreements amongst maintainers arise. Committers are listed
-on the sub-project's team portal (e.g. [Hypervisor team
-portal](/developers/teams/hypervisor.html)).
+Xen Project Wide Roles {#roles-global}
+----------------------
### Sub-projects and Teams
@@ -118,16 +66,6 @@ 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.
-### Project Lead
-
-Sub-projects and teams hosted on Xenproject.org are managed by a Project Lead,
-who also is a committer of the sub-project/team he/she leads. Project Leads are
-the public figurehead of the project and is responsible for the health of the
-project. Due to their status in the community, project leads can also act as
-referees should disagreements amongst committers of the project arise. The
-project lead typically also has write access to resources, such as the web page
-of a specific project.
-
### Xen Project Advisory Board
The [Xen Project Advisory Board](/join.html) consists of members who are
@@ -162,7 +100,38 @@ committer of a mature project, a member of the advisory board or the community
manager. This ensures that a distinguished community member supports the idea
behind the project.
-Making Contributions
+Project Team Roles {#roles-local}
+------------------
+
+### Maintainers
+
+Maintainers own one or several components in the Xen tree. A maintainer reviews
+and approves changes that affect their components. It is a maintainer's prime
+responsibility to review, comment on, co-ordinate and accept patches from other
+community member's and to maintain the design cohesion of their components.
+Maintainers are listed in a MAINTAINERS file in the root of the source tree.
+
+### Committers
+
+Committers are Maintainers that are allowed to commit changes into the source
+code repository. The committer acts on the wishes of the maintainers and
+applies changes that have been approved by the respective maintainer(s) to the
+source tree. Due to their status in the community, committers can also act as
+referees should disagreements amongst maintainers arise. Committers are listed
+on the sub-project's team portal (e.g. [Hypervisor team
+portal](/developers/teams/hypervisor.html)).
+
+### Project Lead
+
+Sub-projects and teams hosted on Xenproject.org are managed by a Project Lead,
+who also is a committer of the sub-project/team he/she leads. Project Leads are
+the public figurehead of the project and is responsible for the health of the
+project. Due to their status in the community, project leads can also act as
+referees should disagreements amongst committers of the project arise. The
+project lead typically also has write access to resources, such as the web page
+of a specific project.
+
+Making Contributions {#contributions}
--------------------
Making contributions in Xen follows the conventions as they are known in the
@@ -176,12 +145,60 @@ Origin](http://elinux.org/Developer_Certificate_Of_Origin)).
More information on making contributions can be found in the following
documents:
-- [Contribution Guidelines](g/help/contribution-guidelines.html)
+- [Contribution Guidelines](/help/contribution-guidelines.html)
+
+Decision Making, Conflict Resolution, Role Nominations and Elections
+{#decisions}
+--------------------------------------------------------------------
+
+### Consensus Decision Making
+
+Sub-projects or teams hosted on Xenproject.org are normally auto-governing and
+driven by the people who volunteer for the job. This functions well for most
+cases. When more formal decision making and coordination is required, decisions
+are taken with a lazy consensus approach: a few positive votes with no negative
+vote are enough to get going.
+
+Voting is done with numbers:
+
+- +1 : a positive vote
+- 0 : abstain, have no opinion
+- -1 : a negative vote
+
+A negative vote should include an alternative proposal or a detailed
+explanation of the reasons for the negative vote. The project community then
+tries to gather consensus on an alternative proposal that resolves the issue.
+In the great majority of cases, the concerns leading to the negative vote can
+be addressed.
+
+### Conflict Resolution
+
+#### Refereeing
+
+Sub-projects and teams hosted on Xenproject.org are not democracies but
+meritocracies. In situations where there is disagreement on issues related to
+the day-to-day running of the project, Committers and Project Leads are
+expected to act as referees and make a decision on behalf of the community.
+Referees should however consider whether making a decision may be divisive and
+damaging for the community. In such cases, the committer community of the
+project can privately vote on an issue, giving the decision more weight.
+
+#### Last Resort
+
+In some rare cases, the lazy consensus approach may lead to the community being
+paralyzed. Thus, as a last resort when consensus cannot be achieved on a
+question internal to a project, the final decision will be made by a private
+majority vote amongst the committers and project lead. If the vote is tied, the
+project lead gets an extra vote to break the tie.
+
+For questions that affect several projects, committers and project leads of
+mature projects will hold a private majority vote. If the vote is tied, the
+[Xen Project Advisory Board](/join.html) will break the tie through a casting
+vote.
-Elections and Formal Votes
---------------------------
+### Elections
-### Maintainer Elections
+#### Maintainer Elections
Developers who have earned the trust of maintainers (including the project
lead) can be promoted to Maintainer. A two stage mechanism is used
@@ -199,7 +216,7 @@ principles of consensus decision making. If there is disagreement or doubt, the
project lead or a committer should ask the community manager to arrange a more
formal vote.
-### Committer Elections
+#### Committer Elections
Developers who have earned the trust of committers in their project can through
election be promoted to Committer. A two stage mechanism is used
@@ -219,21 +236,22 @@ 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.
-### Project Lead Elections
+#### Project Lead Elections
Projects which lose their project lead are at risk of failing. Should this
occur, the project's maintainer community should agree who would want to be/be
able to be the new project lead and follow the election process as outlined
above.
-### Formal Votes
+Formal Votes {#formal-votes}
+------------
Sometimes it is necessary to conduct formal voting within the community
(outside of elections). Formal votes are necessary when processes and
procedures are introduced or changed, or as part of the [Project
Governance](#project-governance). Who is eligible to vote, depends on whether
the scope of a process or procedure is **local** to a sub-project or team, or
-whether it affects **all sub-projects** (or in other words, is**global**).
+whether it affects **all sub-projects** (or in other words, is **global**).
Examples of local scope is the [Security Policy](/security-policy.html) which
applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only.
Examples of global scope are changes to this document or votes outlined in the
@@ -263,7 +281,7 @@ each. For voting a traceable poll mechanism (e.g. voting form that keeps
auditable and tamper proof records) must be used. Voting follows the
conventions as laid out in "Principle: Consensus Decision Making".
-Project Governance
+Project Governance {#project-governance}
------------------
### Basic Project Life Cycle
@@ -461,7 +479,7 @@ words it has completed
In the first case the review is triggered by the incubation project's mentor.
Failing this the review can be requested by any maintainer of a mature project
-(including the projec's lead) or by the Xen Project community manager. See
+(including the project's lead) or by the Xen Project community manager. See
"Requesting Reviews, Reviews and Voting".
The review is essentially a pitch why the project should be archived. The
@@ -514,6 +532,7 @@ will support the project lead in finding a new mentor.
Change History
--------------
+- **v3.0 July 2016:** TODO: Add real changelog in main patch
- **v2.1 May 2016:** Clarify Committer Elections as per this
[discussion](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg0080
1.html) and
@@ -539,6 +558,6 @@ from Requesting Reviews, Reviews and Voting rather than duplicating
- Clarified the roles of Committer and Maintainer.
- Added Making Contributions which contains links to other documentation
and highlights that Xen.org required a DCO for contributions since 2005.
-- **v1.0 Jun 2011:** Intial document approved
+- **v1.0 Jun 2011:** Initial document approved
\ No newline at end of file
--
2.5.4 (Apple Git-61)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/3] Added comment sections to highight problem areas
[not found] <1470957226-18139-1-git-send-email-lars.kurth@citrix.com>
2016-08-11 23:13 ` [PATCH 1/3] Code motion changes to make real patches easier to read Lars Kurth
@ 2016-08-11 23:13 ` Lars Kurth
2016-08-11 23:13 ` [PATCH 3/3] Significant changes to decision making; some new roles and minor changes Lars Kurth
[not found] ` <1470957226-18139-4-git-send-email-lars.kurth@citrix.com>
3 siblings, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-11 23:13 UTC (permalink / raw)
To: xen-devel; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, Lars Kurth
These are marked by
-------------------------------------------------------------------------
...
-------------------------------------------------------------------------
blocks that will be removed in the published version
Signed-off-by: Lars Kurth <lars.kurth@citrix.com>
---
governance.pandoc | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 88 insertions(+), 3 deletions(-)
diff --git a/governance.pandoc b/governance.pandoc
index 2ce780c..86e4433 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,3 +1,4 @@
+
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.
@@ -54,8 +55,23 @@ 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
+ -------------------------------------------------------------------------------------
+
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
@@ -103,6 +119,15 @@ behind the project.
Project Team Roles {#roles-local}
------------------
+ -------------------------------------------------------------------------------------
+ ISSUES TO BE ADDRESSED LATER:
+ - Fix minor Inaccuracies and Improvements
+ - Allow for customization of roles by sub-projects (but this definition is the default)
+ - Allow for Security Response Team
+ - Allow for sub-projects to be lead by a Project Leadership Team (which may include a
+ Project Lead)
+ -------------------------------------------------------------------------------------
+
### Maintainers
Maintainers own one or several components in the Xen tree. A maintainer reviews
@@ -131,6 +156,10 @@ referees should disagreements amongst committers of the project arise. The
project lead typically also has write access to resources, such as the web page
of a specific project.
+ -------------------------------------------------------------------------------------
+ Moved this section
+ -------------------------------------------------------------------------------------
+
Making Contributions {#contributions}
--------------------
@@ -147,18 +176,46 @@ documents:
- [Contribution Guidelines](/help/contribution-guidelines.html)
-Decision Making, Conflict Resolution, Role Nominations and Elections
-{#decisions}
+ -------------------------------------------------------------------------------------
+ Consolidated all Decision Making Related topics into one section
+ - I changed the order of the sections from ...
+ "Consensus Decision Making, Conflict Resolution, Elections and Formal Votes" to
+ "Consensus Decision Making, Formal Votes, Conflict Resolution, Elections"
+ - I changed header titles and fixed the headline
+
+ Otherwise the relevant sections remain identical, with the exception of comment
+ sections that I added, which highlight issues that are to be addressed.
+ -------------------------------------------------------------------------------------
+
+Decision Making, Conflict Resolution, Role Nominations and Elections {#decisions}
--------------------------------------------------------------------
+ -------------------------------------------------------------------------------------
+ ISSUES TO BE ADDRESSED LATER:
+ - Add a pre-amble explaining the different decision making mechanisms and when they
+ apply
+ - Add a section about review and commit, which is the primary means of making
+ code related decisions
+ -------------------------------------------------------------------------------------
+
### Consensus Decision Making
+ -------------------------------------------------------------------------------------
+ ISSUES TO BE ADDRESSED LATER:
+ - The "Consensus Decision Making" section is totally wrong. It does not describe
+ "Lazy Consensus"
+ -------------------------------------------------------------------------------------
+
Sub-projects or teams hosted on Xenproject.org are normally auto-governing and
driven by the people who volunteer for the job. This functions well for most
cases. When more formal decision making and coordination is required, decisions
are taken with a lazy consensus approach: a few positive votes with no negative
vote are enough to get going.
+ -------------------------------------------------------------------------------------
+ - Introduce -2 to +2 voting under a new section
+ -------------------------------------------------------------------------------------
+
Voting is done with numbers:
- +1 : a positive vote
@@ -173,6 +230,13 @@ be addressed.
### Conflict Resolution
+ -------------------------------------------------------------------------------------
+ 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
+ -------------------------------------------------------------------------------------
+
#### Refereeing
Sub-projects and teams hosted on Xenproject.org are not democracies but
@@ -196,6 +260,11 @@ mature projects will hold a private majority vote. If the vote is tied, the
[Xen Project Advisory Board](/join.html) will break the tie through a casting
vote.
+ -------------------------------------------------------------------------------------
+ Changed headline structure: h2 to h3
+ Removed Formal Votes from headline as it has been moved into a separate section
+ -------------------------------------------------------------------------------------
+
### Elections
#### Maintainer Elections
@@ -246,12 +315,23 @@ above.
Formal Votes {#formal-votes}
------------
+ -------------------------------------------------------------------------------------
+ ISSUES TO BE ADDRESSED LATER:
+ - Local votes should be handled elsewhere: this section should only cover global
+ decision making
+ - Better specify scope : when are Formal Votes applicable
+ - In fact we do not have any clear rules for tallying votes (do votes have to be
+ unanimous or not)
+ - Note that the voting eligibility is maintainers? Do we want to retain this?
+ I assume NO, as in practive we never did this.
+ -------------------------------------------------------------------------------------
+
Sometimes it is necessary to conduct formal voting within the community
(outside of elections). Formal votes are necessary when processes and
procedures are introduced or changed, or as part of the [Project
Governance](#project-governance). Who is eligible to vote, depends on whether
the scope of a process or procedure is **local** to a sub-project or team, or
-whether it affects **all sub-projects** (or in other words, is **global**).
+whether it affects **all sub-projects** (or in other words, is** global**).
Examples of local scope is the [Security Policy](/security-policy.html) which
applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only.
Examples of global scope are changes to this document or votes outlined in the
@@ -280,6 +360,11 @@ private vote. Public review and voting should be open for a minimum of a week
each. For voting a traceable poll mechanism (e.g. voting form that keeps
auditable and tamper proof records) must be used. Voting follows the
conventions as laid out in "Principle: Consensus Decision Making".
+
+ -------------------------------------------------------------------------------------
+ ISSUES TO BE ADDRESSED LATER:
+ - Verify terminology in light of changes above
+ -------------------------------------------------------------------------------------
Project Governance {#project-governance}
------------------
--
2.5.4 (Apple Git-61)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] <1470957226-18139-1-git-send-email-lars.kurth@citrix.com>
2016-08-11 23:13 ` [PATCH 1/3] Code motion changes to make real patches easier to read Lars Kurth
2016-08-11 23:13 ` [PATCH 2/3] Added comment sections to highight problem areas Lars Kurth
@ 2016-08-11 23:13 ` Lars Kurth
[not found] ` <1470957226-18139-4-git-send-email-lars.kurth@citrix.com>
3 siblings, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-11 23:13 UTC (permalink / raw)
To: xen-devel; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, Lars Kurth
Added RTC Policy
Added +2 ... -2 scheme for votes
Clarified lazy consensus
Added Informal Votes/Surveys
Added Project Team Leadership role and Decision making
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 <lars.kurth@citrix.com>
---
governance.pandoc | 714 ++++++++++++++++++++++++++++++++++++++++--------------
1 file changed, 535 insertions(+), 179 deletions(-)
diff --git a/governance.pandoc b/governance.pandoc
index 86e4433..b824c7f 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,4 +1,3 @@
-
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.
@@ -12,8 +11,9 @@ Content
- [Making Contributions](#contributions)
- [Decision Making, Conflict Resolution, Role Nominations and
Elections](#decisions)
-- [Formal Votes](#formal-votes)
+- [Project Wide Decision Making](#project-decisions)
- [Project Governance](#project-governance)
+- [Per Sub-Project Governance Specialisations](#specialisations)
Goals {#goals}
-----
@@ -55,23 +55,17 @@ 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.
-
+### Local Decision Making
+
-------------------------------------------------------------------------------------
- I moved the "Roles" section up and split it into two sections with unmodified content
- - Xen Project Wide Roles
- - Project Team Roles
+ This is a little clumsy: maybe someone can come up with a better definition
-------------------------------------------------------------------------------------
-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,7 +74,20 @@ 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.
+
+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
@@ -111,30 +118,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 distinguished community member supports the idea
-behind the project.
+support the creation of the new project. A sponsor can be a member of the
+project leadership team of a mature project, a member of the advisory board or
+the community manager. This ensures that a distinguished community member
+supports the idea behind the project.
Project Team Roles {#roles-local}
------------------
- -------------------------------------------------------------------------------------
- ISSUES TO BE ADDRESSED LATER:
- - Fix minor Inaccuracies and Improvements
- - Allow for customization of roles by sub-projects (but this definition is the default)
- - Allow for Security Response Team
- - Allow for sub-projects to be lead by a Project Leadership Team (which may include a
- Project Lead)
- -------------------------------------------------------------------------------------
+Sub-projects or teams are driven by the people who volunteer for the job. This
+functions well for most cases. This section lists the main roles which projects
+use. This section lists the default roles, which are based on how the
+Hypervisor project operates. Sub-projects can deviate from the default, but are
+required to document deviations from the default and link to it from this
+[document](#specialisations). The only exception is that each project is
+required to have a project leadership team, as without it, the project will not
+be able to function.
+
+The following table lists how each project uses these roles. Note that
+**incubation projects** have more flexibility in experimenting with roles that
+work for them, but need to define specialistions before they can **mature**.
+
+ --------------------- ------------ ----------------- ---------------- ------------------- --------------------------------------------------------
+ **Project** **Mature** **Maintainers** **Committers** **Security Team** **Leadership Team**
+ **Hypervisor** YES YES YES YES Committers and Release Manager, without a Project Lead
+ **Windows Drivers** NO YES YES NO Committers, with a Project Lead
+ **XAPI** YES YES YES NO Committers, with a Project Lead
+ --------------------- ------------ ----------------- ---------------- ------------------- --------------------------------------------------------
+
### Maintainers
-Maintainers own one or several components in the Xen tree. A maintainer reviews
-and approves changes that affect their components. It is a maintainer's prime
-responsibility to review, comment on, co-ordinate and accept patches from other
-community member's and to maintain the design cohesion of their components.
-Maintainers are listed in a MAINTAINERS file in the root of the source tree.
+Maintainers own one or several components in the sub-projects source tree(s). A
+maintainer reviews and approves changes that affect their components. It is a
+maintainer's prime responsibility to review, comment on, co-ordinate and accept
+patches from other community member's and to maintain the design cohesion of
+their components. Maintainers are listed in a MAINTAINERS file in the root of
+each code repository that the project owns.
+
+Larger sub-projects such as the Hypervisor may have special maintainer roles
+such as a release manager and stable branch maintainers. In addition, larger
+projects may award different maintainers different levels of influence. Any
+specialisations and implications are documented in the respective MAINTAINERS
+file.
+
+ -------------------------------------------------------------------------------------
+ CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+ - The xen.git MAINTAINERS file does not list our release managers and
+ stable branch maintainers
+ - We do have a number of repos without MAINTAINERS files, e.g. mini-os.git,
+ osstest.git
+ - For projects with many repositories (e.g. XAPI and Mirage OS), using MAINTAINERS
+ files is not very practical. XAPI seems to sometimes use MAINTAINERS and README
+ files at other times. We may need a more central place to state roles.
+ -------------------------------------------------------------------------------------
### Committers
@@ -144,22 +181,41 @@ applies changes that have been approved by the respective maintainer(s) to the
source tree. Due to their status in the community, committers can also act as
referees should disagreements amongst maintainers arise. Committers are listed
on the sub-project's team portal (e.g. [Hypervisor team
-portal](/developers/teams/hypervisor.html)).
+portal](/developers/teams/hypervisor.html)) and/or in the projects MAINTAINERS
+files.
-### Project Lead
+### Security Response Team
-Sub-projects and teams hosted on Xenproject.org are managed by a Project Lead,
-who also is a committer of the sub-project/team he/she leads. Project Leads are
-the public figurehead of the project and is responsible for the health of the
-project. Due to their status in the community, project leads can also act as
-referees should disagreements amongst committers of the project arise. The
-project lead typically also has write access to resources, such as the web page
-of a specific project.
+Each sub-project may have a security response team, that is responsible for
+receiving, reviewing, and responding to security incident reports for the
+sub-projects assets according to its security response process (e.g.
+[Hypervisor Security Problem Response Process](/security-policy.html)).
+
+### Project Leadership Team and Project Lead
+
+Sub-projects and teams hosted on Xenproject.org are managed by a Project
+Leadership Team. The leadership team is made up of distinguished community
+members, but the exact composition may depend on the sub-project. For example,
+in the case of the Hypervisor sub-project, all committers and the release
+manager, are part of the leadership team. The leadership team owns the
+sub-projects processes, the overall architecture and all assets within the
+project and makes [sub-project wide decisions](#decisions) on behalf of its
+community.
+
+A sub-projects leadership team members are listed on the sub-project's team
+portal (e.g. [Hypervisor team portal](developers/teams/hypervisor.html)).
-------------------------------------------------------------------------------------
- Moved this section
+ CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+ - XAPI and Mirage OS ought to decide who their leadership team is
+ (I made some assumptions for now)
-------------------------------------------------------------------------------------
+The Leadership Team may elect a Project Lead who is also a member of the
+Leadership Team. Project Leads are the public figurehead of the project and are
+responsible for the health of the project. Project Leads can also act as
+[referees](#conflict) should the Project Leadership Team become paralysed.
+
Making Contributions {#contributions}
--------------------
@@ -175,102 +231,330 @@ More information on making contributions can be found in the following
documents:
- [Contribution Guidelines](/help/contribution-guidelines.html)
-
- -------------------------------------------------------------------------------------
- Consolidated all Decision Making Related topics into one section
- - I changed the order of the sections from ...
- "Consensus Decision Making, Conflict Resolution, Elections and Formal Votes" to
- "Consensus Decision Making, Formal Votes, Conflict Resolution, Elections"
- - I changed header titles and fixed the headline
-
- Otherwise the relevant sections remain identical, with the exception of comment
- sections that I added, which highlight issues that are to be addressed.
- -------------------------------------------------------------------------------------
+- [Review Then Commit Policy](#RTC)
Decision Making, Conflict Resolution, Role Nominations and Elections {#decisions}
--------------------------------------------------------------------
+Sub-projects or teams hosted on Xenproject.org are normally auto-governing and
+driven by the people who volunteer for the job. This functions well for most
+cases. This section lists the main mechanisms by which projects make decisions.
+This section lists the default mode of operation, which is based on how the
+Hypervisor project operates. Sub-projects can deviate from the default, but are
+required to document deviations from the default and link to it from this
+[document](#specialisation). The only exception is that each project is
+required to adhere to the **Review Then Commit Policy**, **Leadership Team
+Decisions** and **Conflict Resolution**.
+
-------------------------------------------------------------------------------------
- ISSUES TO BE ADDRESSED LATER:
- - Add a pre-amble explaining the different decision making mechanisms and when they
- apply
- - Add a section about review and commit, which is the primary means of making
- code related decisions
+ TODO, after this section is agreed, or mostly agreed
+ - Add a table of the projects that states who adheres to the default
+ - I believe that the Hypervisor, winPV and XAPI are likely to adhere to this section
-------------------------------------------------------------------------------------
-### Consensus Decision Making
+### Review Then Commit {#RTC}
+
+The vast majority of technical decisions within the Xen Project are code
+related decisions (e.g. patches and design documents), which determine whether
+a specific change can be accepted into the code base. The default decision
+making process is a review and commit process, which requires that all changes
+receive explicit approval from respective code owners (maintainers) before they
+are committed. The exact workflow and details of this policy between
+sub-projects may differ and are documented in one or several of the following
+places: MAINTAINERS/README/CONTRIBUTING files in repositories and/or the
+sub-project team portal.
+
+### Expressing Agreement and Disagreement {#expressingopinion}
+
+
+Within the community, we follow the following number notation to explicitly
+express opinions on proposals, formal or informal votes.
+
+- **+2** : I am happy with this proposal, and I will argue for it
+- **+1** : I am happy with this proposal, but will not argue for it
+- **0** : I have no opinion
+- **-1** : I am not happy with this proposal, but will not argue against it
+- **-2** : I am not happy with this proposal, and I will argue against it
+
+A **-2** should include an alternative proposal or a detailed explanation of
+the reasons for the negative opinion. A **+2** should include reasons for the
+positive opinion.
+
+How we tally results and their implications depend on the context in which is
+is used and are marked with Passed/Failed: in one of the following sections:
+
+- [Lazy Consensus](#lazyconsensus)
+- [Leadership Team Decisions](#leadership)
+- [Project Wide Decision Making](#project-decisions)
+
+### Lazy Consensus {#lazyconsensus}
+
+Lazy Consensus is a useful technique to make decisions for specific proposals
+which are not covered by the Review Then Commit Policy or do not require a more
+formal decison (see below). Lazy Consensus is extremely useful, when you don't
+anticipate any objections, or to gage whether there are objections to a
+proposal. To make use of it, post something like the following on the project's
+mailing list (or some other communication channel):
-------------------------------------------------------------------------------------
- ISSUES TO BE ADDRESSED LATER:
- - The "Consensus Decision Making" section is totally wrong. It does not describe
- "Lazy Consensus"
+ Should we set a fixed time-frame? If so what?
-------------------------------------------------------------------------------------
-Sub-projects or teams hosted on Xenproject.org are normally auto-governing and
-driven by the people who volunteer for the job. This functions well for most
-cases. When more formal decision making and coordination is required, decisions
-are taken with a lazy consensus approach: a few positive votes with no negative
-vote are enough to get going.
+ > I am assuming we are agreed on X and am going to assume lazy consensus: <
+ > if there are no objections within the next seven days. <
+
+You should however ensure that all relevant stake-holders which may object are
+explicitly CC'ed, such as relevant maintainers or committers, ensure that
+**lazy consensus** is in the body of your message (this helps set up mail
+filters) and choose a reasonable time-frame. If it is unclear who the relevant
+stake-holders are, the project leadership can nominate a group of stake-holders
+to decide, or may choose to own the decision collectively and resolve it.
+
+Objections by stake-holders should be expressed using the [conventions
+above](#expressingopinion) to make disagreements easily identifiable.
+
+__Passed/Failed:__
+
+- Failed: A single **-2** by a stake-holder whose approval is necessary
+- Failed: **-1**'s by all stake-holder whose approval is necessary
+- Passed: In all other situations
+
-------------------------------------------------------------------------------------
- - Introduce -2 to +2 voting under a new section
+ I added the following section, as we did have real cases like this in the past.
+ In particular an issue may not have been highlighted to all the relevant people in
+ time.
-------------------------------------------------------------------------------------
-Voting is done with numbers:
+It can only be overturned if the project leadership agrees collectively, that
+the decision is too important to be settled by lazy consensus. In situations
+where a proposal is failed, an alternative solution needs to be found, or if a
+decision is formally challenged, [conflict resolution mechanisms](#conflict)
+may need to be used to resolve the situation.
-- +1 : a positive vote
-- 0 : abstain, have no opinion
-- -1 : a negative vote
+### Informal Votes or Surveys
-A negative vote should include an alternative proposal or a detailed
-explanation of the reasons for the negative vote. The project community then
-tries to gather consensus on an alternative proposal that resolves the issue.
-In the great majority of cases, the concerns leading to the negative vote can
-be addressed.
+ -------------------------------------------------------------------------------------
+ RATIONALE for the following section:
+ in practice, we have always operated this way. We did this, when we introduced the
+ security vulnerability process and for other controversial changes.
+ -------------------------------------------------------------------------------------
-### Conflict Resolution
+Generally the Xen Project community tries to achieve consensus on most issues.
+In situations where several concrete options are possible, community members
+may organize an informal vote on the different proposals and use the
+[conventions above](#expressingopinion) to identify the strongest proposal.
+Once the strongest candidate has been identified, [lazy
+consensus](#lazyconsensus) could be used to close the discussion. In some
+situation, a specific survey may need to be created, to help identify gaging
+consensus on specific issues. For informal votes and surveys, we do not
+prescribe specific rules, as they are non-binding: it is up to the organizer of
+an informal vote or survey to interpret the result and explain it to the
+community. If the vote/survey relates to an area that is owned by the project
+leadership, the project leadership has to formally confirm the decision.
+
+Note that informal votes amongst a small set of stake-holders that disagree on
+a position during technical disagreements in code, design reviews and other
+discussions can be useful. In technical discussions it is not always clear how
+strong agreement or disagreement on a specific issue is. Using the [conventions
+above](#expressingopinion), can help differentiate between minor and major
+disagreements and reduce the time a discussions continues unnecessarily. This
+is true in particular for cases, where several maintainers may need to agree to
+a proposal.
+
+When having an informal vote or survey, they creator should consider whether
+conducting a vote or survey in public, may be divisive and damaging for the
+community. In such cases, the vote/survey should be conducted anonomously.
-------------------------------------------------------------------------------------
- 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
+ The following section represents the most significant change to the governance. In
+ the original governance document, we had one way of making project-local decisions
+ through a formal vote on proposals by maintainers. Unfortunately, in the original
+ governance document, tallying the vote is not specified. However, in the general
+ section about how we make decisions, we essentially say that decisions in general
+ only hold, if there are no objections (vetos). As some people stated in prior
+ discussion this gets as to "a UN-style model that requires unanimity".
+
+ If we end up with disagreements, we then have conflict resolution mechanisms, which
+ require a simple majority by committers.
+
+ This raises the question, why we don't go for a more unified approach for decisions,
+ that does not require two stages. In a number of previous discussions on xen-devel@
+ it was proposed by several committers, that a majority based approach, with more than
+ a simple majority as requirement for making decisions (e.g. 2/3rds or 75%) may be
+ more desirable.
+
+ This section attempts to
+ - optimise, consolidate and clarify formal decision making
+ - in particular in situations where it is not clear who owns a decision
+ - and use the same decision making mechanism for *all* types of decisions that
+ cannot be resolved by RTC and Lazy Consensus
+ - The exception is Project Wide Decision Making
-------------------------------------------------------------------------------------
-#### Refereeing
+### Leadership Team Decisions {#leadership}
+
+Each sub-project has a leadership team, which is typically made up of the most
+senior and influential developers within the sub-project (e.g. the project's
+committers). The project leadership team owns decisions, such as:
+
+- Sub-project wide policy decisions (e.g. policies, procedures and processes
+whose scope is specific to the sub-projects). This includes deviations from
+project global governance, where permissible.
+- Decisions related to sub-project assets that are not clearly owned (e.g.
+unowned code, project wide assets such as test infrastructure, etc.).
+- Decisions related to nominating and confirming leadership roles within the
+sub-project. This includes [decisions to creating and filling specialised new
+roles](#elections), such as release managers or similar, including their scope
+and set of responsibilities.
+- Resolving [conflicts](#conflict) within the sub-project that cannot
+otherwise be resolved.
+
+Leadership team decisions can be made in private (e.g. a private IRC meeting,
+on a private mailing list, through a private vote) or on a public mailing list
+using [decision making conventions](#expressingopinion). If a decision is made
+in private, the outcome must be summarized in terms of number of votes in
+favour or against on a public mailing list. Decisions should **not** generally
+be made in an anonymous vote, unless there is a good reason to do so. For
+example, if the decision may be divisive and damage the cohesion of the
+leadership team, an anonymous vote is preferred. In such cases, the leadership
+team, can ask the the community manager, to arrange an anonymous vote on behalf
+of the leadership team.
-Sub-projects and teams hosted on Xenproject.org are not democracies but
-meritocracies. In situations where there is disagreement on issues related to
-the day-to-day running of the project, Committers and Project Leads are
-expected to act as referees and make a decision on behalf of the community.
-Referees should however consider whether making a decision may be divisive and
-damaging for the community. In such cases, the committer community of the
-project can privately vote on an issue, giving the decision more weight.
+ -------------------------------------------------------------------------------------
+ The exact majority needed is up for discussion: 2/3rd majority is just a stake
+ in the ground. However, the examples below show that this seems to be a sensible
+ approach to decision making.
+ -------------------------------------------------------------------------------------
+
+Decisions (also called Resolutions) require a **2/3rd** majority amongst active
+leadership team members in favour of a proposal. The tallying of votes follows
+the rules outlined below. Note that a minimum of 3 leadership team members is
+needed for a [leadership team to function](#exceptional-circumstances).
+
+Leadership team decisions normally have to be made actively: in other words
+each team member has to cast a vote **explicitly** expressing their opinion.
+The only exception are face-2-face or on-line meetings with a quorum of
+**2/3rd** of active leadership team members present at the meeting: in such
+cases a meeting chair is required who calls for decision on a resolution and
+asks for objections. This allows to conduct meetings more quickly.
+
+__Passed/Failed Resolutions:__
+
+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.
+
+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
+ ---------------------------- --- -- -- -- -- -- -- -- --
+
+ -------------------------------------------------------------------------------------
+ This comment section contains some examples that have influenced the section above.
+
+ Let me express this as an algorithm.
+
+ treshhold=2/3;
+ active='number of active members'; (7 for the Hypervisor project; IanC is inactive)
+ favour='number of +1 and +2 votes'
+ against='number of -1 and -2 votes'
+ strong-against='number -2 votes'; just added this as a sanity check
+
+ 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.
+
+ In that case:
+
+ active -= 0-votes;
+
+ Without the 0-rule:
+ - to pass: favour/active >= treshhold
+ to pass: with active==7, favour >= 5
+ in other words, 3 (0,-1,-2)-votes block the proposal as we cant achieve favour>=5
+
+ With the 0-rule, let's consider 1, 2 or 3 0-votes
+ 1=>6: to pass: favour >=4
+ in other words, 3 (-1,-2)-votes block the proposal
+ 2=>5: to pass: favour >=4
+ in other words, 2 (-1,-2)-vote blocks the proposal
+ 3=>4: to pass: favour >=3
+ in other words, 2 (-1,-2)-vote blocks the proposal
+
+ Looking at the arithmetic, it does probably make sense to go for the 0-rule. If we
+ do, there ought to be more votes in favour of a proposal, than 0-votes.
+
+ On the other hand, not having the 0-rule forces everyone to form an opinion,
+ otherise we will find it hard to make decisions. But in some cases, forming an
+ opinion costs significant mental capacity.
+
+ It would also allow us to remove the complexity of differentiating between
+ active and non-active leadership team members by assuming that no vote, equals
+ a "0" vote.
+
+ Opinions?
-#### Last Resort
+ 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
-In some rare cases, the lazy consensus approach may lead to the community being
-paralyzed. Thus, as a last resort when consensus cannot be achieved on a
-question internal to a project, the final decision will be made by a private
-majority vote amongst the committers and project lead. If the vote is tied, the
-project lead gets an extra vote to break the tie.
+ Without the 0-rule:
+ 2 -2-votes would block a proposal (instead of 3 (0,-1,-2)-votes)
-For questions that affect several projects, committers and project leads of
-mature projects will hold a private majority vote. If the vote is tied, the
-[Xen Project Advisory Board](/join.html) will break the tie through a casting
-vote.
+ With the 0-rule
+ 1=>6: 2 -2-votes would block a proposal
+ 2=>5: 1 -2-votes would block a proposal
+ 3=>4: 1 -2-votes would block a proposal
+
+ This doesn't seem to make a difference big enough to grant the extra complexity.
+
+ Opinions?
+
+ -------------------------------------------------------------------------------------
+
+### Conflict Resolution {#conflict}
+
+Sub-projects and teams hosted on Xenproject.org are not democracies but
+meritocracies. In situations where there is disagreement on issues related to
+the day-to-day running of the project, the [project leadership
+team](#leadership) is expected to act as referee and make a decision on behalf
+of the community. Projects leadership teams can choose to delegate entire
+classes of conflict resolution issues to community members and/or the project
+lead (e.g. the project can choose to delegate refereeing on committer
+disagreements to the project lead; or it could choose a specific committer to
+always act as referee amongst a group of committers). Any such delegation needs
+to be approved as normal and has to be documented.
+
+Should a project leadership team become dysfunctional or paralysed, the project
+leadership team or project lead should work with the community manager or
+advisory board to find a way forward.
+
+In situations where there is significant disagreement between sub-projects, the
+issue is deferred to the [Xen Project Advisory Board](/join.html).
-------------------------------------------------------------------------------------
- Changed headline structure: h2 to h3
- Removed Formal Votes from headline as it has been moved into a separate section
+ The entire last resourt section goes, because it is essentially not needed any more,
+ as the responsibility has been moved to the project leadership, which is now making
+ majority based decisions.
-------------------------------------------------------------------------------------
-### Elections
+### Elections {#elections}
#### Maintainer Elections
-Developers who have earned the trust of maintainers (including the project
-lead) can be promoted to Maintainer. A two stage mechanism is used
+Developers who have earned the trust of existing maintainers can be promoted to
+maintainer. A two stage mechanism is used
- Nomination: A maintainer should nominate himself by proposing a patch to
the MAINTAINERS file or mailing a nomination to the project's mailing list.
@@ -280,15 +564,15 @@ as a scope (set of owned components). Where the case is not obvious, evidence
such as specific patches and other evidence supporting the nomination should be
cited.
- Confirmation: Normally, there is no need for a direct election to confirm a
-new maintainer. Discussion should happen on the mailing list using the
-principles of consensus decision making. If there is disagreement or doubt, the
-project lead or a committer should ask the community manager to arrange a more
-formal vote.
+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 Elections
+#### Committer, Security Team Member and other Project Leadership Elections
Developers who have earned the trust of committers in their project can through
-election be promoted to Committer. A two stage mechanism is used
+election be promoted to Committer, Security Team Member 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
@@ -299,75 +583,119 @@ 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).
#### Project Lead Elections
-Projects which lose their project lead are at risk of failing. Should this
-occur, the project's maintainer community should agree who would want to be/be
-able to be the new project lead and follow the election process as outlined
-above.
-
-Formal Votes {#formal-votes}
-------------
-
- -------------------------------------------------------------------------------------
- ISSUES TO BE ADDRESSED LATER:
- - Local votes should be handled elsewhere: this section should only cover global
- decision making
- - Better specify scope : when are Formal Votes applicable
- - In fact we do not have any clear rules for tallying votes (do votes have to be
- unanimous or not)
- - Note that the voting eligibility is maintainers? Do we want to retain this?
- I assume NO, as in practive we never did this.
- -------------------------------------------------------------------------------------
+Projects which have a project lead, should vote for a project lead in an
+anonymous vote amongst the project leadership.
+
+### Project Wide Decision Making {#project-decisions}
+
+Project wide decisions are made through **formal global votes** and are
+conducted in rare circumstances only, following the principle of [local
+decision making](#principles). Global votes are only needed, when all sub-projects
+hosted on Xenproject.org are affected. This is true, only for:
+
+- Specific votes on creating, graduating, completing/archiving of
+sub-projects as outlined in [project governance](#project-governance).
+- Changes to this document, where sub-projects cannot specialise. In
+particular the sections: [goals](#goals), [principles](#principles), [project
+wide decision making](#project-decisions) and [project
+governance](#project-governance) (and small parts of [Xen Project wide
+roles](#roles-global), [project team roles](#roles-local) and [decision
+making](#decisions) that are needed for project governance or **apply to all
+sub-projects** as stated in those sections).
+- Changes to this document where sub-projects can specialise require at least
+one mature project other than the Hypervisor project to be impacted
+significantly by the change. The sections in question, are [project team
+roles](#roles-local) and [decision making](#decisions). These sections define
+the **gold standard** of how the original Hypervisor Project operates. In other
+cases, the Hypervisor project leadership team can agree changes to these
+sections, as they are essentially reference definitions. Other sub-projects
+have to be consulted, and have to be given time to adapt to changes.
+- Changes to existing global namespace policies (e.g. [Mailing List
+Conventions](/help/mailing-list/100-misc/139-mailing-list-conventions.html))
+and creation of new project wide namespace policies.
+- Changes to the boundary of what policies are project local and global
+decision: e.g. a decision to introduce a global Security Vulnerability Response
+Process that affects all sub-projects.
+- Some sections of this document such as [Xen Project wide
+roles](#roles-global) and [making contributions](#contributions) **cannot be
+changed by the community** without obtaining additional approval from the
+Advisory Board and/or the Linux Foundation, if these conflict requirements that
+stem from being part of a Linux Foundation Collaborative Project (e.g requiring
+a contributor license agreement). Areas with such requirements cover
+trademarks, legal oversight, financial oversight and project funding.
+
+Global votes are arranged by the community manager when needed (e.g. for a
+project review or a global process change). Who exactly has input on a proposal
+and can vote on it, depends on the type of change as outlined below:
+
+ -----------------------------------------------------------------------------------------
+ **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.
+ -----------------------------------------------------------------------------------------
-Sometimes it is necessary to conduct formal voting within the community
-(outside of elections). Formal votes are necessary when processes and
-procedures are introduced or changed, or as part of the [Project
-Governance](#project-governance). Who is eligible to vote, depends on whether
-the scope of a process or procedure is **local** to a sub-project or team, or
-whether it affects **all sub-projects** (or in other words, is** global**).
-Examples of local scope is the [Security Policy](/security-policy.html) which
-applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only.
-Examples of global scope are changes to this document or votes outlined in the
-Project Governance.
-
- -----------------------------------------------------------------------------
- **Scope** **Who reviews?** **Who votes?**
- ------------ ---------------------- -----------------------------------------
- **Local** Members of developer Maintainers of the project (or projects),
- mailing lists of the which are affected by the process,
- affected projects. procedure, etc. are allowed to vote.
- This includes maintainers from incubation
- projects (if the scope affects the
- project).
-
- **Global** Members of all Maintainers of **all mature** projects
- developer mailing and the Xenproject.org community manager
- lists of all are allowed to vote.
- sub-projects hosted on
- Xenproject.org.
- -----------------------------------------------------------------------------
-\
The community manager first arranges a public review, followed by a timed
private vote. Public review and voting should be open for a minimum of a week
each. For voting a traceable poll mechanism (e.g. voting form that keeps
-auditable and tamper proof records) must be used. Voting follows the
-conventions as laid out in "Principle: Consensus Decision Making".
-
+auditable and tamper proof records) must be used.
+
+Voting is conducted **per project** in line with the following rules:
+
+- Each qualifying project's vote is counted per project and then aggregated
+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
+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.
+
+__Passed/Failed Resolutions:__
+
+- If none of the qualifying projects achieve a quorum, the change cannot
+hold. In that case, we consider that there is not enough momentum behind a
+change.
+- 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.
+
+Project Governance {#project-governance}
+------------------
+
-------------------------------------------------------------------------------------
ISSUES TO BE ADDRESSED LATER:
- Verify terminology in light of changes above
+ - But let's agree the previous set of sections first
-------------------------------------------------------------------------------------
-Project Governance {#project-governance}
-------------------
### Basic Project Life Cycle
@@ -430,7 +758,7 @@ After a review, the requester of the review may decide to withdraw, request a
re-review or progress to a vote by arranging with the community manager.
**Voting:** The community manager arranges a timed private vote as outlined in
-[Formal Votes](#formal-votes).
+[Formal Votes](#project-decisions).
### Forming a Project
@@ -564,7 +892,7 @@ words it has completed
In the first case the review is triggered by the incubation project's mentor.
Failing this the review can be requested by any maintainer of a mature project
-(including the project's lead) or by the Xen Project community manager. See
+(including the projec's lead) or by the Xen Project community manager. See
"Requesting Reviews, Reviews and Voting".
The review is essentially a pitch why the project should be archived. The
@@ -596,28 +924,56 @@ Xenproject.org, the code will be
remove the code in a subsequent release (it should however give users
sufficient time to adapt)
-### Exceptional Circumstances
+### Exceptional Circumstances {#exceptional-circumstances}
-#### Projects without Project Lead
+#### Incubation Projects without Project Lead
-Projects which lose their project lead during the incubation or maturity phase
-are at risk of failing. Should this occur, the project's maintainer community
-should agree who would want to be/be able to be the new project lead and follow
-the election process as outlined in "Electing Maintainers".
+Projects which lose their project lead during the incubation phase, and do not
+have a working project leadership team, are at risk of failing. Should this
+occur, the project's maintainer or committer community should nominate a new
+project lead and follow the election process as outlined in
+[elections](#elections).
If a project lead leaves during the formation phase, without finding a
-successor we assume that the project does not have enough momentum and will not
-go ahead.
+successor we assume that the project does not have enough momentum and will
+consider archiving the project.
+
+#### Projects without functional Project Leadership Team
+
+Projects which lose their project leadership team, or whose project leadership
+team is too small to function, are at risk of failing. A project leadership
+team should be of sufficient size to manage the project. Should this occur, the
+project's maintainer or committer community should nominate new leadership team
+members and follow the election process as outlined in [elections](#elections).
+
+If the community cannot create a functional leadership team, we assume that the
+project does not have enough momentum and will consider archiving the project.
#### Incubation projects without Mentor
Should an incubation project lose its mentor, the Xen Project community manager
will support the project lead in finding a new mentor.
+Per Sub-Project Governance Specialisation {#specialisations}
+-----------------------------------------
+
+ -------------------------------------------------------------------------------------
+ ISSUES TO BE ADDRESSED LATER:
+ - Add exceptions as they surface
+ -------------------------------------------------------------------------------------
+
Change History
--------------
-- **v3.0 July 2016:** TODO: Add real changelog in main patch
+- **v3.0 August 2016:** Refactored document. Otherwise significant changes to
+decision making, in the following areas
+ - Split roles into project wide and sub-project specific roles.
+ - Added +2 ... -2 scheme for votes.
+ - Clarified lazy consensus.
+ - Added Project Team Leadership role and Decision making.
+ - Changed Project Wide Decision making.
+ - Clarified scope of Decision making
+ - Modified sections which have dependencies on changes above.
- **v2.1 May 2016:** Clarify Committer Elections as per this
[discussion](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg0080
1.html) and
--
2.5.4 (Apple Git-61)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <1470957226-18139-4-git-send-email-lars.kurth@citrix.com>
@ 2016-08-12 12:41 ` Jan Beulich
[not found] ` <57ADDFFF0200007800105745@prv-mh.provo.novell.com>
` (3 subsequent siblings)
4 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2016-08-12 12:41 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, xen-devel
>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
> +### Lazy Consensus {#lazyconsensus}
> +
> +Lazy Consensus is a useful technique to make decisions for specific proposals
> +which are not covered by the Review Then Commit Policy or do not require a more
> +formal decison (see below). Lazy Consensus is extremely useful, when you don't
> +anticipate any objections, or to gage whether there are objections to a
> +proposal. To make use of it, post something like the following on the project's
> +mailing list (or some other communication channel):
>
> -------------------------------------------------------------------------------------
> - ISSUES TO BE ADDRESSED LATER:
> - - The "Consensus Decision Making" section is totally wrong. It does not describe
> - "Lazy Consensus"
> + Should we set a fixed time-frame? If so what?
> -------------------------------------------------------------------------------------
>
> -Sub-projects or teams hosted on Xenproject.org are normally auto-governing and
> -driven by the people who volunteer for the job. This functions well for most
> -cases. When more formal decision making and coordination is required, decisions
> -are taken with a lazy consensus approach: a few positive votes with no negative
> -vote are enough to get going.
> + > I am assuming we are agreed on X and am going to assume lazy consensus: <
> + > if there are no objections within the next seven days. <
> +
> +You should however ensure that all relevant stake-holders which may object are
> +explicitly CC'ed, such as relevant maintainers or committers, ensure that
> +**lazy consensus** is in the body of your message (this helps set up mail
> +filters) and choose a reasonable time-frame. If it is unclear who the relevant
> +stake-holders are, the project leadership can nominate a group of stake-holders
> +to decide, or may choose to own the decision collectively and resolve it.
> +
> +Objections by stake-holders should be expressed using the [conventions
> +above](#expressingopinion) to make disagreements easily identifiable.
> +
> +__Passed/Failed:__
> +
> +- Failed: A single **-2** by a stake-holder whose approval is necessary
> +- Failed: **-1**'s by all stake-holder whose approval is necessary
> +- Passed: In all other situations
Hmm, that means all -1's except a single 0 would already be a pass?
> + Let me express this as an algorithm.
> +
> + treshhold=2/3;
> + active='number of active members'; (7 for the Hypervisor project; IanC is inactive)
> + favour='number of +1 and +2 votes'
> + against='number of -1 and -2 votes'
> + strong-against='number -2 votes'; just added this as a sanity check
> +
> + 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.
> +
> + In that case:
> +
> + active -= 0-votes;
> +
> + Without the 0-rule:
> + - to pass: favour/active >= treshhold
> + to pass: with active==7, favour >= 5
> + in other words, 3 (0,-1,-2)-votes block the proposal as we cant achieve favour>=5
> +
> + With the 0-rule, let's consider 1, 2 or 3 0-votes
> + 1=>6: to pass: favour >=4
> + in other words, 3 (-1,-2)-votes block the proposal
> + 2=>5: to pass: favour >=4
> + in other words, 2 (-1,-2)-vote blocks the proposal
> + 3=>4: to pass: favour >=3
> + in other words, 2 (-1,-2)-vote blocks the proposal
> +
> + Looking at the arithmetic, it does probably make sense to go for the 0-rule. If we
> + do, there ought to be more votes in favour of a proposal, than 0-votes.
> +
> + On the other hand, not having the 0-rule forces everyone to form an opinion,
> + otherise we will find it hard to make decisions. But in some cases, forming an
> + opinion costs significant mental capacity.
> +
> + It would also allow us to remove the complexity of differentiating between
> + active and non-active leadership team members by assuming that no vote, equals
> + a "0" vote.
> +
> + Opinions?
I'm in favor of the "with 0-rule" variant.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <57ADDFFF0200007800105745@prv-mh.provo.novell.com>
@ 2016-08-12 12:53 ` Lars Kurth
[not found] ` <D3D38326.2CC31%lars.kurth@citrix.com>
2016-08-12 21:58 ` Stefano Stabellini
2 siblings, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-12 12:53 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, xen-devel
On 12/08/2016 13:41, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
>> +### Lazy Consensus {#lazyconsensus}
>> +
>> +Lazy Consensus is a useful technique to make decisions for specific
>>proposals
>> +which are not covered by the Review Then Commit Policy or do not
>>require a more
>> +formal decison (see below). Lazy Consensus is extremely useful, when
>>you don't
>> +anticipate any objections, or to gage whether there are objections to
>>a
>> +proposal. To make use of it, post something like the following on the
>>project's
>> +mailing list (or some other communication channel):
>>
>>
>>-------------------------------------------------------------------------
>>------------
>> - ISSUES TO BE ADDRESSED LATER:
>> - - The "Consensus Decision Making" section is totally wrong. It
>>does not describe
>> - "Lazy Consensus"
>> + Should we set a fixed time-frame? If so what?
>>
>>-------------------------------------------------------------------------
>>------------
>>
>> -Sub-projects or teams hosted on Xenproject.org are normally
>>auto-governing and
>> -driven by the people who volunteer for the job. This functions well
>>for most
>> -cases. When more formal decision making and coordination is required,
>>decisions
>> -are taken with a lazy consensus approach: a few positive votes with no
>>negative
>> -vote are enough to get going.
>> + > I am assuming we are agreed on X and am going to assume lazy
>>consensus: <
>> + > if there are no objections within the next seven days.
>> <
>> +
>> +You should however ensure that all relevant stake-holders which may
>>object are
>> +explicitly CC'ed, such as relevant maintainers or committers, ensure
>>that
>> +**lazy consensus** is in the body of your message (this helps set up
>>mail
>> +filters) and choose a reasonable time-frame. If it is unclear who the
>>relevant
>> +stake-holders are, the project leadership can nominate a group of
>>stake-holders
>> +to decide, or may choose to own the decision collectively and resolve
>>it.
>> +
>> +Objections by stake-holders should be expressed using the [conventions
>> +above](#expressingopinion) to make disagreements easily identifiable.
>> +
>> +__Passed/Failed:__
>> +
>> +- Failed: A single **-2** by a stake-holder whose approval is
>>necessary
>> +- Failed: **-1**'s by all stake-holder whose approval is necessary
>> +- Passed: In all other situations
>
>Hmm, that means all -1's except a single 0 would already be a pass?
That is not the intention. If we have only -1's and 0's it should be a
fail.
Let me fix this in the next revisions.
How about:
+- Failed: Only **-1** or **0** votes by all stake-holder whose approval
is necessary
Although maybe someone can come up with a clearer way to express this.
>> + Let me express this as an algorithm.
>> +
>> + treshhold=2/3;
>> + active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>> + favour='number of +1 and +2 votes'
>> + against='number of -1 and -2 votes'
>> + strong-against='number -2 votes'; just added this as a sanity
>>check
>> +
>> + 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.
>> +
>> + In that case:
>> +
>> + active -= 0-votes;
>> +
>> + Without the 0-rule:
>> + - to pass: favour/active >= treshhold
>> + to pass: with active==7, favour >= 5
>> + in other words, 3 (0,-1,-2)-votes block the proposal as we cant
>>achieve favour>=5
>> +
>> + With the 0-rule, let's consider 1, 2 or 3 0-votes
>> + 1=>6: to pass: favour >=4
>> + in other words, 3 (-1,-2)-votes block the proposal
>> + 2=>5: to pass: favour >=4
>> + in other words, 2 (-1,-2)-vote blocks the proposal
>> + 3=>4: to pass: favour >=3
>> + in other words, 2 (-1,-2)-vote blocks the proposal
>> +
>> + Looking at the arithmetic, it does probably make sense to go for
>>the 0-rule. If we
>> + do, there ought to be more votes in favour of a proposal, than
>>0-votes.
>> +
>> + On the other hand, not having the 0-rule forces everyone to form
>>an opinion,
>> + otherise we will find it hard to make decisions. But in some
>>cases, forming an
>> + opinion costs significant mental capacity.
>> +
>> + It would also allow us to remove the complexity of differentiating
>>between
>> + active and non-active leadership team members by assuming that no
>>vote, equals
>> + a "0" vote.
>> +
>> + Opinions?
>
>I'm in favor of the "with 0-rule" variant.
That's what I assumed most people would go for and which is (hopefully
correctly)
implemented in the rules above the comment section.
Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <D3D38326.2CC31%lars.kurth@citrix.com>
@ 2016-08-12 13:01 ` Jan Beulich
[not found] ` <57ADE4C10200007800105769@prv-mh.provo.novell.com>
1 sibling, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2016-08-12 13:01 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, xen-devel
>>> On 12.08.16 at 14:53, <lars.kurth@citrix.com> wrote:
> On 12/08/2016 13:41, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
>>> +### Lazy Consensus {#lazyconsensus}
>>> +
>>> +Lazy Consensus is a useful technique to make decisions for specific
>>>proposals
>>> +which are not covered by the Review Then Commit Policy or do not
>>>require a more
>>> +formal decison (see below). Lazy Consensus is extremely useful, when
>>>you don't
>>> +anticipate any objections, or to gage whether there are objections to
>>>a
>>> +proposal. To make use of it, post something like the following on the
>>>project's
>>> +mailing list (or some other communication channel):
>>>
>>>
>>>-------------------------------------------------------------------------
>>>------------
>>> - ISSUES TO BE ADDRESSED LATER:
>>> - - The "Consensus Decision Making" section is totally wrong. It
>>>does not describe
>>> - "Lazy Consensus"
>>> + Should we set a fixed time-frame? If so what?
>>>
>>>-------------------------------------------------------------------------
>>>------------
>>>
>>> -Sub-projects or teams hosted on Xenproject.org are normally
>>>auto-governing and
>>> -driven by the people who volunteer for the job. This functions well
>>>for most
>>> -cases. When more formal decision making and coordination is required,
>>>decisions
>>> -are taken with a lazy consensus approach: a few positive votes with no
>>>negative
>>> -vote are enough to get going.
>>> + > I am assuming we are agreed on X and am going to assume lazy
>>>consensus: <
>>> + > if there are no objections within the next seven days.
>>> <
>>> +
>>> +You should however ensure that all relevant stake-holders which may
>>>object are
>>> +explicitly CC'ed, such as relevant maintainers or committers, ensure
>>>that
>>> +**lazy consensus** is in the body of your message (this helps set up
>>>mail
>>> +filters) and choose a reasonable time-frame. If it is unclear who the
>>>relevant
>>> +stake-holders are, the project leadership can nominate a group of
>>>stake-holders
>>> +to decide, or may choose to own the decision collectively and resolve
>>>it.
>>> +
>>> +Objections by stake-holders should be expressed using the [conventions
>>> +above](#expressingopinion) to make disagreements easily identifiable.
>>> +
>>> +__Passed/Failed:__
>>> +
>>> +- Failed: A single **-2** by a stake-holder whose approval is
>>>necessary
>>> +- Failed: **-1**'s by all stake-holder whose approval is necessary
>>> +- Passed: In all other situations
>>
>>Hmm, that means all -1's except a single 0 would already be a pass?
>
> That is not the intention. If we have only -1's and 0's it should be a
> fail.
> Let me fix this in the next revisions.
>
> How about:
> +- Failed: Only **-1** or **0** votes by all stake-holder whose approval
> is necessary
That would still leave 10 -1's overruled by a single +1.
> Although maybe someone can come up with a clearer way to express this.
Maybe when there are no +2's, simply take the sum of all votes,
and require it to be non-negative?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <57ADDFFF0200007800105745@prv-mh.provo.novell.com>
2016-08-12 12:53 ` Lars Kurth
[not found] ` <D3D38326.2CC31%lars.kurth@citrix.com>
@ 2016-08-12 21:58 ` Stefano Stabellini
2 siblings, 0 replies; 18+ messages in thread
From: Stefano Stabellini @ 2016-08-12 21:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Lars Kurth, xen-api, committers, mirageos-devel, xen-devel, win-pv-devel
On Fri, 12 Aug 2016, Jan Beulich wrote:
> > + Let me express this as an algorithm.
> > +
> > + treshhold=2/3;
> > + active='number of active members'; (7 for the Hypervisor project; IanC is inactive)
> > + favour='number of +1 and +2 votes'
> > + against='number of -1 and -2 votes'
> > + strong-against='number -2 votes'; just added this as a sanity check
> > +
> > + 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.
> > +
> > + In that case:
> > +
> > + active -= 0-votes;
> > +
> > + Without the 0-rule:
> > + - to pass: favour/active >= treshhold
> > + to pass: with active==7, favour >= 5
> > + in other words, 3 (0,-1,-2)-votes block the proposal as we cant achieve favour>=5
> > +
> > + With the 0-rule, let's consider 1, 2 or 3 0-votes
> > + 1=>6: to pass: favour >=4
> > + in other words, 3 (-1,-2)-votes block the proposal
> > + 2=>5: to pass: favour >=4
> > + in other words, 2 (-1,-2)-vote blocks the proposal
> > + 3=>4: to pass: favour >=3
> > + in other words, 2 (-1,-2)-vote blocks the proposal
> > +
> > + Looking at the arithmetic, it does probably make sense to go for the 0-rule. If we
> > + do, there ought to be more votes in favour of a proposal, than 0-votes.
> > +
> > + On the other hand, not having the 0-rule forces everyone to form an opinion,
> > + otherise we will find it hard to make decisions. But in some cases, forming an
> > + opinion costs significant mental capacity.
> > +
> > + It would also allow us to remove the complexity of differentiating between
> > + active and non-active leadership team members by assuming that no vote, equals
> > + a "0" vote.
> > +
> > + Opinions?
>
> I'm in favor of the "with 0-rule" variant.
I am also in favor of the 0-rule
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <57ADE4C10200007800105769@prv-mh.provo.novell.com>
@ 2016-08-13 9:28 ` Lars Kurth
[not found] ` <D3D4A690.2CCCF%lars.kurth@citrix.com>
1 sibling, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-13 9:28 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-api, win-pv-devel, committers, mirageos-devel, xen-devel
On 12/08/2016 14:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 12.08.16 at 14:53, <lars.kurth@citrix.com> wrote:
>> On 12/08/2016 13:41, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
>>>> +### Lazy Consensus {#lazyconsensus}
>>>> +
>>>>[snip]
>>>> +
>>>> +Objections by stake-holders should be expressed using the
>>>>[conventions
>>>> +above](#expressingopinion) to make disagreements easily identifiable.
>>>> +
>>>> +__Passed/Failed:__
>>>> +
>>>> +- Failed: A single **-2** by a stake-holder whose approval is
>>>>necessary
>>>> +- Failed: **-1**'s by all stake-holder whose approval is necessary
>>>> +- Passed: In all other situations
>>>
>>>Hmm, that means all -1's except a single 0 would already be a pass?
>>
>> That is not the intention. If we have only -1's and 0's it should be a
>> fail.
>> Let me fix this in the next revisions.
>>
>> How about:
>> +- Failed: Only **-1** or **0** votes by all stake-holder whose
>>approval
>> is necessary
>
>That would still leave 10 -1's overruled by a single +1.
>
>> Although maybe someone can come up with a clearer way to express this.
>
>Maybe when there are no +2's, simply take the sum of all votes,
>and require it to be non-negative?
That would work. Any other opinions?
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <1470957226-18139-4-git-send-email-lars.kurth@citrix.com>
2016-08-12 12:41 ` Jan Beulich
[not found] ` <57ADDFFF0200007800105745@prv-mh.provo.novell.com>
@ 2016-08-15 10:59 ` Tim Deegan
[not found] ` <20160815105913.GA21763@deinos.phlegethon.org>
2016-08-26 11:59 ` Wei Liu
4 siblings, 0 replies; 18+ messages in thread
From: Tim Deegan @ 2016-08-15 10:59 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel, win-pv-devel, committers, mirageos-devel, xen-api
Hi,
At 00:13 +0100 on 12 Aug (1470960826), Lars Kurth wrote:
> +### Conflict Resolution {#conflict}
> +
> +Sub-projects and teams hosted on Xenproject.org are not democracies but
> +meritocracies. In situations where there is disagreement on issues related to
> +the day-to-day running of the project, the [project leadership
> +team](#leadership) is expected to act as referee and make a decision on behalf
> +of the community. Projects leadership teams can choose to delegate entire
> +classes of conflict resolution issues to community members and/or the project
> +lead (e.g. the project can choose to delegate refereeing on committer
> +disagreements to the project lead; or it could choose a specific committer to
> +always act as referee amongst a group of committers). Any such delegation needs
> +to be approved as normal and has to be documented.
> +
> +Should a project leadership team become dysfunctional or paralysed, the project
> +leadership team or project lead should work with the community manager or
> +advisory board to find a way forward.
> +
> +In situations where there is significant disagreement between sub-projects, the
> +issue is deferred to the [Xen Project Advisory Board](/join.html).
This looks like a pretty significant shift of responsibilty to the AB.
As I read it, the current governance requires a _vote_ if subprojects
disagree, with the AB only called to break a tie.
It also seems to conflict with the wording that the AB "leaves all
technical decisions to the open source meritocracy".
IMO if this is to be changed it should be to something more concrete
than "significant disagreement".
> +- Some sections of this document such as [Xen Project wide
> +roles](#roles-global) and [making contributions](#contributions) **cannot be
> +changed by the community** without obtaining additional approval from the
> +Advisory Board and/or the Linux Foundation, if these conflict requirements that
> +stem from being part of a Linux Foundation Collaborative Project (e.g requiring
> +a contributor license agreement). Areas with such requirements cover
> +trademarks, legal oversight, financial oversight and project funding.
Again, this is a change from the current governance, which just
delegates those things to the AB and leaves it at that (with the
implication that the project as a whole controls its own governance).
IMO it would be better to leave the AB wording as it is, and refer to
a _specific_ LF policy document in the section on the LF.
Or if people want a section like this then it should be a clear list
of exactly which things require approval from which bodies, with no
"such as" or similar, so there is no confusion later.
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <20160815105913.GA21763@deinos.phlegethon.org>
@ 2016-08-15 14:55 ` Lars Kurth
[not found] ` <D3D77FC9.2CDA3%lars.kurth@citrix.com>
1 sibling, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-15 14:55 UTC (permalink / raw)
To: Tim (Xen.org)
Cc: xen-devel, win-pv-devel, committers, mirageos-devel, xen-api
Hi Tim,
>At 00:13 +0100 on 12 Aug (1470960826), Lars Kurth wrote:
>> +### Conflict Resolution {#conflict}
>> +
>> +Sub-projects and teams hosted on Xenproject.org are not democracies
>>but
>> +meritocracies. In situations where there is disagreement on issues
>>related to
>> +the day-to-day running of the project, the [project leadership
>> +team](#leadership) is expected to act as referee and make a decision
>>on behalf
>> +of the community. Projects leadership teams can choose to delegate
>>entire
>> +classes of conflict resolution issues to community members and/or the
>>project
>> +lead (e.g. the project can choose to delegate refereeing on committer
>> +disagreements to the project lead; or it could choose a specific
>>committer to
>> +always act as referee amongst a group of committers). Any such
>>delegation needs
>> +to be approved as normal and has to be documented.
>> +
>> +Should a project leadership team become dysfunctional or paralysed,
>>the project
>> +leadership team or project lead should work with the community manager
>>or
>> +advisory board to find a way forward.
>> +
>> +In situations where there is significant disagreement between
>>sub-projects, the
>> +issue is deferred to the [Xen Project Advisory Board](/join.html).
>
>This looks like a pretty significant shift of responsibilty to the AB.
>As I read it, the current governance requires a _vote_ if subprojects
>disagree, with the AB only called to break a tie.
>
>It also seems to conflict with the wording that the AB "leaves all
>technical decisions to the open source meritocracy".
>
>IMO if this is to be changed it should be to something more concrete
>than "significant disagreement".
That was not intentional. It crept in, because I wanted to avoid repeating
the phrase I used in the previous paragraph, purely for style reasons.
A bit of background on my thinking
A) The AB never felt comfortable with the tie-breaker scenario
B) The new voting model doesn't require the AB to be a tie maker any more
C) It does spell out the areas where AB sign-off is needed regardless of
Community votes more clearly (in practice mostly it will primarily in
areas where funds are needed to implement something)
See your comment below
D) Also, from a scope perspective, global votes would only ever be about
non-technical issues, such as policy
But I see your point. The text should really have said something like...
-----
In situations where the entire Xen Project community becomes paralysed,
the project leaderships team or project lead should work with the
community
manager or advisory board to find a way forward.
-----
It would be nice to list an examples of "becoming paralysed", but
I can't think of anything.
>> +- Some sections of this document such as [Xen Project wide
>> +roles](#roles-global) and [making contributions](#contributions)
>>**cannot be
>> +changed by the community** without obtaining additional approval from
>>the
>> +Advisory Board and/or the Linux Foundation, if these conflict
>>requirements that
>> +stem from being part of a Linux Foundation Collaborative Project (e.g
>>requiring
>> +a contributor license agreement). Areas with such requirements cover
>> +trademarks, legal oversight, financial oversight and project funding.
>
>Again, this is a change from the current governance, which just
>delegates those things to the AB and leaves it at that (with the
>implication that the project as a whole controls its own governance).
I can see how this comes across. I will lay out my thoughts after answering
your other concerns.
>IMO it would be better to leave the AB wording as it is, and refer to
>a _specific_ LF policy document in the section on the LF.
I am lost now: there is not much wording related to the Advisory Board
in the original governance at all (except where the AB is defined). I
could
take this entire paragraph out, as in fact we did not have it and we
Managed well. In practice, people would just come to me when there were
grey
areas.
>
>Or if people want a section like this then it should be a clear list
>of exactly which things require approval from which bodies, with no
>"such as" or similar, so there is no confusion later.
That's a problem, because there are no public documents listing these.
For example, there is no published document which says, collaborative
Projects must not have a CLA. But we were told that me must never
introduce one, when we became an LF project.
I put this section in, because in practice community members do tend
to come to me (as member of the AB) when it comes to funding stuff: e.g.
build and CI infra for the Win PV driver project, ... but these were
project local things. And we had past instances when an AB member
raised concrete issues (e.g. in 2012 a number of contributors were really
Unhappy that we didn't have a release and roadmap process). But in
hindsight,
This paragraph doesn't add much and isn't really needed.
I think we have two options:
A) A delete this bullet entirely
B) Replace it with something clearer - even though, the location
for such a paragraph is wrong.
My gut feel is to just go for A.
Any objections?
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <D3D77FC9.2CDA3%lars.kurth@citrix.com>
@ 2016-08-16 5:32 ` Tim Deegan
[not found] ` <20160816053231.GA5720@deinos.phlegethon.org>
1 sibling, 0 replies; 18+ messages in thread
From: Tim Deegan @ 2016-08-16 5:32 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel, win-pv-devel, committers, mirageos-devel, xen-api
Hi,
At 14:55 +0000 on 15 Aug (1471272946), Lars Kurth wrote:
> But I see your point. The text should really have said something like...
> -----
> In situations where the entire Xen Project community becomes paralysed,
> the project leaderships team or project lead should work with the
> community
> manager or advisory board to find a way forward.
> -----
Sure. I think that's good.
> I think we have two options:
> A) A delete this bullet entirely
> B) Replace it with something clearer - even though, the location
> for such a paragraph is wrong.
>
> My gut feel is to just go for A.
Sounds good to me.
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <D3D4A690.2CCCF%lars.kurth@citrix.com>
@ 2016-08-26 11:49 ` Wei Liu
[not found] ` <20160826114902.GH2590@citrix.com>
1 sibling, 0 replies; 18+ messages in thread
From: Wei Liu @ 2016-08-26 11:49 UTC (permalink / raw)
To: Lars Kurth
Cc: Wei Liu, Jan Beulich, xen-api, committers, mirageos-devel,
xen-devel, win-pv-devel
On Sat, Aug 13, 2016 at 09:28:49AM +0000, Lars Kurth wrote:
>
>
> On 12/08/2016 14:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>>> On 12.08.16 at 14:53, <lars.kurth@citrix.com> wrote:
> >> On 12/08/2016 13:41, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
> >>>> +### Lazy Consensus {#lazyconsensus}
> >>>> +
> >>>>[snip]
> >>>> +
> >>>> +Objections by stake-holders should be expressed using the
> >>>>[conventions
> >>>> +above](#expressingopinion) to make disagreements easily identifiable.
> >>>> +
> >>>> +__Passed/Failed:__
> >>>> +
> >>>> +- Failed: A single **-2** by a stake-holder whose approval is
> >>>>necessary
> >>>> +- Failed: **-1**'s by all stake-holder whose approval is necessary
> >>>> +- Passed: In all other situations
> >>>
> >>>Hmm, that means all -1's except a single 0 would already be a pass?
> >>
> >> That is not the intention. If we have only -1's and 0's it should be a
> >> fail.
> >> Let me fix this in the next revisions.
> >>
> >> How about:
> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
> >>approval
> >> is necessary
> >
> >That would still leave 10 -1's overruled by a single +1.
> >
> >> Although maybe someone can come up with a clearer way to express this.
> >
> >Maybe when there are no +2's, simply take the sum of all votes,
> >and require it to be non-negative?
>
> That would work. Any other opinions?
When there are no +2's *and -2's* ?
> Lars
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <1470957226-18139-4-git-send-email-lars.kurth@citrix.com>
` (3 preceding siblings ...)
[not found] ` <20160815105913.GA21763@deinos.phlegethon.org>
@ 2016-08-26 11:59 ` Wei Liu
4 siblings, 0 replies; 18+ messages in thread
From: Wei Liu @ 2016-08-26 11:59 UTC (permalink / raw)
To: Lars Kurth
Cc: Wei Liu, xen-api, committers, mirageos-devel, xen-devel, win-pv-devel
On Fri, Aug 12, 2016 at 12:13:46AM +0100, Lars Kurth wrote:
[...]
> +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
> + ---------------------------- --- -- -- -- -- -- -- -- --
> +
> + -------------------------------------------------------------------------------------
> + This comment section contains some examples that have influenced the section above.
> +
> + Let me express this as an algorithm.
> +
> + treshhold=2/3;
> + active='number of active members'; (7 for the Hypervisor project; IanC is inactive)
> + favour='number of +1 and +2 votes'
> + against='number of -1 and -2 votes'
> + strong-against='number -2 votes'; just added this as a sanity check
> +
> + 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.
> +
> + In that case:
> +
> + active -= 0-votes;
> +
> + Without the 0-rule:
> + - to pass: favour/active >= treshhold
> + to pass: with active==7, favour >= 5
> + in other words, 3 (0,-1,-2)-votes block the proposal as we cant achieve favour>=5
> +
> + With the 0-rule, let's consider 1, 2 or 3 0-votes
> + 1=>6: to pass: favour >=4
> + in other words, 3 (-1,-2)-votes block the proposal
> + 2=>5: to pass: favour >=4
> + in other words, 2 (-1,-2)-vote blocks the proposal
> + 3=>4: to pass: favour >=3
> + in other words, 2 (-1,-2)-vote blocks the proposal
> +
> + Looking at the arithmetic, it does probably make sense to go for the 0-rule. If we
> + do, there ought to be more votes in favour of a proposal, than 0-votes.
> +
> + On the other hand, not having the 0-rule forces everyone to form an opinion,
> + otherise we will find it hard to make decisions. But in some cases, forming an
> + opinion costs significant mental capacity.
> +
> + It would also allow us to remove the complexity of differentiating between
> + active and non-active leadership team members by assuming that no vote, equals
> + a "0" vote.
> +
> + Opinions?
>
I'm in favour of having 0-rule here.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <20160826114902.GH2590@citrix.com>
@ 2016-08-26 14:35 ` Lars Kurth
[not found] ` <D3E5C984.2D348%lars.kurth@citrix.com>
1 sibling, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-08-26 14:35 UTC (permalink / raw)
To: Wei Liu
Cc: Jan Beulich, xen-api, committers, mirageos-devel, xen-devel,
win-pv-devel
On 26/08/2016 07:49, "Wei Liu" <wei.liu2@citrix.com> wrote:
>On Sat, Aug 13, 2016 at 09:28:49AM +0000, Lars Kurth wrote:
>>
>>
>> On 12/08/2016 14:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>> >>>> On 12.08.16 at 14:53, <lars.kurth@citrix.com> wrote:
>> >> On 12/08/2016 13:41, "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>>>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
>> >>>> +### Lazy Consensus {#lazyconsensus}
>> >>>> +
>> >>>>[snip]
>> >>>> +
>> >>>> +Objections by stake-holders should be expressed using the
>> >>>>[conventions
>> >>>> +above](#expressingopinion) to make disagreements easily
>>identifiable.
>> >>>> +
>> >>>> +__Passed/Failed:__
>> >>>> +
>> >>>> +- Failed: A single **-2** by a stake-holder whose approval is
>> >>>>necessary
>> >>>> +- Failed: **-1**'s by all stake-holder whose approval is
>>necessary
>> >>>> +- Passed: In all other situations
>> >>>
>> >>>Hmm, that means all -1's except a single 0 would already be a pass?
>> >>
>> >> That is not the intention. If we have only -1's and 0's it should be
>>a
>> >> fail.
>> >> Let me fix this in the next revisions.
>> >>
>> >> How about:
>> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
>> >>approval
>> >> is necessary
>> >
>> >That would still leave 10 -1's overruled by a single +1.
>> >
>> >> Although maybe someone can come up with a clearer way to express
>>this.
>> >
>> >Maybe when there are no +2's, simply take the sum of all votes,
>> >and require it to be non-negative?
>>
>> That would work. Any other opinions?
>
>When there are no +2's *and -2's* ?
I guess we are a little confused here.
A -2 is a strong objection. So what we are saying is that with a strong
objection we can't move forward. Now we are only using this scheme for
expressing opinion informally and on Lazy Consensus. The central idea
behind Lazy consensus is that WE DO NOT NEED to explicitly express
agreement: in other words, the default when someone does not saying
anything is a +1 (an implicit agreement).
I added the "Only **-1** or **0** votes by all stake-holder whose", as
this would be a strong signal that people generally think we don't have a
good proposal and nobody is willing to defend it in any way.
+2's and -2's are in some sense a way to highlight that we have a strong
disagreement on an issue, whereas if we had +1's to -1's we only have a
minor disagreement.
I am not quite sure how to encode this using a formula. Looking for
feedback, but will do a little research in Apache, Eclipse and other FOSS
projects
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <D3E5C984.2D348%lars.kurth@citrix.com>
@ 2016-08-26 14:51 ` Wei Liu
[not found] ` <20160826145128.GY20641@citrix.com>
1 sibling, 0 replies; 18+ messages in thread
From: Wei Liu @ 2016-08-26 14:51 UTC (permalink / raw)
To: Lars Kurth
Cc: Wei Liu, Jan Beulich, xen-api, committers, mirageos-devel,
xen-devel, win-pv-devel
On Fri, Aug 26, 2016 at 03:35:38PM +0100, Lars Kurth wrote:
>
>
> On 26/08/2016 07:49, "Wei Liu" <wei.liu2@citrix.com> wrote:
>
> >On Sat, Aug 13, 2016 at 09:28:49AM +0000, Lars Kurth wrote:
> >>
> >>
> >> On 12/08/2016 14:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>
> >> >>>> On 12.08.16 at 14:53, <lars.kurth@citrix.com> wrote:
> >> >> On 12/08/2016 13:41, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> >>>>>> On 12.08.16 at 01:13, <lars.kurth@citrix.com> wrote:
> >> >>>> +### Lazy Consensus {#lazyconsensus}
> >> >>>> +
> >> >>>>[snip]
> >> >>>> +
> >> >>>> +Objections by stake-holders should be expressed using the
> >> >>>>[conventions
> >> >>>> +above](#expressingopinion) to make disagreements easily
> >>identifiable.
> >> >>>> +
> >> >>>> +__Passed/Failed:__
> >> >>>> +
> >> >>>> +- Failed: A single **-2** by a stake-holder whose approval is
> >> >>>>necessary
> >> >>>> +- Failed: **-1**'s by all stake-holder whose approval is
> >>necessary
> >> >>>> +- Passed: In all other situations
> >> >>>
> >> >>>Hmm, that means all -1's except a single 0 would already be a pass?
> >> >>
> >> >> That is not the intention. If we have only -1's and 0's it should be
> >>a
> >> >> fail.
> >> >> Let me fix this in the next revisions.
> >> >>
> >> >> How about:
> >> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
> >> >>approval
> >> >> is necessary
> >> >
> >> >That would still leave 10 -1's overruled by a single +1.
> >> >
> >> >> Although maybe someone can come up with a clearer way to express
> >>this.
> >> >
> >> >Maybe when there are no +2's, simply take the sum of all votes,
> >> >and require it to be non-negative?
> >>
> >> That would work. Any other opinions?
> >
> >When there are no +2's *and -2's* ?
>
> I guess we are a little confused here.
>
> A -2 is a strong objection. So what we are saying is that with a strong
> objection we can't move forward. Now we are only using this scheme for
> expressing opinion informally and on Lazy Consensus. The central idea
> behind Lazy consensus is that WE DO NOT NEED to explicitly express
> agreement: in other words, the default when someone does not saying
> anything is a +1 (an implicit agreement).
>
> I added the "Only **-1** or **0** votes by all stake-holder whose", as
> this would be a strong signal that people generally think we don't have a
> good proposal and nobody is willing to defend it in any way.
>
> +2's and -2's are in some sense a way to highlight that we have a strong
> disagreement on an issue, whereas if we had +1's to -1's we only have a
> minor disagreement.
>
> I am not quite sure how to encode this using a formula. Looking for
> feedback, but will do a little research in Apache, Eclipse and other FOSS
> projects
>
I wish we can't get into a situation that more than one rule could be
applied. So with your original words, a vote with one -2 and six +1's
(assuming 7 valid votes in total) can have two interpretations.
Failed: A single **-2** by a stake-holder whose approval is necessary
Passed: No +2's but total sum >0
Maybe I missed something here?
Or do you want to explicitly state the precedence of rules?
Wei.
> Lars
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <20160826145128.GY20641@citrix.com>
@ 2016-09-06 11:38 ` Lars Kurth
0 siblings, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-09-06 11:38 UTC (permalink / raw)
To: Wei Liu
Cc: Jan Beulich, xen-api, George Dunlap, committers, mirageos-devel,
xen-devel, win-pv-devel
On 26/08/2016 10:51, "Wei Liu" <wei.liu2@citrix.com> wrote:
>On Fri, Aug 26, 2016 at 03:35:38PM +0100, Lars Kurth wrote:
>>
>>
>> On 26/08/2016 07:49, "Wei Liu" <wei.liu2@citrix.com> wrote:
>>
>> >On Sat, Aug 13, 2016 at 09:28:49AM +0000, Lars Kurth wrote:
>> >>
>> >> >> How about:
>> >> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
>> >> >>approval
>> >> >> is necessary
>> >> >
>> >> >That would still leave 10 -1's overruled by a single +1.
>> >> >
>> >> >> Although maybe someone can come up with a clearer way to express
>> >>this.
>> >> >
>> >> >Maybe when there are no +2's, simply take the sum of all votes,
>> >> >and require it to be non-negative?
>> >>
>> >> That would work. Any other opinions?
>> >
>> >When there are no +2's *and -2's* ?
>>
>> I guess we are a little confused here.
>>
>> A -2 is a strong objection. So what we are saying is that with a strong
>> objection we can't move forward. Now we are only using this scheme for
>> expressing opinion informally and on Lazy Consensus. The central idea
>> behind Lazy consensus is that WE DO NOT NEED to explicitly express
>> agreement: in other words, the default when someone does not saying
>> anything is a +1 (an implicit agreement).
>>
>> I added the "Only **-1** or **0** votes by all stake-holder whose", as
>> this would be a strong signal that people generally think we don't have
>>a
>> good proposal and nobody is willing to defend it in any way.
>>
>> +2's and -2's are in some sense a way to highlight that we have a strong
>> disagreement on an issue, whereas if we had +1's to -1's we only have a
>> minor disagreement.
>>
>> I am not quite sure how to encode this using a formula. Looking for
>> feedback, but will do a little research in Apache, Eclipse and other
>>FOSS
>> projects
>>
>
>I wish we can't get into a situation that more than one rule could be
>applied. So with your original words, a vote with one -2 and six +1's
>(assuming 7 valid votes in total) can have two interpretations.
Sorry for the late reply.
Agreed. I wanted to end up with something simple for lazy consensus,
which also takes into account that a non-reply states implicit consensus.
We already have a more complex mechanism, in the section "Leadership
Decisions",
which makes decisions by 2/3 majority, which we can always fall back to.
> Failed: A single **-2** by a stake-holder whose approval is necessary
This would fit into the above set of requirements: simple and assumes that
a non-reply states implicit consensus.
> Passed: No +2's but total sum >0
I think the challenge is that there is a grey area. Also, I think that in
general,
we should only use "lazy consensus" where only a few people are involved
(e.g. a
2-4 maintainers/committers in an area). Where everyone is affected, it
seems to
me that we should just follow the "Leadership Decisions" model. I think
your
Proposal may be simple enough: but I think there is a problem with
Passed: No +2's but total sum >0
because it is probably fair to assume that the proposer of a proposal, will
by default have at least a "+1" position. If the proposer is willing to
argue
for his/her proposal (which is likely), then the proposal could never pass.
In any case, a single "+2" in absence of any "-2"'s should pass.
How about
The proposer of a lazy consensus is assumed to implicitly have an opinion
of **+1**,
unless otherwise stated.
Passed: A total sum of opinions **>0**
Failed: A single **-2** by a stake-holder whose approval is necessary
Failed: A total sum of opinions **<=0**
In case of failed lazy consensus, follow the pattern described in
"Leadership
Team Decisions"
This would mean that a proposal would pass, if a proposal is made and
no-one else
expresses any opinion, which seems fair enough. In this case, the sum
would be a "+1".
It would also mean that it can't pass if there was a single -1 (as
+1-1=0), unless
- the proposer started out with a "+2" or
- other people expressed a "+1" or "+2" in addition to the original
proposer.
Again, this seems fair enough.
If a proposal was started with a "+2" by the proposer, a fellow maintainer
could raise
an objection by expressing a "-2", arguing that this specific proposal is
too important
to be left to lazy consensus and we would have to defer to the leadership
team. In
other words, we would discourage proposers to start out with a "+2"
raising the bar
for negative votes.
This would also allow for some odd boundary cases, if a proposer started
out with a
**0** or **-1** to basically solicit opinions on something he/she is not
100% sure
about or to verify that a way of doing something is probably not a good
idea.
Maybe the following background reading helps with terminology
- http://oss-watch.ac.uk/resources/meritocraticgovernancevoting
I think this does retain enough of lazy consensus, with some elements of
lazy voting
thrown in for the whole approach not to be too different to standard
terminology. It
does raise the question, whether we should call this lazy consensus, lazy
voting or
something else. Which I guess would only be relevant for labelling the
process.
@George: do you have an opinion?
I think it also addresses Jan's concerns and your concerns regarding
simplicity.
Does this makes sense?
Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <20160816053231.GA5720@deinos.phlegethon.org>
@ 2016-09-09 11:56 ` Lars Kurth
[not found] ` <D3F853A4.2DA58%lars.kurth@citrix.com>
1 sibling, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2016-09-09 11:56 UTC (permalink / raw)
To: Tim (Xen.org)
Cc: xen-devel, win-pv-devel, committers, mirageos-devel, xen-api
On 16/08/2016 06:32, "Tim Deegan" <tim@xen.org> wrote:
>Hi,
>
>At 14:55 +0000 on 15 Aug (1471272946), Lars Kurth wrote:
>> But I see your point. The text should really have said something like...
>> -----
>> In situations where the entire Xen Project community becomes paralysed,
>> the project leaderships team or project lead should work with the
>> community
>> manager or advisory board to find a way forward.
>> -----
>
>Sure. I think that's good.
>
>> I think we have two options:
>> A) A delete this bullet entirely
>> B) Replace it with something clearer - even though, the location
>> for such a paragraph is wrong.
>>
>> My gut feel is to just go for A.
>
>Sounds good to me.
Having looked at the text again (making edits for v2), I propose to add
the following
new section to the document.
-------------
- [Community Decisions with Funding and Legal
implications](#funding-and-legal)
...
Community Decisions with Funding and Legal Implications
(#funding-and-legal)
-------------------------------------------------------
In some cases sub-project local and global decisions **may require
input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation]
(#roles-lf). For example, if a proposal by a project leadership team or
a global project decision requires that the project hires a staff member
or
contractor (e.g. a PR consultant, marketing manager) or requires the
funding
of new infrastructure (e.g. additional test hardware or services) to
implement
said proposal, then funding would need to be secured from the Advisory
Board or
from other sources.
If for example, a community proposal required the Linux Foundation to sign
a legal agreement with a 3rd party on behalf of the project/sub-project,
then
of course a review of such an agreement and a signature by the Linux
Foundation
would be required.
In such cases, the impacted project leadership team(s) will contact the
Community Manager and/or Advisory Board to resolve possible issues.
-------------
I don't think this is in fact a change in governance. It is just clarifying
what has happened in the past. I merely wanted to highlight that in some
cases there are dependencies. We have not had any global changes, where
this
was the case, but we had a few local ones.
E.g.
- Windows driver signing required buying a cert and an agreement between
the
LF and Microsoft to deliver signed windows drivers
- The way how we make hypervisor releases requires to operate OSSTEST
(aka. COLO agreements, procurement of HW, technical support, ...) which
also required the LF to sign contracts on behalf of the project.
I hope that is OK
Best Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
[not found] ` <D3F853A4.2DA58%lars.kurth@citrix.com>
@ 2016-09-09 15:45 ` Tim Deegan
0 siblings, 0 replies; 18+ messages in thread
From: Tim Deegan @ 2016-09-09 15:45 UTC (permalink / raw)
To: Lars Kurth; +Cc: xen-devel, win-pv-devel, committers, mirageos-devel, xen-api
At 11:56 +0000 on 09 Sep (1473422177), Lars Kurth wrote:
> Community Decisions with Funding and Legal Implications
> (#funding-and-legal)
> -------------------------------------------------------
>
> In some cases sub-project local and global decisions **may require
> input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation]
> (#roles-lf). For example, if a proposal by a project leadership team or
> a global project decision requires that the project hires a staff member
> or
> contractor (e.g. a PR consultant, marketing manager) or requires the
> funding
> of new infrastructure (e.g. additional test hardware or services) to
> implement
> said proposal, then funding would need to be secured from the Advisory
> Board or
> from other sources.
>
> If for example, a community proposal required the Linux Foundation to sign
> a legal agreement with a 3rd party on behalf of the project/sub-project,
> then
> of course a review of such an agreement and a signature by the Linux
> Foundation
> would be required.
>
> In such cases, the impacted project leadership team(s) will contact the
> Community Manager and/or Advisory Board to resolve possible issues.
>
>
> -------------
FWIW, LGTM.
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-09-09 15:45 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1470957226-18139-1-git-send-email-lars.kurth@citrix.com>
2016-08-11 23:13 ` [PATCH 1/3] Code motion changes to make real patches easier to read Lars Kurth
2016-08-11 23:13 ` [PATCH 2/3] Added comment sections to highight problem areas Lars Kurth
2016-08-11 23:13 ` [PATCH 3/3] Significant changes to decision making; some new roles and minor changes Lars Kurth
[not found] ` <1470957226-18139-4-git-send-email-lars.kurth@citrix.com>
2016-08-12 12:41 ` Jan Beulich
[not found] ` <57ADDFFF0200007800105745@prv-mh.provo.novell.com>
2016-08-12 12:53 ` Lars Kurth
[not found] ` <D3D38326.2CC31%lars.kurth@citrix.com>
2016-08-12 13:01 ` Jan Beulich
[not found] ` <57ADE4C10200007800105769@prv-mh.provo.novell.com>
2016-08-13 9:28 ` Lars Kurth
[not found] ` <D3D4A690.2CCCF%lars.kurth@citrix.com>
2016-08-26 11:49 ` Wei Liu
[not found] ` <20160826114902.GH2590@citrix.com>
2016-08-26 14:35 ` Lars Kurth
[not found] ` <D3E5C984.2D348%lars.kurth@citrix.com>
2016-08-26 14:51 ` Wei Liu
[not found] ` <20160826145128.GY20641@citrix.com>
2016-09-06 11:38 ` Lars Kurth
2016-08-12 21:58 ` Stefano Stabellini
2016-08-15 10:59 ` Tim Deegan
[not found] ` <20160815105913.GA21763@deinos.phlegethon.org>
2016-08-15 14:55 ` Lars Kurth
[not found] ` <D3D77FC9.2CDA3%lars.kurth@citrix.com>
2016-08-16 5:32 ` Tim Deegan
[not found] ` <20160816053231.GA5720@deinos.phlegethon.org>
2016-09-09 11:56 ` Lars Kurth
[not found] ` <D3F853A4.2DA58%lars.kurth@citrix.com>
2016-09-09 15:45 ` Tim Deegan
2016-08-26 11:59 ` Wei Liu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.