The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Governance draft
(→Interest Groups) |
|||
| (10 intermediate revisions by 4 users not shown) | |||
| Line 5: | Line 5: | ||
== The Mer Project is Open to All Contributors == | == 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, | + | 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, documentation, testing, and marketing. |
= The Mer Project Leadership = | = The Mer Project Leadership = | ||
| 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. | ||
| − | ... | + | http://www.yoctoproject.org/sites/all/files/resize/pages/yocto-governance-600x447.png |
= Roles = | = Roles = | ||
| Line 25: | Line 25: | ||
== Maintainer == | == 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. | + | 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 == | == Technical Leaders == | ||
| Line 33: | Line 33: | ||
== Interest Groups == | == 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. | + | 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. |
| + | |||
| + | To register as an interest group in Mer, send an e-mail to the current Project Architect, stating the name of the interest group, who your representative towards Mer is (full name, email) and who you are representing (abstract form is OK), if you want an e-mail list for your interest group (and it's name) and wiki page. | ||
== Architect == | == Architect == | ||
The Project Architect, who encompasses all project work, resolves conflicts and provides overall leadership. | The Project Architect, who encompasses all project work, resolves conflicts and provides overall leadership. | ||
| + | |||
| + | == Advisory board == | ||
| + | |||
| + | The advisory board consists of 7 people and consists of two representatives from the Interest Groups grouping, two from the Maintainers grouping and two from the 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 claim allegiance to a Interest Group. | ||
| + | |||
| + | = Organisational Structure = | ||
| + | |||
| + | Mer will be setup as a non-profit organisation with the Advisory Board as the board. | ||
| + | |||
| + | The AB will delegate operational, financial and general administrative duties. | ||
Latest revision as of 06:18, 20 January 2012
Contents |
[edit] 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.
[edit] 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, documentation, testing, and marketing.
[edit] 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.
[edit] 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.
http://www.yoctoproject.org/sites/all/files/resize/pages/yocto-governance-600x447.png
[edit] 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:
[edit] 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.
[edit] 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.
[edit] 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.
To register as an interest group in Mer, send an e-mail to the current Project Architect, stating the name of the interest group, who your representative towards Mer is (full name, email) and who you are representing (abstract form is OK), if you want an e-mail list for your interest group (and it's name) and wiki page.
[edit] Architect
The Project Architect, who encompasses all project work, resolves conflicts and provides overall leadership.
[edit] Advisory board
The advisory board consists of 7 people and consists of two representatives from the Interest Groups grouping, two from the Maintainers grouping and two from the 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 claim allegiance to a Interest Group.
[edit] Organisational Structure
Mer will be setup as a non-profit organisation with the Advisory Board as the board.
The AB will delegate operational, financial and general administrative duties.
