<p>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.</p>
+ (see revision sections). The last modification has been made in July
+ 2016.</p>
+<h2>Content</h2>
+<ul>
+ <li><a href="#goals">Goals</a></li>
+ <li><a href="#principles">Principles</a></li>
+ <li><a href="#roles-global">Xen Project Wide Roles</a></li>
+ <li><a href="#roles-local">Project Team Roles</a></li>
+ <li><a href="#contributions">Making Contributions</a></li>
+ <li><a href="#decisions">Decision Making, Conflict Resolution, Role Nominations and
+ Elections</a></li>
+ <li><a href="#formal-votes">Formal Votes</a></li>
+ <li><a href="#project-governance">Project Governance</a></li>
+</ul>
<p>
<a id="goals"></a>
</p>
<h2>Goals</h2>
<p>The goals of Xen Project Governance are to:</p>
<ul>
- <li>Create a set of minimum requirements for a sub-project hosted on
- Xenproject.org</li>
+ <li>Create a set of minimum requirements for a sub-project hosted on Xenproject.org</li>
<li>Create a lightweight project life cycle that
<ul>
<li>leads the project to articulate its goals and how to achieve them</li>
<p>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.</p>
-<h3>Consensus Decision Making</h3>
-<p>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.</p>
-<p>Voting is done with numbers:</p>
-<ul>
- <li>+1 : a positive vote</li>
- <li>0 : abstain, have no opinion</li>
- <li>-1 : a negative vote</li>
-</ul>
-<p>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.
- <a id="conflict"> </a>
-</p>
-<h3>Conflict Resolution</h3>
-<h4>Refereeing</h4>
-<p>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.</p>
-<h4>Last Resort</h4>
-<p>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.</p>
-<p>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 <a href="/join.html">Xen Project Advisory Board</a> will break
- the tie through a casting vote.</p>
<p>
<a id="roles"></a>
+ <a id="roles-global"></a>
</p>
-<h2>Roles</h2>
-<h3>Maintainers</h3>
-<p>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.</p>
-<h3>Committers</h3>
-<p>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.
- <a href="/developers/teams/hypervisor.html">Hypervisor team portal</a>).</p>
+<h2>Xen Project Wide Roles</h2>
<h3>Sub-projects and Teams</h3>
<p>The Xen Project organizes itself into a number of sub-projects, which
follow the <a href="#project-governance">Project Governance</a> (or
referred to as teams to highlight the collaborative nature of development.
For example, each sub-project has a <a href="/developers/teams.html">team
portal</a> on Xenproject.org.</p>
-<h3>Project Lead</h3>
-<p>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.</p>
<h3>Xen Project Advisory Board</h3>
-<p>The <a href="/join.html">Xen Project Advisory Board</a> consists of
+<p>The <a href="/join.html">Xen Project Advisory Board</a> consists of
members who are committed to steering the project to advance
its market and technical success, and who serve as positive ambassadors
for the project. The Xen Project Advisory Board manages non-technical
marketing and events, and managing the Xen Project trademark. The Advisory
Board leaves all technical decisions to the open source meritocracy.</p>
<h3>The Linux Foundation</h3>
-<p>The Xen Project is a <a href="/linux-foundation.html">Linux Foundation</a>
+<p>The Xen Project is a <a href="/linux-foundation.html">Linux Foundation</a>
Collaborative Project. Collaborative Projects are independently funded
software projects that harness the power of collaborative development
to fuel innovation across industries and ecosystems. By spreading the
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.</p>
+<p>
+ <a id="roles-local"></a>
+</p>
+<h2>Project Team Roles</h2>
+<h3>Maintainers</h3>
+<p>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.</p>
+<h3>Committers</h3>
+<p>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.
+ <a href="/developers/teams/hypervisor.html">Hypervisor team portal</a>).</p>
+<h3>Project Lead</h3>
+<p>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.</p>
+<p>
+ <a id="contributions"></a>
+</p>
<h2>Making Contributions</h2>
<p>Making contributions in Xen follows the conventions as they are known
in the Linux Kernel community. In summary contributions are made through
<p>More information on making contributions can be found in the following
documents:</p>
<ul>
- <li><a href="g/help/contribution-guidelines.html">Contribution Guidelines</a></li>
+ <li><a href="/help/contribution-guidelines.html">Contribution Guidelines</a></li>
+</ul>
+<p>
+ <a id="decisions"></a>
+</p>
+<h2>Decision Making, Conflict Resolution, Role Nominations and Elections</h2>
+<h3>Consensus Decision Making</h3>
+<p>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.</p>
+<p>Voting is done with numbers:</p>
+<ul>
+ <li>+1 : a positive vote</li>
+ <li>0 : abstain, have no opinion</li>
+ <li>-1 : a negative vote</li>
</ul>
-<h2>Elections and Formal Votes</h2>
-<h3>Maintainer Elections</h3>
+<p>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.</p>
+<p>
+ <a id="conflict"> </a>
+</p>
+<h3>Conflict Resolution</h3>
+<h4>Refereeing</h4>
+<p>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.</p>
+<h4>Last Resort</h4>
+<p>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.</p>
+<p>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 <a href="/join.html">Xen Project Advisory Board</a> will break
+ the tie through a casting vote.</p>
+<h3>Elections</h3>
+<h4>Maintainer Elections</h4>
<p>Developers who have earned the trust of maintainers (including the project
lead) can be promoted to Maintainer. A two stage mechanism is used</p>
<ul>
or doubt, the project lead or a committer should ask the community
manager to arrange a more formal vote.</li>
</ul>
-<h3>Committer Elections</h3>
+<h4>Committer Elections</h4>
<p>Developers who have earned the trust of committers in their project can
through election be promoted to Committer. A two stage mechanism is
used</p>
will try and resolve the situation and reach consensus. Results will
be published on the public mailing list.</li>
</ul>
-<h3>Project Lead Elections</h3>
+<h4>Project Lead Elections</h4>
<p>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
<p>
<a id="formal-votes"></a>
</p>
-<h3>Formal Votes</h3>
+<h2>Formal Votes</h2>
<p>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
+ procedures are introduced or changed, or as part of the
<a href="#project-governance">Project Governance</a>.
Who is eligible to vote, depends on whether the scope of a process
or procedure is <b>local</b> to a sub-project or team, or whether it
affects <b>all sub-projects</b> (or in other words, is<strong> global</strong>).
- Examples of local scope is the <a href="/security-policy.html">Security Policy</a>
+ Examples of local scope is the <a href="/security-policy.html">Security Policy</a>
which applies to the <a href="/developers/teams/hypervisor.html">Hypervisor
Project</a> only. Examples of global scope are changes to this document or votes
outlined in the Project Governance.</p>
process of project formation will grow into a project proposal. The
project proposal will need to satisfy some basic conditions, will be
put out for community review and is then put to a vote to all maintainers
- and project leads of mature sub-projects hosted on Xenproject.org
- following the usual decision making process.</p>
+ and project leads of mature sub-projects hosted on Xenproject.org following
+ the usual decision making process.</p>
<p>For agreed project proposals, the Xen Project will provide basic infrastructure
and the project can get started. Sub-projects in incubation are working
towards a set of goals, will get additional support and marketing opportunities
<ul>
<li>gather final feedback and input from the community (it is good practice
to informally do this before the review),</li>
- <li>advertise the project with the aim to attract interest, users and contributors.
- </li>
+ <li>advertise the project with the aim to attract interest, users and contributors.</li>
</ul>
<p>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.</p>
<li>A codeline</li>
<li>A sub-project or team portal on Xenproject.org (in an area separate
from mature projects)</li>
- <li>A wiki page on <a href="http://wiki.xenproject.org">wiki.xenproject.org</a>
- (this is expected to be maintained by the project lead)</li>
+ <li>A wiki page on <a href="http://wiki.xenproject.org">wiki.xenproject.org</a> (this is expected to be maintained by the project lead)</li>
</ul>
<h3>Incubating a Project</h3>
<p>The purpose of the incubation phase is for a project to show that it
from an archived projects section on Xenproject.org</li>
<li>The project's wiki pages will be tagged as <strong>archived</strong>.
A project may be completed (i.e. it has achieved its goals and/or
- fulfilled its charter) in which case it is tagged as <strong>completed</strong>
- and <strong>archived</strong>.</li>
+ fulfilled its charter) in which case it is tagged as <strong>completed</strong> and <strong>archived</strong>.</li>
<li>The project or team portal on Xenproject.org will be moved into an
- <strong>Archive</strong> section. We may have a <strong>Completed</strong>
- section within the <strong>Archive</strong> section.</li>
+ <strong>Archive</strong> section. We may have a <strong>Completed</strong> section within the <strong>Archive</strong> section.</li>
</ul>
<p>In cases where the project has delivered code into other sub-projects
hosted on Xenproject.org, the code will be</p>
<h2>Change History</h2>
<div class="box-note">
<ul>
+ <li><strong>v3.0 July 2016:</strong> TODO: Add real changelog in main patch</li>
<li><strong>v2.1 May 2016:</strong> Clarify Committer
Elections as per this <a href="http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00801.html">discussion</a> and <a href="http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01614.html">vote</a></li>
<li><strong>v2.0 May 2012:</strong> Changes to reflect transition from
projects / people / larsk / security-process.git / commitdiff