From: Ian Jackson Date: Fri, 8 Jul 2016 15:45:39 +0000 (+0100) Subject: governance.html: from Lars X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=971af9f82b7635dd6a9e2b023aab3f37bad8d25d;p=people%2Flarsk%2Fsecurity-process.git governance.html: from Lars --- diff --git a/governance.html b/governance.html new file mode 100644 index 0000000..085235a --- /dev/null +++ b/governance.html @@ -0,0 +1,536 @@ +

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

+

+

Goals

+

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.

+

Transparency

+

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.

+

Consensus Decision Making

+

Sub-projects or teams hosted on Xenproject.org are normally +auto-governing and driven by the people who volunteer for the job. This +functions well for most cases. When more formal decision making and +coordination is required, decisions are taken with a lazy consensus +approach: a few positive votes with no negative vote are enough to get +going.

+

Voting is done with numbers:

+ +

A negative vote should include an alternative proposal or a detailed +explanation of the reasons for the negative vote. The project community +then tries to gather consensus on an alternative proposal that resolves +the issue. In the great majority of cases, the concerns leading to the +negative vote can be addressed.

+

Conflict Resolution

+

Refereeing

+

Sub-projects and teams hosted on Xenproject.org are not +democracies but meritocracies. In situations where there is disagreement +on issues related to the day-to-day running of the project, Committers and +Project Leads are expected to act as referees and make a decision on +behalf of the community. Referees should however consider whether making a +decision may be divisive and damaging for the community. In such cases, +the committer community of the project can privately vote on an issue, +giving the decision more weight.

+

Last Resort

+

In some rare cases, the lazy consensus approach may lead to the +community being paralyzed. Thus, as a last resort when consensus cannot be +achieved on a question internal to a project, the final decision will be +made by a private majority vote amongst the committers and project lead. +If the vote is tied, the project lead gets an extra vote to break the +tie.

+

For questions that affect several projects, committers and project +leads of mature projects will hold a private majority vote. If the vote is +tied, the Xen Project Advisory +Board will break the tie through a casting vote.

+

+

Roles

+

Maintainers

+

Maintainers own one or several components in the Xen tree. A maintainer +reviews and approves changes that affect their components. It is a +maintainer's prime responsibility to review, comment on, co-ordinate and +accept patches from other community member's and to maintain the design +cohesion of their components. Maintainers are listed in a MAINTAINERS file +in the root of the source tree.

+

Committers

+

Committers are Maintainers that are allowed to commit changes into the +source code repository. The committer acts on the wishes of the +maintainers and applies changes that have been approved by the respective +maintainer(s) to the source tree. Due to their status in the community, +committers can also act as referees should disagreements amongst +maintainers arise. Committers are listed on the sub-project's team portal +(e.g. Hypervisor team portal).

+

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.

+

Project Lead

+

Sub-projects and teams hosted on Xenproject.org are managed by a +Project Lead, who also is a committer of the sub-project/team he/she +leads. Project Leads are the public figurehead of the project and is +responsible for the health of the project. Due to their status in the +community, project leads can also act as referees should disagreements +amongst committers of the project arise. The project lead typically also +has write access to resources, such as the web page of a specific +project.

+

Xen Project Advisory Board

+

The Xen Project Advisory +Board 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.

+

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.

+

Sponsor

+

To form a new sub-project or team on Xenproject.org, we require a +sponsor to support the creation of the new project. A sponsor can be a +project lead or committer of a mature project, a member of the advisory +board or the community manager. This ensures that a distinguished +community member supports the idea behind the project.

+

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:

+ +

Elections and Formal Votes

+

Maintainer Elections

+

Developers who have earned the trust of maintainers (including the +project lead) can be promoted to Maintainer. A two stage mechanism is +used

+ +

Committer Elections

+

Developers who have earned the trust of committers in their project can +through election be promoted to Committer. A two stage mechanism is +used

+ +

Project Lead Elections

+

Projects which lose their project lead are at risk of failing. Should +this occur, the project's maintainer community should agree who would want +to be/be able to be the new project lead and follow the election process +as outlined above.

+

+

Formal Votes

+

Sometimes it is necessary to conduct formal voting within the community +(outside of elections). Formal votes are necessary when processes and +procedures are introduced or changed, or as part of the Project Governance. Who is eligible to +vote, depends on whether the scope of a process or procedure is +local to a sub-project or team, or whether it affects all +sub-projects (or in other words, is global). Examples +of local scope is the Security Policy which +applies to the Hypervisor Project only. +Examples of global scope are changes to this document or votes outlined in +the Project Governance.

+

+ + + + + + + + + + + + + + + + + + +
ScopeWho reviews?Who votes?
LocalMembers of developer mailing lists of the affected projects.Maintainers of the project (or projects), which are affected by the +process, procedure, etc. are allowed to vote. This includes maintainers +from incubation projects (if the scope affects the project).
GlobalMembers of all developer mailing lists of all sub-projects hosted on +Xenproject.org.Maintainers of all mature projects and the Xenproject.org +community manager are allowed to vote.
+

+

The community manager first arranges a public review, followed by a +timed private vote. Public review and voting should be open for a minimum +of a week each. For voting a traceable poll mechanism (e.g. voting form +that keeps auditable and tamper proof records) must be used. Voting +follows the conventions as laid out in "Principle: Consensus Decision +Making".

+

+

Project Governance

+

Basic Project Life Cycle

+

The proposal is to follow a simple basic flow:

+

governance-xen projectstages

+

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.

+

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:

+ +

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:

+ +

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:

+ +

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.

+

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

+

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:

+ +

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

+ +

In the first case the review is triggered by the incubation project's +mentor. Failing this the review can be requested by any maintainer of a +mature project (including the projec's lead) or by the Xen Project +community manager. See "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:

+ +

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

+ +

Exceptional Circumstances

+

Projects without Project Lead

+

Projects which lose their project lead during the incubation or +maturity phase are at risk of failing. Should this occur, the project's +maintainer community should agree who would want to be/be able to be the +new project lead and follow the election process as outlined in "Electing +Maintainers".

+

If a project lead leaves during the formation phase, without finding a +successor we assume that the project does not have enough momentum and +will not go ahead.

+

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.

+

Change History

+
+ +