From: Lars Kurth Date: Fri, 1 Mar 2019 12:53:15 +0000 (+0000) Subject: Normalized for new website X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=f084d205875d719c761185ef2456c35261cacced;p=people%2Flarsk%2Fgovernance.git Normalized for new website --- diff --git a/governance.html b/governance.html index 41ab3ea..a293369 100644 --- a/governance.html +++ b/governance.html @@ -1,71 +1,73 @@ -

This document has come in effect in June 2011 and will be reviewed periodically (see revision sections). The last modification has been made in December 2016.

-

Content

+This document has come in effect in June 2011 and will be reviewed periodically (see revision sections). The last modification has been made in December 2016. +

Content

Goals

-

The goals of Xen Project Governance are to:

+The goals of Xen Project Governance are to:

Principles

Openness

-

The Xen Project is open to all and provides the same opportunity to all. Everyone participates with the same rules. There are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.

+The Xen Project is open to all and provides the same opportunity to all. Everyone participates with the same rules. There are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.

Transparency

-

Project discussions, minutes, deliberations, project plans, plans for new features, and other artefacts are open, public, and easily accessible.

+Project discussions, minutes, deliberations, project plans, plans for new features, and other artefacts are open, public, and easily accessible.

Meritocracy

-

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.

+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

-

The Xen Project consists of a number of sub-projects: each sub-project makes technical and other decisions that solely affect it locally.

+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

Sub-projects and Teams

-

The Xen Project organizes itself into a number of sub-projects, which follow the 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 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. In line with the meritocratic principle, mature projects have more influence than incubation projects, on project wide decisions.

+The Xen Project organizes itself into a number of sub-projects, which follow the 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 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. In line with the meritocratic principle, mature projects have more influence than incubation projects, on project wide decisions.

Community Manager

-

The Xen Project has a community manager, whose primary role it is to support the entire Xen Project Community.

+The Xen Project has a community manager, whose primary role it is to support the entire Xen Project Community.

Xen Project Advisory Board

-

The Xen Project Advisory Board 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 aspects of the Xen Project including funding for shared project infrastructure, marketing and events, and managing the Xen Project trademark. The Advisory Board leaves all technical decisions to the open source meritocracy.

+The Xen Project Advisory Board 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 aspects of the Xen Project including funding for shared project infrastructure, marketing and events, and managing the Xen Project trademark. The Advisory Board leaves all technical decisions to the open source meritocracy.

The Linux Foundation

-

The Xen Project is a Linux Foundation 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 collaborative DNA of the largest collaborative software development project in history, The Linux Foundation provides the essential collaborative and organizational framework so projects can focus on innovation and results.

+The Xen Project is a Linux Foundation 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 collaborative DNA of the largest collaborative software development project in history, The Linux Foundation provides the essential collaborative and organizational framework so projects can focus on innovation and results.

Mentor

-

Younger projects may have a need for a mentor to help ensure that the project will be successful. Mentors can be maintainers, project leads, advisory board members or other distinguished community members.

+Younger projects may have a need for a mentor to help ensure that the project will be successful. Mentors can be maintainers, project leads, advisory board members or other distinguished community members. -

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

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

-

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. 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 specializations before they can mature.

- +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. 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 specializations before they can mature. +
- - - - - - - + + + + + + + - + @@ -73,7 +75,7 @@ - + @@ -81,7 +83,7 @@ - + @@ -92,109 +94,127 @@
ProjectMatureMaintainersCommittersSecurity TeamLeadership Team
ProjectMatureMaintainersCommittersSecurity TeamLeadership Team
Hypervisor YES YESYES Committers and Release Manager, without a Project Lead
Windows Drivers NO YESNO Committers, with a Project Lead
XAPI YES YES

Maintainers

-

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.

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

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) and/or in the projects MAINTAINERS files.

+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) and/or in the projects MAINTAINERS files.

Security Response Team (short: Security Team)

-

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

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

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

-

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 should the Project Leadership Team become paralysed.

+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 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). + +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 should the Project Leadership Team become paralysed.

Making Contributions

-

Making contributions in Xen follows the conventions as they are known in the Linux Kernel community. In summary contributions are made through patches that are reviewed by the community. Xen does not require community members to sign contribution or committer agreements. We do require contributors to sign contributions using the sign-off feature of the code repository, following the same approach as the Linux Kernel does (see Developer Certificate Of Origin).

-

More information on making contributions can be found in the following documents:

+Making contributions in Xen follows the conventions as they are known in the Linux Kernel community. In summary contributions are made through patches that are reviewed by the community. Xen does not require community members to sign contribution or committer agreements. We do require contributors to sign contributions using the sign-off feature of the code repository, following the same approach as the Linux Kernel does (see Developer Certificate Of Origin). + +More information on making contributions can be found in the following documents:

Decision Making, Conflict Resolution, Role Nominations and Elections

-

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. The only exception is that each project is required to adhere to the Review Then Commit Policy, Leadership Team Decisions and Conflict Resolution.

+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. The only exception is that each project is required to adhere to the Review Then Commit Policy, Leadership Team Decisions and Conflict Resolution.

Review Then Commit

-

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.

+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

-

Within the community, we follow the following number notation to explicitly express opinions on proposals, formal or informal votes.

+Within the community, we follow the following number notation to explicitly express opinions on proposals, formal or informal votes. -

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:

+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 / Lazy Voting

-

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 decision (see below). Lazy Consensus is extremely useful, when you don't anticipate any objections, or to gauge whether there are objections to a proposal. The concrete process in this section is a mixture between Lazy Consensus and Lazy Voting and is designed to avoid unnecessary multiple stages in decision making.

-

To make use of it, post something like the following on the project's mailing list (or some other communication channel):

-
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 to make disagreements easily identifiable.

-

Passed/Failed: The proposer of Lazy Consensus decision is assumed to implicitly have an opinion of +1, unless otherwise stated.

+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 decision (see below). Lazy Consensus is extremely useful, when you don't anticipate any objections, or to gauge whether there are objections to a proposal. The concrete process in this section is a mixture between Lazy Consensus and Lazy Voting and is designed to avoid unnecessary multiple stages in decision making. + +To make use of it, post something like the following on the project's mailing list (or some other communication channel): +
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 to make disagreements easily identifiable. + +Passed/Failed: The proposer of Lazy Consensus decision is assumed to implicitly have an opinion of +1, unless otherwise stated. -

It can only be overturned if the project leadership agrees collectively, that the decision is too important to be settled by lazy consensus / lazy voting. In situations where a proposal is failed, an alternative solution needs to be found, or if a decision is formally challenged, conflict resolution mechanisms may need to be used to resolve the situation.

-

Further Examples: A Lazy Consensus decision starts out with the implicit +1 opinion of the proposer. If there is no explicit response, the proposal passes as the sum is >0.

-

If there is a single -1 without any + votes, the proposal fails.

-

If there are multiple +1's or +2's, more -1's than positive votes are needed for the proposal to fail. This mechanism, is often also called Lazy Voting.

-

The process does allow for a proposer to state a starting opinion of 0 or -1. In this case, the Lazy Consensus label does not work for the process, as positive opinions are needed for the proposal to pass. To make use of this mechanism, post something like the following on the project's mailing list (or some other communication channel)

-
I want to solicit opinions on X and am going to assume lazy voting:     
-My starting position is **0**, as I feel that at least one other        
-stake-holder should agree with the proposal.                            
-If there is a majority in favour, without a **-2** objection within the 
-next seven days, I assume that the proposal holds and does not need      
-require further discussion.                                             
-
-

Unlike in the lazy consensus case, a single +1 vote is needed. Otherwise the proposal fails. Otherwise, the counting rules follow the general case.

-

This can be useful in situations, where the proposer is not quite sure about his/her position, or where the invoker acts on behalf of the community to resolve a discussion which has become stuck. A starting position of -1 can be used to verify that a specific approach may be a bad idea: whether this is really useful, has to be verified as we start using this process.

+It can only be overturned if the project leadership agrees collectively, that the decision is too important to be settled by lazy consensus / lazy voting. 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. + +Further Examples: A Lazy Consensus decision starts out with the implicit +1 opinion of the proposer. If there is no explicit response, the proposal passes as the sum is >0. + +If there is a single -1 without any + votes, the proposal fails. + +If there are multiple +1's or +2's, more -1's than positive votes are needed for the proposal to fail. This mechanism, is often also called + +Lazy Voting. + +The process does allow for a proposer to state a starting opinion of 0 or -1. In this case, the Lazy Consensus label does not work for the process, as positive opinions are needed for the proposal to pass. To make use of this mechanism, post something like the following on the project's mailing list (or some other communication channel) +
I want to solicit opinions on X and am going to assume lazy voting:
+My starting position is 0, as I feel that at least one other stake-holder
+should agree with the proposal.If there is a majority in favour, without a
+-2 objection within the next seven days, I assume that the proposal holds and
+does not need require further discussion.
+Unlike in the lazy consensus case, a single +1 vote is needed. Otherwise the proposal fails. Otherwise, the counting rules follow the general case. + +This can be useful in situations, where the proposer is not quite sure about his/her position, or where the invoker acts on behalf of the community to resolve a discussion which has become stuck. A starting position of -1 can be used to verify that a specific approach may be a bad idea: whether this is really useful, has to be verified as we start using this process.

Informal Votes or Surveys

-

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 to identify the strongest proposal. Once the strongest candidate has been identified, lazy consensus could be used to close the discussion. In some situation, a specific survey may need to be created, to help identify gauging 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, 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 anonymously.

+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 to identify the strongest proposal. Once the strongest candidate has been identified, lazy consensus could be used to close the discussion. In some situation, a specific survey may need to be created, to help identify gauging 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, 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 anonymously.

Leadership Team Decisions

-

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:

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

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. 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 community manager, to arrange an anonymous vote on behalf of the leadership team.

-

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.

-

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:

+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. 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 community manager, to arrange an anonymous vote on behalf of the leadership team. + +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. + +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: -

The table below maps the number of leadership team members against the required quorum:

- +The table below maps the number of leadership team members against the required quorum: +
- - - - - - - - - - - + + + + + + + + + + + - + @@ -208,23 +228,22 @@ require further discussion.
Leadership team members1098765432
Leadership team members1098765432
Positive votes needed for quorum 4 3
-

-

The table below maps active votes against votes needed to pass:

- +The table below maps active votes against votes needed to pass: +
- - - - - - - - - - - + + + + + + + + + + + - + @@ -239,228 +258,251 @@ require further discussion.
Active Votes (+1 or -1)1098765432
Active Votes (+1 or -1)1098765432
Positive votes needed to pass 7 6

Conflict Resolution

-

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 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 the entire Xen Project community becomes paralysed the impacted project leadership teams or project leads should work with the community manager or advisory board to find a way forward.

+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 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 the entire Xen Project community becomes paralysed the impacted project leadership teams or project leads should work with the community manager or advisory board to find a way forward.

Elections

Maintainer Elections

-

Developers who have earned the trust of existing maintainers 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

Committer and other Project Leadership Elections

-

Developers who have earned the trust of committers in their project can through election be promoted to Committer or Project Leadership (if not covered otherwise). A two stage mechanism is used

+Developers who have earned the trust of committers in their project can through election be promoted to Committer or Project Leadership (if not covered otherwise). A two stage mechanism is used

Security Response Team Members

-

Developers who have earned the trust of other security team members can be promoted to be on the security team. Due to the specific needs of the security team, promotions are typically made by the security team itself and confirmed by lazy consensus within the team.

+Developers who have earned the trust of other security team members can be promoted to be on the security team. Due to the specific needs of the security team, promotions are typically made by the security team itself and confirmed by lazy consensus within the team.

Project Lead Elections

-

Projects which have a project lead, should vote for a project lead in an anonymous vote amongst the project leadership.

+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 wide decisions are made through formal global votes and are conducted in rare circumstances only, following the principle of local decision making. Global votes are only needed, when all sub-projects hosted on Xenproject.org are affected. This is true, only for:

+Project wide decisions are made through formal global votes and are conducted in rare circumstances only, following the principle of local decision making. Global votes are only needed, when all sub-projects hosted on Xenproject.org are affected. This is true, only for: -

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:

- +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: +
- + + + + + - + - +
ProposalWho reviews?Who votes?
ProposalWho reviews?Who votes?
Creating, graduating, completing/archiving of sub-projects Members of developer mailing lists of qualifying projects Leadership teams of mature 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 lists of qualifying projects Leadership teams of mature sub-projects, within the scope described above.
-

-

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 is conducted per project in line with the following rules:

+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 is conducted per project in line with the following rules: -

Passed/Failed Resolutions:

+Passed/Failed Resolutions: -

In some cases sub-project local and global decisions may require input from the Advisory Board 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.

+In some cases sub-project local and global decisions may require input from the Advisory Board 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.

Project Governance

Basic Project Life Cycle

-

The proposal is to follow a simple basic flow:

-
-

A Xenproject.org hosted project starts with an idea which through the 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.

-

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 from the Xen Project. However there will also be regular checkpoints to see whether the project is progressing. Should it turn out that a project is not viable any more, it will be archived after an archivation review and vote. For a project to graduate, some basic conditions must be satisfied. If a project in incubation has achieved the point where it believes it is mature enough to graduate, it can request a Graduation community review followed by a vote.

-

Mature projects are pretty much expected to run themselves. However at some point a mature project will lose momentum and developers. If this is the case the Xen Project community can request an archivation review, which follows the usual pattern.

-

Archivation reviews have two purposes:

+The proposal is to follow a simple basic flow: +
+
+
+A Xenproject.org hosted project starts with an idea which through the 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. + +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 from the Xen Project. However there will also be regular checkpoints to see whether the project is progressing. Should it turn out that a project is not viable any more, it will be archived after an archivation review and vote. For a project to graduate, some basic conditions must be satisfied. If a project in incubation has achieved the point where it believes it is mature enough to graduate, it can request a Graduation community review followed by a vote. + +Mature projects are pretty much expected to run themselves. However at some point a mature project will lose momentum and developers. If this is the case the Xen Project community can request an archivation review, which follows the usual pattern. + +Archivation reviews have two purposes: -

It is also possible to revive archived projects. However these are treated almost like new projects as projects would only be archived if they have become inactive.

+It is also possible to revive archived projects. However these are treated almost like new projects as projects would only be archived if they have become inactive.

Requesting Reviews, Reviews and Voting

-

Requesting Reviews: Project Proposal and Graduation Reviews are requested by the (prospective) project lead of the project by contacting the community manager providing the necessary documentation. An archivation review can be requested by any maintainer of a mature project or by the Xen Project community manager. The community manager will then publish relevant material on the respective mailing lists.

-

Reviews: These are off-line reviews which are open to all community members by which a proposal is published for review. The purpose of the review is two-fold:

+Requesting Reviews: Project Proposal and Graduation Reviews are requested by the (prospective) project lead of the project by contacting the community manager providing the necessary documentation. An archivation review can be requested by any maintainer of a mature project or by the Xen Project community manager. The community manager will then publish relevant material on the respective mailing lists. + +Reviews: These are off-line reviews which are open to all community members by which a proposal is published for review. The purpose of the review is two-fold: -

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.

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

Forming a Project

-

Requirements for forming a sub-project or team on Xenproject.org:

+Requirements for forming a sub-project or team on Xenproject.org: -

The purpose of the project formation phase is to work out what the project is about, get community buy-in and help the future project gain publicity and momentum. The formation phase is driven by the project lead. The project mentor's role is to advise and support the project lead in getting the project started.

-

The project proposal is a document that describes and is published on wiki.xenproject.org:

+The purpose of the project formation phase is to work out what the project is about, get community buy-in and help the future project gain publicity and momentum. The formation phase is driven by the project lead. The project mentor's role is to advise and support the project lead in getting the project started. + +The project proposal is a document that describes and is published on wiki.xenproject.org:

Project Proposal Review

-

The review is initiated by the project lead and follows the rules outlined in "Requesting Reviews, Reviews and Voting".

-

After a successful review, the following resources will be created for the project:

+The review is initiated by the project lead and follows the rules outlined in "Requesting Reviews, Reviews and Voting". + +After a successful review, the following resources will be created for the project:

Incubating a Project

-

The purpose of the incubation phase is for a project to show that it is gathering momentum and adheres to the "Principles & Roles" of sub-projects hosted on Xenproject.org. The project mentor will work closely with the project lead and there are at least quarterly informal review meetings with the mentor on how the project is doing. Should a mentor not be able to fulfil his/her role any more, it is the responsibility of the project lead to find another mentor. We advise that the project lead gives at least quarterly updates on the Xen Project blog on how the project is doing.

-

The Xen Project will provide support to incubating projects. The project lead will work closely with the Xen Project community manager as well as with the project mentor.

+The purpose of the incubation phase is for a project to show that it is gathering momentum and adheres to the "Principles & Roles" of sub-projects hosted on Xenproject.org. The project mentor will work closely with the project lead and there are at least quarterly informal review meetings with the mentor on how the project is doing. Should a mentor not be able to fulfil his/her role any more, it is the responsibility of the project lead to find another mentor. We advise that the project lead gives at least quarterly updates on the Xen Project blog on how the project is doing. + +The Xen Project will provide support to incubating projects. The project lead will work closely with the Xen Project community manager as well as with the project mentor.

Archiving an Incubating project

-

The mentor can request for a project to be archived, if the project is not making sufficient progress. See "archivation review".

+The mentor can request for a project to be archived, if the project is not making sufficient progress. See "archivation review".

Graduation Review

-

The review is initiated by the project lead and follows the rules outlined in "Requesting Reviews, Reviews and Voting". In essence the project lead makes a pitch to the community, why the project should graduate.

-

A project must fulfil the following requirements before it can graduate:

+The review is initiated by the project lead and follows the rules outlined in "Requesting Reviews, Reviews and Voting". In essence the project lead makes a pitch to the community, why the project should graduate. + +A project must fulfil the following requirements before it can graduate: -

Other items to look at during the review (depending on project are):

+Other items to look at during the review (depending on project are):

Mature Projects

-

Mature projects are expected to be run and promote themselves. The project leadership team and/or project lead has significant responsibility in ensuring that this happens. The Xen Project and the community manager will help organize events, provide opportunities for the project to get new contributors and build a community, promote new releases on the blog and to the press, work with project members, etc. However the Xen Project and the community manager will not get involved in the day-to-day running of the project.

-

At some point during its life cycle a project may lose momentum. In other words developers and users are not interested in the project any more. If this is the case, it may be time to archive the project. If the project has achieved its goals and is thus completed, it may also be time to archive the project.

+Mature projects are expected to be run and promote themselves. The project leadership team and/or project lead has significant responsibility in ensuring that this happens. The Xen Project and the community manager will help organize events, provide opportunities for the project to get new contributors and build a community, promote new releases on the blog and to the press, work with project members, etc. However the Xen Project and the community manager will not get involved in the day-to-day running of the project. + +At some point during its life cycle a project may lose momentum. In other words developers and users are not interested in the project any more. If this is the case, it may be time to archive the project. If the project has achieved its goals and is thus completed, it may also be time to archive the project.

Archivation Review

-

These can happen in a number of situations:

+These can happen in a number of situations: -

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 "Requesting Reviews, Reviews and Voting".

-

The review is essentially a pitch why the project should be archived. The purpose of the review is not necessarily to archive a project, but also to provide a last opportunity for interested parties in the Xen Project community to save the project and step up. The Xen Project community manager will support efforts to save the project, should community members want to step up. There is the special case that a project has been completed: in this case the normal situation would be for the project lead to make the case, why this is so.

+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 "Requesting Reviews, Reviews and Voting". + +The review is essentially a pitch why the project should be archived. The purpose of the review is not necessarily to archive a project, but also to provide a last opportunity for interested parties in the Xen Project community to save the project and step up. The Xen Project community manager will support efforts to save the project, should community members want to step up. There is the special case that a project has been completed: in this case the normal situation would be for the project lead to make the case, why this is so.

Archived Projects

-

When a project is archived the following happens:

+When a project is archived the following happens: -

In cases where the project has delivered code into other sub-projects hosted on Xenproject.org, the code will be

+In cases where the project has delivered code into other sub-projects hosted on Xenproject.org, the code will be

Exceptional Circumstances

Incubation Projects without Project Lead

-

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.

-

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 consider archiving the project.

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

-

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.

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

+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

-

Add specialisations to this section, as they surface.

+Add specialisations to this section, as they surface.

Change History

\ No newline at end of file +
  • v1.0 Jun 2011: Initial document approved
    • + diff --git a/governance.pandoc b/governance.pandoc index 188fa41..83ce9f0 100644 --- a/governance.pandoc +++ b/governance.pandoc @@ -1,4 +1,4 @@ -This document has come in effect in June 2011 and will be reviewed periodically +This document has come in effect in June 2011 and will be reviewed periodically (see revision sections). The last modification has been made in December 2016. Content @@ -9,7 +9,7 @@ Content - [Xen Project Wide Roles](#roles-global) - [Project Team Roles](#roles-local) - [Making Contributions](#contributions) -- [Decision Making, Conflict Resolution, Role Nominations and +- [Decision Making, Conflict Resolution, Role Nominations and Elections](#decisions) - [Project Wide Decision Making](#project-decisions) - [Community Decisions with Funding and Legal Implications](#funding-and-legal) @@ -21,7 +21,7 @@ Goals {#goals} The goals of Xen Project Governance are to: -- Create a set of minimum requirements for a sub-project hosted on +- Create a set of minimum requirements for a sub-project hosted on Xenproject.org - Create a lightweight project life cycle that - leads the project to articulate its goals and how to achieve them @@ -30,9 +30,9 @@ Xenproject.org - leads to non-viable projects failing quickly - provides opportunities for other community members - Avoid bureaucracy, i.e. the life cycle should be as informal as possible -- Encourage Xen related projects to be hosted on Xenproject.org rather than +- Encourage Xen related projects to be hosted on Xenproject.org rather than going elsewhere -- Set clear expectations to vendors, upstream and downstream projects and +- Set clear expectations to vendors, upstream and downstream projects and community members Principles {#principles} @@ -40,100 +40,100 @@ Principles {#principles} ### Openness -The Xen Project is open to all and provides the same opportunity to all. -Everyone participates with the same rules. There are no rules to exclude any -potential contributors which include, of course, direct competitors in the +The Xen Project is open to all and provides the same opportunity to all. +Everyone participates with the same rules. There are no rules to exclude any +potential contributors which include, of course, direct competitors in the marketplace. ### Transparency -Project discussions, minutes, deliberations, project plans, plans for new +Project discussions, minutes, deliberations, project plans, plans for new features, and other artefacts are open, public, and easily accessible. ### Meritocracy -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 +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 -The Xen Project consists of a number of sub-projects: each sub-project makes +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} +Xen Project Wide Roles {#roles-global} ---------------------- ### Sub-projects and Teams -The Xen Project organizes itself into a number of sub-projects, which follow -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-projects own and are responsible for a collection of source repositories -and other resources (e.g. test infrastructure, CI infrastructure, ...), which +The Xen Project organizes itself into a number of sub-projects, which follow +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) 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 +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 Xen Project has a community manager, whose primary role it is to support the entire Xen Project Community. ### Xen Project Advisory Board {#roles-ab} -The [Xen Project Advisory Board](/join.html) consists of members who are -committed to steering the project to advance its market and technical success, -and who serve as positive ambassadors for the project. The Xen Project Advisory -Board manages non-technical aspects of the Xen Project including funding for -shared project infrastructure, marketing and events, and managing the Xen -Project trademark. The Advisory Board leaves all technical decisions to the +The [Xen Project Advisory Board](/join) 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 aspects of the Xen Project including funding for +shared project infrastructure, marketing and events, and managing the Xen +Project trademark. The Advisory Board leaves all technical decisions to the open source meritocracy. ### The Linux Foundation {#roles-lf} -The Xen Project is a [Linux Foundation](/linux-foundation.html) 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 collaborative DNA of the largest -collaborative software development project in history, The Linux Foundation -provides the essential collaborative and organizational framework so projects +The Xen Project is a [Linux Foundation](/linux-foundation) 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 collaborative DNA of the largest +collaborative software development project in history, The Linux Foundation +provides the essential collaborative and organizational framework so projects can focus on innovation and results. ### Mentor -Younger projects may have a need for a mentor to help ensure that the project -will be successful. Mentors can be maintainers, project leads, advisory board +Younger projects may have a need for a mentor to help ensure that the project +will be successful. Mentors can be maintainers, project leads, advisory board 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 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 +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 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} ------------------ -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 +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 +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 specializations before they can **mature**. --------------------- ------------ ----------------- ---------------- ------------------- -------------------------------------------------------- @@ -145,101 +145,101 @@ work for them, but need to define specializations before they can **mature**. ### Maintainers -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 +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 +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. ### 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)) and/or in the projects MAINTAINERS +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)) and/or in the projects MAINTAINERS files. ### Security Response Team (short: Security Team) -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)). +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](/developers/security-policy)). ### 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 +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)). +A sub-projects leadership team members are listed on the sub-project's team +portal (e.g. [Hypervisor team portal](/developers/teams/hypervisor)). -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 +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} -------------------- -Making contributions in Xen follows the conventions as they are known in the -Linux Kernel community. In summary contributions are made through patches that -are reviewed by the community. Xen does not require community members to sign -contribution or committer agreements. We do require contributors to sign -contributions using the sign-off feature of the code repository, following the -same approach as the Linux Kernel does (see [Developer Certificate Of +Making contributions in Xen follows the conventions as they are known in the +Linux Kernel community. In summary contributions are made through patches that +are reviewed by the community. Xen does not require community members to sign +contribution or committer agreements. We do require contributors to sign +contributions using the sign-off feature of the code repository, following the +same approach as the Linux Kernel does (see [Developer Certificate Of Origin](http://elinux.org/Developer_Certificate_Of_Origin)). -More information on making contributions can be found in the following +More information on making contributions can be found in the following documents: -- [Contribution Guidelines](/help/contribution-guidelines.html) +- [Contribution Guidelines](/help/contribution-guidelines) - [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 +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**. ### 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 +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} +### Expressing Agreement and Disagreement {#expressingopinion} -Within the community, we follow the following number notation to explicitly +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 @@ -248,11 +248,11 @@ express opinions on proposals, formal or informal votes. - **-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 +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 +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 / Lazy Voting](#lazyconsensus) @@ -261,166 +261,171 @@ is used and are marked with Passed/Failed: in one of the following sections: ### Lazy Consensus / Lazy Voting {#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 decision (see below). Lazy Consensus is extremely useful, when you don't -anticipate any objections, or to gauge whether there are objections to a +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 decision (see below). Lazy Consensus is extremely useful, when you don't +anticipate any objections, or to gauge whether there are objections to a proposal. The concrete process in this section is a mixture between Lazy Consensus and Lazy Voting and is designed to avoid unnecessary multiple stages in decision making. -To make use of it, post something like the following on the project's +To make use of it, post something like the following on the project's mailing list (or some other communication channel): - > 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. < +``` {style="padding-bottom: 15px"} +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 +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 +Objections by stake-holders should be expressed using the [conventions above](#expressingopinion) to make disagreements easily identifiable. -__Passed/Failed:__ -The proposer of Lazy Consensus decision is assumed to implicitly have an +**Passed/Failed:** +The proposer of Lazy Consensus decision is assumed to implicitly have an opinion of **+1**, unless otherwise stated. - Failed: A single **-2** by a stake-holder whose approval is necessary - Failed: A total sum of opinions **<=0** - Passed: A total sum of opinions **>0** -It can only be overturned if the project leadership agrees collectively, that -the decision is too important to be settled by lazy consensus / lazy voting. -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. +It can only be overturned if the project leadership agrees collectively, that +the decision is too important to be settled by lazy consensus / lazy voting. +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. -__Further Examples:__ -A Lazy Consensus decision starts out with the implicit **+1** opinion of the -proposer. If there is no explicit response, the proposal passes as the sum +**Further Examples:** +A Lazy Consensus decision starts out with the implicit **+1** opinion of the +proposer. If there is no explicit response, the proposal passes as the sum is **>0**. If there is a single **-1** without any **+** votes, the proposal fails. If there are multiple **+1**'s or **+2**'s, more **-1**'s than positive votes are needed for the proposal to fail. This mechanism, is often also called -**Lazy Voting**. -The process does allow for a proposer to state a starting opinion of **0** or -**-1**. In this case, the Lazy Consensus label does not work for the process, -as positive opinions are needed for the proposal to pass. To make use of this -mechanism, post something like the following on the project's mailing list +**Lazy Voting**. + +The process does allow for a proposer to state a starting opinion of **0** or +**-1**. In this case, the Lazy Consensus label does not work for the process, +as positive opinions are needed for the proposal to pass. To make use of this +mechanism, post something like the following on the project's mailing list (or some other communication channel) - > I want to solicit opinions on X and am going to assume lazy voting: < - > My starting position is **0**, as I feel that at least one other < - > stake-holder should agree with the proposal. < - > If there is a majority in favour, without a **-2** objection within the < - > next seven days, I assume that the proposal holds and does not need < - > require further discussion. < +``` {style="padding-bottom: 15px"} +I want to solicit opinions on X and am going to assume lazy voting: +My starting position is 0, as I feel that at least one other stake-holder +should agree with the proposal.If there is a majority in favour, without a +-2 objection within the next seven days, I assume that the proposal holds and +does not need require further discussion. +``` Unlike in the lazy consensus case, a single **+1** vote is needed. Otherwise the proposal fails. Otherwise, the counting rules follow the general case. -This can be useful in situations, where the proposer is not quite sure about -his/her position, or where the invoker acts on behalf of the community to -resolve a discussion which has become stuck. A starting position of **-1** can -be used to verify that a specific approach may be a bad idea: whether this is +This can be useful in situations, where the proposer is not quite sure about +his/her position, or where the invoker acts on behalf of the community to +resolve a discussion which has become stuck. A starting position of **-1** can +be used to verify that a specific approach may be a bad idea: whether this is really useful, has to be verified as we start using this process. ### Informal Votes or Surveys -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 gauging -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 +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 gauging +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 +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 +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 anonymously. ### 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 +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 +- 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. +- 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 +- 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 +- 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 community manager, to arrange an anonymous vote on behalf +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 community manager, to arrange an anonymous vote on behalf of the leadership team. -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 +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 +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:__ +**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 +- 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 at least 1/3 of positive votes for a proposal** is required for a -resolution to pass. In other words, if the leadership team has 7 members, at -least 3 members need to vote for the resolution. -- The resolution passes, if a 2/3 majority of active votes is in favour of -it. +- A **quorum of at least 1/3 of positive votes for a proposal** is required for a +resolution to pass. In other words, if the leadership team has 7 members, at +least 3 members need to vote for the resolution. +- The resolution passes, if a 2/3 majority of active votes is in favour of +it. -The table below maps the number of leadership team members against the +The table below maps the number of leadership team members against the required quorum: ------------------------------------- --- -- -- -- -- -- -- -- -- **Leadership team members** 10 9 8 7 6 5 4 3 2 - **Positive votes needed for quorum** 4 3 3 3 2 2 2 1 1 + **Positive votes needed for quorum** 4 3 3 3 2 2 2 1 1 ------------------------------------- --- -- -- -- -- -- -- -- -- The table below maps active votes against votes needed to pass: @@ -432,22 +437,22 @@ The table below maps active votes against votes needed to pass: ### 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 +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 +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 the entire Xen Project community becomes paralysed the +In situations where the entire Xen Project community becomes paralysed the impacted project leadership teams or project leads should work with the community manager or advisory board to find a way forward. @@ -455,138 +460,138 @@ community manager or advisory board to find a way forward. #### Maintainer Elections -Developers who have earned the trust of existing maintainers can be promoted to +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. -Alternatively another maintainer may nominate a community member. A nomination -should explain the contributions of proposed maintainer to the project as well -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 +- Nomination: A maintainer should nominate himself by proposing a patch to +the MAINTAINERS file or mailing a nomination to the project's mailing list. +Alternatively another maintainer may nominate a community member. A nomination +should explain the contributions of proposed maintainer to the project as well +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 normal -decision making process. If there is disagreement or doubt, the decision is +- Confirmation: Normally, there is no need for a direct election to confirm a +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 and other Project Leadership Elections -Developers who have earned the trust of committers in their project can through -election be promoted to Committer or Project Leadership (if not covered otherwise). +Developers who have earned the trust of committers in their project can through +election be promoted to Committer 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 -contributions to the project and thus why they should be elected to become a -Committer of the project. The nomination should cite evidence such as patches -and other contributions where the case is not obvious. Existing Committers will -review all proposals, check whether the nominee would be willing to accept the -nomination and publish suitable nominations on the project's public mailing +- Nomination: Community members should nominate candidates by posting a +proposal to *appointments at xenproject dot org* explaining the candidate's +contributions to the project and thus why they should be elected to become a +Committer of the project. The nomination should cite evidence such as patches +and other contributions where the case is not obvious. Existing Committers will +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. In other words, the decision is delegated to the [project -leadership team](#leadership). +- Election: A committer will be elected using the decision making process +outlined earlier. In other words, the decision is delegated to the [project +leadership team](#leadership). -#### Security Response Team Members +#### Security Response Team Members {#security-response-team-members} -Developers who have earned the trust of other security team members can -be promoted to be on the security team. Due to the specific needs of the +Developers who have earned the trust of other security team members can +be promoted to be on the security team. Due to the specific needs of the security team, promotions are typically made by the security team itself and confirmed by lazy consensus within the team. #### Project Lead Elections -Projects which have a project lead, should vote for a project lead in an +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 +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 +- 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 +- 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 +- 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)) +- Changes to existing global namespace policies (e.g. [Mailing List +Conventions](/help/mailing-list/mailing-list-conventions/)) 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 +- 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. -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 +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 + ----------------------------- ----------------------------- ----------------------------- + 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. - ----------------------------------------------------------------------------------------- + Global Process Changes Members of developer mailing Leadership teams of + lists of qualifying projects **mature** sub-projects, + within the scope described + above. + ----------------------------------------------------------------------------------------- -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 +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 is conducted **per project** in line with the following rules: -- Each qualifying project's vote is counted per project and then aggregated +- 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 +- 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 at least least 1/3 of positive votes** of each project's -leadership team members is required. In other words: if a project's leadership -team does not achieve the quorum, the entire sub-project's vote is not counted. -This avoids situations where only a minority of leadership team members vote, -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 +- A **quorum of at least least 1/3 of positive votes** of each project's +leadership team members is required. In other words: if a project's leadership +team does not achieve the quorum, the entire sub-project's vote is not counted. +This avoids situations where only a minority of leadership team members vote, +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 community manager. -__Passed/Failed Resolutions:__ +**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 +- 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 +- 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 +- 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 achieves a 2/3rd majority in favour, the proposal passes. +- If the total vote achieves a 2/3rd majority in favour, the proposal passes. Otherwise it fails. Community Decisions with Funding and Legal Implications {#funding-and-legal} @@ -598,14 +603,14 @@ 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. +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. +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 +In such cases, the impacted project leadership team(s) will contact the Community Manager and/or Advisory Board to resolve possible issues. Project Governance {#project-governance} @@ -615,102 +620,106 @@ Project Governance {#project-governance} The proposal is to follow a simple basic flow: -![](images/articles/governance-xen_projectstages.png) +
    + +![](http://xenproject.org/wp-content/uploads/sites/79/2013/03/governance-xen_projectstages.png){.aligncenter .wp-image-19 .size-full width="901" height="452"} + +
    -A Xenproject.org hosted project starts with an idea which through the 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 +A Xenproject.org hosted project starts with an idea which through the 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. -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 from -the Xen Project. However there will also be regular checkpoints to see whether -the project is progressing. Should it turn out that a project is not viable any -more, it will be archived after an archivation review and vote. For a project -to graduate, some basic conditions must be satisfied. If a project in -incubation has achieved the point where it believes it is mature enough to +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 from +the Xen Project. However there will also be regular checkpoints to see whether +the project is progressing. Should it turn out that a project is not viable any +more, it will be archived after an archivation review and vote. For a project +to graduate, some basic conditions must be satisfied. If a project in +incubation has achieved the point where it believes it is mature enough to graduate, it can request a Graduation community review followed by a vote. -Mature projects are pretty much expected to run themselves. However at some -point a mature project will lose momentum and developers. If this is the case -the Xen Project community can request an archivation review, which follows the +Mature projects are pretty much expected to run themselves. However at some +point a mature project will lose momentum and developers. If this is the case +the Xen Project community can request an archivation review, which follows the usual pattern. Archivation reviews have two purposes: -- give somebody in the community an opportunity to step up and continue a +- give somebody in the community an opportunity to step up and continue a project, -- archive the project outcomes such that they are still available to people +- archive the project outcomes such that they are still available to people who want to use them, but promotion of such projects will cease. -It is also possible to revive archived projects. However these are treated -almost like new projects as projects would only be archived if they have become +It is also possible to revive archived projects. However these are treated +almost like new projects as projects would only be archived if they have become inactive. ### Requesting Reviews, Reviews and Voting -**Requesting Reviews:** Project Proposal and Graduation Reviews are requested -by the (prospective) project lead of the project by contacting the community -manager providing the necessary documentation. An archivation review can be -requested by any maintainer of a mature project or by the Xen Project community -manager. The community manager will then publish relevant material on the +**Requesting Reviews:** Project Proposal and Graduation Reviews are requested +by the (prospective) project lead of the project by contacting the community +manager providing the necessary documentation. An archivation review can be +requested by any maintainer of a mature project or by the Xen Project community +manager. The community manager will then publish relevant material on the respective mailing lists. -**Reviews:** These are off-line reviews which are open to all community members -by which a proposal is published for review. The purpose of the review is +**Reviews:** These are off-line reviews which are open to all community members +by which a proposal is published for review. The purpose of the review is two-fold: -- gather final feedback and input from the community (it is good practice to +- gather final feedback and input from the community (it is good practice to informally do this before the review), -- advertise the project with the aim to attract interest, users and +- advertise the project with the aim to attract interest, users and contributors. -After a review, the requester of the review may decide to withdraw, request a +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 +**Voting:** The community manager arranges a timed private vote as outlined in [Formal Votes](#project-decisions). ### Forming a Project Requirements for forming a sub-project or team on Xenproject.org: -- A project needs a lead, who is willing to become the project lead of the +- A project needs a lead, who is willing to become the project lead of the sub-project -- A project needs a sponsor, which can be a project lead of a mature project, +- A project needs a sponsor, which can be a project lead of a mature project, a member of the Xen Project Advisory Board or the community manager -- There should be no dissent from other community members who would qualify +- There should be no dissent from other community members who would qualify as sponsor (see "Principle: Consensus Decision Making") -- A project needs a mentor, which can be the project sponsor or a maintainer +- A project needs a mentor, which can be the project sponsor or a maintainer of a mature project -- A project needs to have a relationship to other sub-projects or teams, i.e. -it aims to develop software that has a dependency on other sub-projects or -teams hosted on Xenproject.org. If the project needs components in other +- A project needs to have a relationship to other sub-projects or teams, i.e. +it aims to develop software that has a dependency on other sub-projects or +teams hosted on Xenproject.org. If the project needs components in other sub-projects to work, then this should also be stated. -- A project needs to be large and long-term enough to grant a separate -project. For example adding support for a new CPU architecture, adding -additional functionality on top of existing projects, etc. Adding a new feature +- A project needs to be large and long-term enough to grant a separate +project. For example adding support for a new CPU architecture, adding +additional functionality on top of existing projects, etc. Adding a new feature to an existing project should be performed within an existing project. -- A project will deliver code using a license that is compatible with other +- A project will deliver code using a license that is compatible with other sub-projects hosted on Xenproject.org (ideally GPLv2). -The purpose of the project formation phase is to work out what the project is -about, get community buy-in and help the future project gain publicity and -momentum. The formation phase is driven by the project lead. The project -mentor's role is to advise and support the project lead in getting the project +The purpose of the project formation phase is to work out what the project is +about, get community buy-in and help the future project gain publicity and +momentum. The formation phase is driven by the project lead. The project +mentor's role is to advise and support the project lead in getting the project started. -The project proposal is a document that describes and is published on +The project proposal is a document that describes and is published on [wiki.xenproject.org](http://wiki.xenproject.org): -- What the project is aiming to achieve (i.e. the project charter and project +- What the project is aiming to achieve (i.e. the project charter and project goals) -- What components/code and in which code lines (new or components in other +- What components/code and in which code lines (new or components in other projects) the project aims to deliver -- Key dependencies on other sub-projects or teams hosted on Xenproject.org +- Key dependencies on other sub-projects or teams hosted on Xenproject.org (if applicable) - Lists initial maintainers (if applicable) - Lists any interested parties in the project (if applicable) @@ -719,62 +728,62 @@ projects) the project aims to deliver ### Project Proposal Review -The review is initiated by the project lead and follows the rules outlined in +The review is initiated by the project lead and follows the rules outlined in "Requesting Reviews, Reviews and Voting". -After a successful review, the following resources will be created for the +After a successful review, the following resources will be created for the project: - A mailing list - A codeline -- A sub-project or team portal on Xenproject.org (in an area separate from +- A sub-project or team portal on Xenproject.org (in an area separate from mature projects) -- A wiki page on [wiki.xenproject.org](http://wiki.xenproject.org) (this is +- A wiki page on [wiki.xenproject.org](http://wiki.xenproject.org) (this is expected to be maintained by the project lead) ### Incubating a Project -The purpose of the incubation phase is for a project to show that it is -gathering momentum and adheres to the "Principles & Roles" of sub-projects -hosted on Xenproject.org. The project mentor will work closely with the project -lead and there are at least quarterly informal review meetings with the mentor -on how the project is doing. Should a mentor not be able to fulfil his/her role -any more, it is the responsibility of the project lead to find another mentor. -We advise that the project lead gives at least quarterly updates on the Xen +The purpose of the incubation phase is for a project to show that it is +gathering momentum and adheres to the "Principles & Roles" of sub-projects +hosted on Xenproject.org. The project mentor will work closely with the project +lead and there are at least quarterly informal review meetings with the mentor +on how the project is doing. Should a mentor not be able to fulfil his/her role +any more, it is the responsibility of the project lead to find another mentor. +We advise that the project lead gives at least quarterly updates on the Xen Project blog on how the project is doing. -The Xen Project will provide support to incubating projects. The project lead -will work closely with the Xen Project community manager as well as with the +The Xen Project will provide support to incubating projects. The project lead +will work closely with the Xen Project community manager as well as with the project mentor. ### Archiving an Incubating project -The mentor can request for a project to be archived, if the project is not +The mentor can request for a project to be archived, if the project is not making sufficient progress. See "archivation review". ### Graduation Review -The review is initiated by the project lead and follows the rules outlined in -"Requesting Reviews, Reviews and Voting". In essence the project lead makes a +The review is initiated by the project lead and follows the rules outlined in +"Requesting Reviews, Reviews and Voting". In essence the project lead makes a pitch to the community, why the project should graduate. A project must fulfil the following requirements before it can graduate: - It follows the principles of openness, transparency and meritocracy -- It has delivered at least one functioning release of what it is aiming to +- It has delivered at least one functioning release of what it is aiming to deliver -- It has a public code line which shows active development and has mechanisms +- It has a public code line which shows active development and has mechanisms to accept patches (and a history of accepting patches) -- It has a public mailing list that is active (as we get more experience we +- It has a public mailing list that is active (as we get more experience we will add some guidelines) -- It has a mechanism for users to raise bugs and for developers to work on +- It has a mechanism for users to raise bugs and for developers to work on bugs -- It has an active developer community (as we get more experience we will add -some guidelines). But things to look for are number of maintainers, different +- It has an active developer community (as we get more experience we will add +some guidelines). But things to look for are number of maintainers, different organisations involved, number of users, etc. -- It has a project leadership team that resolves conflicts and participates +- It has a project leadership team that resolves conflicts and participates in cross-project decision making -- It adheres to the Xen Project governance as outlined in this document, or +- It adheres to the Xen Project governance as outlined in this document, or documents areas where the sub-project differs Other items to look at during the review (depending on project are): @@ -785,18 +794,18 @@ Other items to look at during the review (depending on project are): ### Mature Projects -Mature projects are expected to be run and promote themselves. The project -leadership team and/or project lead -has significant responsibility in ensuring that this happens. The Xen Project -and the community manager will help organize events, provide opportunities for -the project to get new contributors and build a community, promote new releases -on the blog and to the press, work with project members, etc. However the Xen -Project and the community manager will not get involved in the day-to-day +Mature projects are expected to be run and promote themselves. The project +leadership team and/or project lead +has significant responsibility in ensuring that this happens. The Xen Project +and the community manager will help organize events, provide opportunities for +the project to get new contributors and build a community, promote new releases +on the blog and to the press, work with project members, etc. However the Xen +Project and the community manager will not get involved in the day-to-day running of the project. -At some point during its life cycle a project may lose momentum. In other words -developers and users are not interested in the project any more. If this is the -case, it may be time to archive the project. If the project has achieved its +At some point during its life cycle a project may lose momentum. In other words +developers and users are not interested in the project any more. If this is the +case, it may be time to archive the project. If the project has achieved its goals and is thus completed, it may also be time to archive the project. ### Archivation Review @@ -804,73 +813,73 @@ goals and is thus completed, it may also be time to archive the project. These can happen in a number of situations: - An incubation project shows clear signs of failing and not progressing -- A mature project has lost its developer and user base (and there is little +- A mature project has lost its developer and user base (and there is little or no activity) -- The project has achieved its goals and/or fulfilled its charter: in other +- The project has achieved its goals and/or fulfilled its charter: in other 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 +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 "Requesting Reviews, Reviews and Voting". -The review is essentially a pitch why the project should be archived. The -purpose of the review is not necessarily to archive a project, but also to -provide a last opportunity for interested parties in the Xen Project community -to save the project and step up. The Xen Project community manager will support -efforts to save the project, should community members want to step up. There is -the special case that a project has been completed: in this case the normal +The review is essentially a pitch why the project should be archived. The +purpose of the review is not necessarily to archive a project, but also to +provide a last opportunity for interested parties in the Xen Project community +to save the project and step up. The Xen Project community manager will support +efforts to save the project, should community members want to step up. There is +the special case that a project has been completed: in this case the normal situation would be for the project lead to make the case, why this is so. ### Archived Projects When a project is archived the following happens: -- The codeline and mailing list will be made read-only and made accessible +- The codeline and mailing list will be made read-only and made accessible from an archived projects section on Xenproject.org -- The project's wiki pages will be tagged as **archived**. A project may be -completed (i.e. it has achieved its goals and/or fulfilled its charter) in +- The project's wiki pages will be tagged as **archived**. A project may be +completed (i.e. it has achieved its goals and/or fulfilled its charter) in which case it is tagged as **completed** and **archived**. -- The project or team portal on Xenproject.org will be moved into an -**Archive** section. We may have a **Completed** section within the **Archive** +- The project or team portal on Xenproject.org will be moved into an +**Archive** section. We may have a **Completed** section within the **Archive** section. -In cases where the project has delivered code into other sub-projects hosted on +In cases where the project has delivered code into other sub-projects hosted on Xenproject.org, the code will be - Deprecated at the point where the project is archived -- The project which now contains the archived code can (but does not have to) -remove the code in a subsequent release (it should however give users +- The project which now contains the archived code can (but does not have to) +remove the code in a subsequent release (it should however give users sufficient time to adapt) ### Exceptional Circumstances {#exceptional-circumstances} #### Incubation Projects without Project Lead -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 +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 +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 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 +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 +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 +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} @@ -881,8 +890,8 @@ Add specialisations to this section, as they surface. Change History -------------- -- **v3.0 December 2016:** Refactored document. Otherwise significant changes to -decision making, in the following areas +- **v3.0 December 2016:** Refactored document. Otherwise significant changes +to decision making, in the following areas - Added Goal: Local Decision Making - Split roles into project wide and sub-project specific roles - Added new roles: Community Manager, Security Response Team, Leadership Team @@ -898,30 +907,28 @@ decision making, in the following areas - Clarified scope of Decision making - Added section on Community Decisions with Funding and Legal Implications - Modified all other sections which have dependencies on changes above - - Added Per Sub-Project Governance Specialisation -- **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 -[vote](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01614.html -) -- **v2.0 May 2012:** Changes to reflect transition from xen.org to + - Added Per Sub-Project Governance Specialisation +- **v2.1 May 2016:** Clarify Committer Elections as per this +[discussion](https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00801.html) and +[vote](https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01614.html) +- **v2.0 May 2012:** Changes to reflect transition from xen.org to xenproject.org - - Added definitions for Sub-projects and Teams, Xen Project Advisory + - Added definitions for Sub-projects and Teams, Xen Project Advisory Board and The Linux Foundation. - - Removed Xen.org Chairman as Referee of Last Resort and delegated this + - Removed Xen.org Chairman as Referee of Last Resort and delegated this role to the Xen Project Advisory Board. - Allow Xen Project Advisory Board members to be Mentors. - - Clarify scope and eligible votes in Formal Votes; refer to this section + - Clarify scope and eligible votes in Formal Votes; refer to this section from Requesting Reviews, Reviews and Voting rather than duplicating - - Rename xen.org to xenproject.org or Xen Project throughout the document + - Rename xen.org to xenproject.org or Xen Project throughout the document (except in the history) - Refer to sub-projects and teams instead of projects where appropriate -- **[v1.2](index.php?option=com_content&view=archive&year=2013&month=3) May +- **[v1.2](index.php?option=com_content&view=archive&year=2013&month=3) May 2012:** Minor changes - Fixed typo and ambiguity in the role of Project Lead. - Added section on Conflict Resolution. - **v1.1 Oct 2011:** Minor changes - Clarified the roles of Committer and Maintainer. - - Added Making Contributions which contains links to other documentation + - 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:** Initial document approved \ No newline at end of file +- **v1.0 Jun 2011:** Initial document approved