|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] [PATCH v3 1/4] Code motion changes to make real patches easier to read
On Fri, Sep 23, 2016 at 07:55:26PM +0100, Lars Kurth wrote:
> Added TOC
> Re-arranged sections compared to previous version of document
> Added new anchors where needed
> Split Roles section into two sections
>
> The actual content was not changed (with the exception of minor
> typos that I spotted)
>
> Signed-off-by: Lars Kurth <lars.kurth@xxxxxxxxxx>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> ---
> governance.pandoc | 207
> +++++++++++++++++++++++++++++-------------------------
> 1 file changed, 113 insertions(+), 94 deletions(-)
>
> diff --git a/governance.pandoc b/governance.pandoc
> index 60fc942..2ce780c 100644
> --- a/governance.pandoc
> +++ b/governance.pandoc
> @@ -1,9 +1,20 @@
> -
> -This document has come in effect in June 2011 and will be
> -reviewed periodically (see revision sections). The last modification has
> been
> -made in May 2013.
> -
> -Goals
> +This document has come in effect in June 2011 and will be reviewed
> periodically
> +(see revision sections). The last modification has been made in July 2016.
> +
> +Content
> +-------
> +
> +- [Goals](#goals)
> +- [Principles](#principles)
> +- [Xen Project Wide Roles](#roles-global)
> +- [Project Team Roles](#roles-local)
> +- [Making Contributions](#contributions)
> +- [Decision Making, Conflict Resolution, Role Nominations and
> +Elections](#decisions)
> +- [Formal Votes](#formal-votes)
> +- [Project Governance](#project-governance)
> +
> +Goals {#goals}
> -----
>
> The goals of Xen Project Governance are to:
> @@ -22,7 +33,7 @@ going elsewhere
> - Set clear expectations to vendors, upstream and downstream projects and
> community members
>
> -Principles
> +Principles {#principles}
> ----------
>
> ### Openness
> @@ -43,71 +54,8 @@ The Xen Project is a meritocracy. The more you contribute
> the more
> responsibility you will earn. Leadership roles in Xen are also merit-based
> and
> earned by peer acclaim.
>
> -### Consensus Decision Making
> -
> -Sub-projects or teams hosted on Xenproject.org are normally auto-governing
> and
> -driven by the people who volunteer for the job. This functions well for most
> -cases. When more formal decision making and coordination is required,
> decisions
> -are taken with a lazy consensus approach: a few positive votes with no
> negative
> -vote are enough to get going.
> -
> -Voting is done with numbers:
> -
> -- +1 : a positive vote
> -- 0 : abstain, have no opinion
> -- -1 : a negative vote
> -
> -A negative vote should include an alternative proposal or a detailed
> -explanation of the reasons for the negative vote. The project community then
> -tries to gather consensus on an alternative proposal that resolves the
> issue.
> -In the great majority of cases, the concerns leading to the negative vote
> can
> -be addressed.
> -
> -### Conflict Resolution
> -
> -#### Refereeing
> -
> -Sub-projects and teams hosted on Xenproject.org are not democracies but
> -meritocracies. In situations where there is disagreement on issues related
> to
> -the day-to-day running of the project, Committers and Project Leads are
> -expected to act as referees and make a decision on behalf of the community.
> -Referees should however consider whether making a decision may be divisive
> and
> -damaging for the community. In such cases, the committer community of the
> -project can privately vote on an issue, giving the decision more weight.
> -
> -#### Last Resort
> -
> -In some rare cases, the lazy consensus approach may lead to the community
> being
> -paralyzed. Thus, as a last resort when consensus cannot be achieved on a
> -question internal to a project, the final decision will be made by a private
> -majority vote amongst the committers and project lead. If the vote is tied,
> the
> -project lead gets an extra vote to break the tie.
> -
> -For questions that affect several projects, committers and project leads of
> -mature projects will hold a private majority vote. If the vote is tied, the
> -[Xen Project Advisory Board](/join.html) will break the tie through a
> casting
> -vote.
> -
> -Roles
> ------
> -
> -### Maintainers
> -
> -Maintainers own one or several components in the Xen tree. A maintainer
> reviews
> -and approves changes that affect their components. It is a maintainer's
> prime
> -responsibility to review, comment on, co-ordinate and accept patches from
> other
> -community member's and to maintain the design cohesion of their components.
> -Maintainers are listed in a MAINTAINERS file in the root of the source tree.
> -
> -### Committers
> -
> -Committers are Maintainers that are allowed to commit changes into the
> source
> -code repository. The committer acts on the wishes of the maintainers and
> -applies changes that have been approved by the respective maintainer(s) to
> the
> -source tree. Due to their status in the community, committers can also act
> as
> -referees should disagreements amongst maintainers arise. Committers are
> listed
> -on the sub-project's team portal (e.g. [Hypervisor team
> -portal](/developers/teams/hypervisor.html)).
> +Xen Project Wide Roles {#roles-global}
> +----------------------
>
> ### Sub-projects and Teams
>
> @@ -118,16 +66,6 @@ projects) are run by individuals and are often referred
> to as teams to
> highlight the collaborative nature of development. For example, each
> sub-project has a [team portal](/developers/teams.html) on Xenproject.org.
>
> -### Project Lead
> -
> -Sub-projects and teams hosted on Xenproject.org are managed by a Project
> Lead,
> -who also is a committer of the sub-project/team he/she leads. Project Leads
> are
> -the public figurehead of the project and is responsible for the health of
> the
> -project. Due to their status in the community, project leads can also act as
> -referees should disagreements amongst committers of the project arise. The
> -project lead typically also has write access to resources, such as the web
> page
> -of a specific project.
> -
> ### Xen Project Advisory Board
>
> The [Xen Project Advisory Board](/join.html) consists of members who are
> @@ -162,7 +100,38 @@ committer of a mature project, a member of the advisory
> board or the community
> manager. This ensures that a distinguished community member supports the
> idea
> behind the project.
>
> -Making Contributions
> +Project Team Roles {#roles-local}
> +------------------
> +
> +### Maintainers
> +
> +Maintainers own one or several components in the Xen tree. A maintainer
> reviews
> +and approves changes that affect their components. It is a maintainer's
> prime
> +responsibility to review, comment on, co-ordinate and accept patches from
> other
> +community member's and to maintain the design cohesion of their components.
> +Maintainers are listed in a MAINTAINERS file in the root of the source tree.
> +
> +### Committers
> +
> +Committers are Maintainers that are allowed to commit changes into the
> source
> +code repository. The committer acts on the wishes of the maintainers and
> +applies changes that have been approved by the respective maintainer(s) to
> the
> +source tree. Due to their status in the community, committers can also act
> as
> +referees should disagreements amongst maintainers arise. Committers are
> listed
> +on the sub-project's team portal (e.g. [Hypervisor team
> +portal](/developers/teams/hypervisor.html)).
> +
> +### Project Lead
> +
> +Sub-projects and teams hosted on Xenproject.org are managed by a Project
> Lead,
> +who also is a committer of the sub-project/team he/she leads. Project Leads
> are
> +the public figurehead of the project and is responsible for the health of
> the
> +project. Due to their status in the community, project leads can also act as
> +referees should disagreements amongst committers of the project arise. The
> +project lead typically also has write access to resources, such as the web
> page
> +of a specific project.
> +
> +Making Contributions {#contributions}
> --------------------
>
> Making contributions in Xen follows the conventions as they are known in the
> @@ -176,12 +145,60 @@
> Origin](http://elinux.org/Developer_Certificate_Of_Origin)).
> More information on making contributions can be found in the following
> documents:
>
> -- [Contribution Guidelines](g/help/contribution-guidelines.html)
> +- [Contribution Guidelines](/help/contribution-guidelines.html)
> +
> +Decision Making, Conflict Resolution, Role Nominations and Elections
> +{#decisions}
> +--------------------------------------------------------------------
> +
> +### Consensus Decision Making
> +
> +Sub-projects or teams hosted on Xenproject.org are normally auto-governing
> and
> +driven by the people who volunteer for the job. This functions well for most
> +cases. When more formal decision making and coordination is required,
> decisions
> +are taken with a lazy consensus approach: a few positive votes with no
> negative
> +vote are enough to get going.
> +
> +Voting is done with numbers:
> +
> +- +1 : a positive vote
> +- 0 : abstain, have no opinion
> +- -1 : a negative vote
> +
> +A negative vote should include an alternative proposal or a detailed
> +explanation of the reasons for the negative vote. The project community then
> +tries to gather consensus on an alternative proposal that resolves the
> issue.
> +In the great majority of cases, the concerns leading to the negative vote
> can
> +be addressed.
> +
> +### Conflict Resolution
> +
> +#### Refereeing
> +
> +Sub-projects and teams hosted on Xenproject.org are not democracies but
> +meritocracies. In situations where there is disagreement on issues related
> to
> +the day-to-day running of the project, Committers and Project Leads are
> +expected to act as referees and make a decision on behalf of the community.
> +Referees should however consider whether making a decision may be divisive
> and
> +damaging for the community. In such cases, the committer community of the
> +project can privately vote on an issue, giving the decision more weight.
> +
> +#### Last Resort
> +
> +In some rare cases, the lazy consensus approach may lead to the community
> being
> +paralyzed. Thus, as a last resort when consensus cannot be achieved on a
> +question internal to a project, the final decision will be made by a private
> +majority vote amongst the committers and project lead. If the vote is tied,
> the
> +project lead gets an extra vote to break the tie.
> +
> +For questions that affect several projects, committers and project leads of
> +mature projects will hold a private majority vote. If the vote is tied, the
> +[Xen Project Advisory Board](/join.html) will break the tie through a
> casting
> +vote.
>
> -Elections and Formal Votes
> ---------------------------
> +### Elections
>
> -### Maintainer Elections
> +#### Maintainer Elections
>
> Developers who have earned the trust of maintainers (including the project
> lead) can be promoted to Maintainer. A two stage mechanism is used
> @@ -199,7 +216,7 @@ principles of consensus decision making. If there is
> disagreement or doubt, the
> project lead or a committer should ask the community manager to arrange a
> more
> formal vote.
>
> -### Committer Elections
> +#### Committer Elections
>
> Developers who have earned the trust of committers in their project can
> through
> election be promoted to Committer. A two stage mechanism is used
> @@ -219,21 +236,22 @@ negative vote the project lead and community manager
> will try and resolve the
> situation and reach consensus. Results will be published on the public
> mailing
> list.
>
> -### Project Lead Elections
> +#### Project Lead Elections
>
> Projects which lose their project lead are at risk of failing. Should this
> occur, the project's maintainer community should agree who would want to
> be/be
> able to be the new project lead and follow the election process as outlined
> above.
>
> -### Formal Votes
> +Formal Votes {#formal-votes}
> +------------
>
> Sometimes it is necessary to conduct formal voting within the community
> (outside of elections). Formal votes are necessary when processes and
> procedures are introduced or changed, or as part of the [Project
> Governance](#project-governance). Who is eligible to vote, depends on
> whether
> the scope of a process or procedure is **local** to a sub-project or team,
> or
> -whether it affects **all sub-projects** (or in other words, is**global**).
> +whether it affects **all sub-projects** (or in other words, is **global**).
> Examples of local scope is the [Security Policy](/security-policy.html)
> which
> applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only.
> Examples of global scope are changes to this document or votes outlined in
> the
> @@ -263,7 +281,7 @@ each. For voting a traceable poll mechanism (e.g. voting
> form that keeps
> auditable and tamper proof records) must be used. Voting follows the
> conventions as laid out in "Principle: Consensus Decision Making".
>
> -Project Governance
> +Project Governance {#project-governance}
> ------------------
>
> ### Basic Project Life Cycle
> @@ -461,7 +479,7 @@ words it has completed
>
> In the first case the review is triggered by the incubation project's
> mentor.
> Failing this the review can be requested by any maintainer of a mature
> project
> -(including the projec's lead) or by the Xen Project community manager. See
> +(including the project's lead) or by the Xen Project community manager. See
> "Requesting Reviews, Reviews and Voting".
>
> The review is essentially a pitch why the project should be archived. The
> @@ -514,6 +532,7 @@ will support the project lead in finding a new mentor.
> Change History
> --------------
>
> +- **v3.0 July 2016:** TODO: Add real changelog in main patch
> - **v2.1 May 2016:** Clarify Committer Elections as per this
>
> [discussion](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg0080
> 1.html) and
> @@ -539,6 +558,6 @@ from Requesting Reviews, Reviews and Voting rather than
> duplicating
> - Clarified the roles of Committer and Maintainer.
> - Added Making Contributions which contains links to other
> documentation
> and highlights that Xen.org required a DCO for contributions since 2005.
> -- **v1.0 Jun 2011:** Intial document approved
> +- **v1.0 Jun 2011:** Initial document approved
>
>
> \ No newline at end of file
> --
> 2.5.4 (Apple Git-61)
>
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |