Growing a community around ARM templates: governance model

[SorraTheOrc]

We want to grow a viable community around ARM templates. The goal is to ensure we can scale to accommodate as many contributions as we attract (truth is we are already struggling to stay on top of the pull requests - keep it up folks!)

To this end I propose the following lightweight governance model. It's heavily based on the model found in Apache projects and seeks to recognize and reward merit through active contribution. I welcome comments...

Overview

This is a meritocratic, consensus-based community project. Anyone with an interest in the project can join the community, contribute to our templates and supporting materials and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the project community.

Roles and responsibilities

We are a self-organizing groups. Roles are defined to help people identify how they can help. There are a few things (like commit access to our repository) that require people to earn merit first, but in the whole everyone should feel free to help in any of the roles and responsibilities identified below.

Users

Users are community members who find our project outputs useful. Users are the most important members of the community. Without them the project would have no purpose. Anyone can be a user; there are no special requirements.
User contributions enable the project team to ensure that they are satisfying people's needs. Common user contributions include (but are not limited to):

• evangelizing about the project (e.g. a link on a website, tweets, blogs and word-of-mouth awareness raising)
• informing developers of strengths and weaknesses from a new user perspective • providing moral support (a ‘thank you’ goes a long way)

Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors, as described in the next section.

Contributors

Contributors are community members who contribute directly to the deliverables of the project. Anyone can become a contributor, and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
In addition to their actions as users, contributors may also find themselves doing one or more of the following:

• supporting new users (existing users are often the best people to support new users)
• reporting bugs
• reviewing pull requests
• identifying requirements
• providing graphics and web design
• programming
• assisting with project infrastructure
• writing documentation
• fixing bugs
• adding features

Contributors engage with the project through the issue tracker (which is fully integrated into mail clients for those who prefer such approaches). Changes to project resources such as templates, code and documentation are submitted via pull requests. These pull requests will be considered for inclusion in the project by project maintainers (see next section).

As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated as a committer.

Committer

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Being a committer allows contributors to more easily carry on with their project related activities by giving them write access to the project’s resources. That is, they can make changes directly to project outputs, without having to wait for another maintainer to review them.

This does not mean that a committer is free to do what they want. In fact, committers have no more authority over the project than contributors. While being a committer makes it faster to get changes into the project repositories this work continues to be reviewed by the community before formal acceptance into the project. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before (this is called commit-then-review, while contributors operate through a review-then-commit process using pull requests).

It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole. By the time a contributor is invited to become a committer, they will have become familiar with the project’s review processes and acceptance criteria.

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a committer will demonstrate that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time.

New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the project management committee (PMC; see below). Committer voting is one of the few activities that takes place on the project’s private management list. This is to allow PMC members to freely express their opinions about a nominee without causing embarrassment.

It is important to recognize that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC (see next section) in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.

A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the PMC. This role is described below.

Project Management Committee

The Project Management Committee (PMC) consists of those individuals identified as ‘project owners’ on the development site. The PMC has additional responsibilities over and above those of a committer. These responsibilities ensure the smooth running of the project. PMC members are expected to review all contribution to project outputs, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.

Members of the PMC do not have significant authority over other members of the community, although it is the PMC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PMC has access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.
Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.

Chair

The PMC Chair is a single individual, voted for by the PMC members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the PMC casts a two-thirds majority vote to remove them.

The PMC Chair has no additional authority over other members of the PMC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.

[SorraTheOrc]

Governance doc moved to https://github.com/Azure/azure-quickstart-templates/wiki/Project-Governance