The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)


Governance draft

From Mer Wiki
(Difference between revisions)
Jump to: navigation, search
(The Mer Project Community)
Line 17: Line 17:
 
The following conceptual diagram loosely illustrates how various groups influence one another within the Mer project.
 
The following conceptual diagram loosely illustrates how various groups influence one another within the Mer project.
  
....
+
[[Image:http://www.yoctoproject.org/sites/all/files/resize/pages/yocto-governance-600x447.png]]
  
 
= Roles =
 
= Roles =

Revision as of 14:37, 16 October 2011

Contents

Governance DRAFT

The Mer project governance is modelled upon that of the Yocto Project, http://www.yoctoproject.org/about/governance and this document is based off that document, which is under Creative Commons Attribution 3.0 License.

The Mer Project is Open to All Contributors

Because the Mer Project requires no admission processes, contracts, or membership fees, any individual or organization can join and contribute. The only real requirement is your desire to join and contribute to its success. We welcome all contributions that lead to the success of the project - including software development, documenation, testing, and marketing.

The Mer Project Leadership

The Mer Project leadership and governance principle is based on meritocracy, which is very similar to how the Linux kernel and many other Open Source projects work. Consequently, technical leaders as well as sub-system maintainers are selected based on the quality and quantity of their contribution to the Mer Project in relevant areas.

The Mer Project Community

The Mer Project software is developed and designed using a collaborative effort by an open community of professionals and volunteers – collectively known as contributors. Contributors include anyone that is positively contributing to the Mer Project.

The following conceptual diagram loosely illustrates how various groups influence one another within the Mer project.

File:Http://www.yoctoproject.org/sites/all/files/resize/pages/yocto-governance-600x447.png

Roles

Because building a functional OS Core requires the coordinated efforts of people in many types of roles, the Mer Project has a particular mix of roles and responsibilities:

Maintainer

As in most open source projects, project code is divided into logical sub-projects and Maintainers are assigned to these sub-projects. The Maintainer, who is the delegated authority, reviews patches that are submitted by contributors and technical leaders, provides feedback to the developers, and accepts the ones that are appropriate. Project Maintainers armed with open input from the community make nearly every decision on the project. Options for a particular component are normally vetted on an appropriate project mailing list and input is solicited before decisions are made. The Maintainers are influenced by requirements set by Interest Groups and code contributed by the community. Contributors are elevated to Maintainers through meritocracy.

Technical Leaders

The Technical Leaders, along with a Maintainer, work within sub-projects to ensure component excellence and functionality. Any given sub-project can have zero to many Technical Leaders involved. Contributors are elevated to Technical Leadership though meritocracy.

Interest Groups

These groups define and document the various requirements for the Mer Project, which are formed around the strongest needs for the Project’s users. Various technical leaders take these requirements and work with the Maintainers to develop plans that can then be executed along a roadmap. Anyone can form an interest group and after sanity check, they will be offered a mailing list and wiki page for organising themselves. An interest group must appoint a representative towards the Mer project.

Architect

The Project Architect, who encompasses all project work, resolves conflicts and provides overall leadership.

Advisory board

The advisory board consists of 9 people and consists of two representatives from the Interest Groups grouping, two from the Maintainers grouping and Technical Leaders grouping, along the Architect as chairman and non-voting tie-breaker. The AB is responsible for advising and influencing but not deciding technical direction. The group is meeting monthly on IRC.

The AB recognises merit and formally elevates contributors to Maintainers and to Technical Leaders based on merit and can select a new Architect amongst Technical Leaders. The AB can create administrative groups for the improvement of the project, such as outreach, research and other administrative tasks.

The representatives from the Interest Groups grouping is selected by how many maintainers (counting one vote) and technical leaders (counting two votes) claim public primary allegiance to that specific Interest Group - by the principle that contribution creates influence. The interest groups then elect the representatives using these votes.

The representatives from the Maintainers is selected by an election within the grouping. This is the same case as with the Technical Leaders. If a person is both Maintainer and Technical Leader, he/she can only vote within Technical Leaders and Interest Group vote.

Personal tools