Revision as of 14:16, 16 October 2011

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

Architect

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

Advisory board

The advisory board consists of equal amount of representatives from the Interest Groups, Maintainers and Technical Leaders, with the Architect as chairman and tie-breaker and 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 and can select a new Architect within Technical Leaders.

The AB can create administrative groups for the improvement of the project, such as outreach, research and other administrative tasks.