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
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.
  
 +
....
  
 
= Roles =
 
= Roles =
Line 22: Line 23:
 
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:
 
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.
+
== Maintainer ==
  
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.
+
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.
  
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.
+
== Technical Leaders ==
  
Architect– The Project Architect, who encompasses all project work, resolves conflicts and provides overall leadership.
+
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.
 +
 
 +
== Architect ==
 +
 
 +
The Project Architect, who encompasses all project work, resolves conflicts and provides overall leadership.

Revision as of 13: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.

....

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.

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.

Architect

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

Personal tools