On Fri, Sep 23, 2016 at 07:55:26PM +0100, Lars Kurth wrote:
> 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.ku...@citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.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)
> 

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Reply via email to