FIXME: Need to explain terms before they are used (meritocratic in the intro sentence, benevolent dictatorship in the second para).

This document provides an example of a governance model in a project governed through meritocracy. See also our more general description of [GovernanceModel].

A meritocratic governance model is, at its most extreme, the one that appears to give control away to community members in response to their contributions to the project. The Apache Software Foundation, perhaps the most famous example of a large scale meritocratic community, are very proud of the fact that they operate with an almost completely flat structure. However, even this model is designed so that those with control today can decide who gets control tomorrow. In this way project leaders ensure that only those sharing a common vision and, just as importantly, the willingness to work towards that shared vision, are given decision making authority. The "flatness" comes from the fact that once someone has decision making authority they have exactly the same authority as everyone else. Another aspect to the flatness of a meritocratic project comes from the fact that decision making responsibilities are usually reserved for those willing and able to understand and appropriately represent the views of the wider community.

Meritocratic projects often start life as a small number of decision makers, possibly even a single person, who provide a mechanism for the distribution of control from the dictator to a fully flat structure in recognition of contribution. Thus even a meritocratic model may look and behave like a benevolent dictator model in the early days.

The example model provided below is designed to be as near to the "community" end of this spectrum as we believe is sensible. It is based on the meritocratic model used in The Apache Software Foundation, although it should be noted that individual ASF projects are free to design their own bylaws, therefore this model is not likely to be identical to that employed in any given project.

The example is written to provide a starting point for your own projects governance model. Simply take this text, replace "Project-X" with your project title and customise it accordingly. However, we urge you to remember that the key to a good meritocratic model is that there is a clear way for people to contribute and a highly visible reward system. OSS Watch are here to help you fine tune your model.

Overview

Project-X is a consensus-based community project. Our governance model is inspired by that used within The Apache Software Foundation projects. Anyone with an interest in Project-X can contribute to the project's design, documentation and strategy. Anyone can join the project community and participate in the decision-making process. This document describes how that participation takes place and how one can increase ones influence on the project.

Roles and Responsibilities

FIXME: Consider using the figure of 8 model to define the roles

Users

Users are community members who have a need for Project-X. Anyone can be a user, there are no special requirements. Users are the most important members of our community, without them the project is nothing more than a white elephant.

We ask that our users participate in the project and community as much as possible, it is user contributions that enable us to ensure we are satisfying the needs of those users.

Common user activities include (but are not limited to):

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

Contributors

Contributors are community members who contribute in concrete ways to the project. Contributions can take many forms, such as those outlined below and in the above section on users. Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process.

Contributors will already be performing actions as a user (see above) but will also find themselves doing one or more of the following:

As contributors gain experience and familiarity with the project they may find that making such contributions becomes easier. As a contributors profile and commitment increases they may be nominated for committership, as described in the next section.

Committer

Committers are community members who have shown that they are committed to the continued development of Project-X through ongoing engagement with the project and its community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the projects resources. That is, they can make changes directly to project outputs rather than having to submit changes via patches.

This does not mean that a committer is free to do what they want. Actually they have no more authority over the project than a contributor (although they do have a "binding vote", see the section on Decision Making below). Instead it means that they have shown themselves to be valued members of the community with a healthy respect for the projects aims and objectives. Their work continues to be reviewed by the community and it must be accepted by the community before it will be included in a release. However, this approval is sought after the contribution is made, rather than before.

This is known as as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions as the majority of those contributions will be accepted by the project. We employ various communication mechanisms to ensure that all contributions are reviewed by the community as a whole, however, there is no need to detail them here. By the time you are invited to become a committer you will have been guided through the use of our various tools as a user and then contributor.

Anyone can become a committer, there are no special requirements other than to have shown they are willing and able by participating as a contributor. Typically a committer will need to show they have an understanding for Project-X, 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 nominated there will be a vote by the Project Management Committee (see below). Committer voting is one of the few activities that happens on the private management list of Project-X. The reason it occurs in private is to allow Project Management Committee members to freely express their opinions about a nominee without having to do so in public where it may embarrass someone. Once the vote has been held the aggregated voting results are published on the public mailing list. The nominee is entitled to request an explanation for any "no" votes against them regardless of the outcome of the vote. This explanation will be provided by the Project Management Committee Chair (see below) and will be anonymous and constructive in nature.

Nominees may refuse their appointment as a committer. However, to do so is unusual as the project does not expect any specific time or resource commitment from its community members. The role of committer is intended to allow people to contribute to the project more easily, it is not intended to tie them into the project in any formal way.

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

Project Management Committee

The Project Management Committee (PMC) of Project-X consists of those individuals identified as "Project owners" on the development site. The PMC has additional responsibilities to ensure the smooth running of the project. PMC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.

Being a member of the Project Management Committee does not give significant authority over other members of the community, although it is the PMC who vote on new committers and make decisions when community consensus cannot be reached. The PMC also has access to the projects 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), but 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.

Project Management Committee 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.

THe PMC Chair has no additional authority over other members of the PMC. The role is one of coordinator and facilitator. The chair is expected to ensure all governance processes are adhered to.

The PMC Chair also has the casting vote in the event of an inability of the project to reach consensus or the required number of votes when a vote is called (see below).

Support

FIXME: Add this section

Decision making process

Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PMC member. All project management discussion takes place on the ProjectX-contributors mailing list (occasionally sensitive discussion occurs on a private list, but general project management discussion always occurs on the public lists).

Lazy Consensus

Decision making is usually a two step process. Occasionally a third step is required. These steps are:

Discussion -> Proposal -> [occassionally] vote -> Decision

Any community member can table an idea for consideration. In order to prompt a discussion about a new idea, send an email to the ProjectX-contributors. Once the idea has become more concrete and appears to have a significant level of support within the community it is time to make a proposal. To make a proposal sumarise the discussion in a new email with the tag "[Proposal]" at the start of the subject line.

Usually, gaining consensus within the community is easy since all community members have a common set of goals. By the time an idea reaches the proposal stage it is likely to have community support since it will already have been discussed publicly. However, full community consensus cannot be assumed at this stage, hence the need for a proposal stage.

In general, as long as nobody explicitly opposes a proposal then it is recognized as having the support of the community. This is called lazy consensus, that is, those who have not stated their opinion explicitly have implicitly agreed to the proposal being implemented. The "[Proposal]" subject tag is used to grab the attention of community members who may have been unable to participate in the discussion phase. It is an indicator that a project decision is about to be made. It is this that allows the community to assume that lazy consensus has been reached.

Lazy consensus is a very important concept within Project-X. It this process that allows a large group of people to efficiently reach consensus. This efficiency stems from the fact that someone with no objections to a proposal need not spend time stating their position, furthermore others need not spend time reading such mails.

For lazy consensus to be effective it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal email.

The time spent gaining the consensus of the community does not prevent work proceeding on the idea. People are free to work on the implementation of any idea or proposal whilst the community examine and discuss it. This process need only be followed for an action that will significantly affect the project. Smaller actions, such as the addition of an optional feature or the fixing of a reported bug need no discussion. Contributors are free to action these items. Since this process is only followed for major activities the time spent reaching consensus is usually considerably less than the time spent implementing the decision.

Voting

Not all decisions can be made using lazy consensus. Issues such as those that affect the strategic direction of the project must gain explicit approval in the form of a vote. See the next section for a discussion of when a vote is needed.

If a formal vote on a proposal is called (signaled simply by sending a email with "[Vote]" in the subject line) then the following procedure applies.

All participants on the ProjectX-contributors list may express an opinion and vote by sending an email in reply to the original "[VOTE]" email with the following vote and information:

To abstain from the vote then simply do not respond to the email.

Every member of the community, from an interested user, through to the most active developer has a vote. We encourage all members of the community to express their opinions in all discussion and all votes. However, only committers in the project (as defined above) have binding votes for the purposes of decision making. It is the responsibility of the committers to ensure all community members opinions are considered. Whilst only committers and PMC members have a binding vote, a -1 from a non-committer that presents a valid justification for the negative vote must be considered by the community, and if appropriate, must be supported by a binding '-1' from committers.

When a [Vote] receives a "-1" (or veto), it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the veto is either rescinded, overruled (in the case of a non-binding veto) or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether).

In the very rare circumstance that consensus cannot be achieved, the Project Management Committee will decide the forward course of action.

Types of Approval

Different actions require different types of approval. The table below summarises the types of approval available within the project. These range from a form of assumed consensus that allows work to progress unless it is challenged through to a majority decision of the project managment committee. The following section describes which type of approval should be used in common situations.

Type

Description

Duration

Lazy consensus

An action with lazy consensus is implicitly allowed unless a binding -1 vote is received, at which time, depending on the type of action, a vote will be called. Note that even though a binding -1 is required to prevent the action all community members are encouraged to cast a -1 vote with supporting argument. Committers are expected to evaluate the argument and, if necessary, support it with a binding -1.|

72 hours

Lazy majority

A lazy majority vote requires more binding +1 votes than binding -1 votes.

72 hours

Consensus approval

Consensus approval requires 3 binding +1 votes and no binding -1 votes.

72 hours

Unanimous consensus

All of the binding votes that are cast are to be +1 and there can be no binding vetoes (-1).

120 hours

2/3 majority

Some strategic actions require a 2/3 majority of PMC members, in addition, 2/3 of the binding votes cast must be +1. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product).

120 hours

When is a vote required?

Generally as many decisions as possible are made through lazy consensus. That is, simply stating ones intentions is assumed to be enough to proceed, unless an objection is raised. However, some activities require a more formal approval process in order to ensure a fully transparent decision making.

The table below describes some of the actions that will require a vote, it also identifies which type of vote should be called.

Action

Description

Approval Type

Release Plan

Defines the timetable and actions for a release. A release plan cannot be vetoed (hence lazy majority).

Lazy Majority

Product Release

When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. A release cannot be vetoed (hence lazy majority).

Lazy Majority

New Committer

A new committer has been proposed.

Consensus Approval

New PMC member

A new PMC member has been proposed.

Consensus Approval

Committer Removal

When removal of commit privileges is sought.

Unanimous consensus

PMC Member Removal

When removal of PMC membership is sought.

Unanimous consensus

Contribution processes

Anyone can contribute to Project X regardless of their skills.

There are many ways to contribute, this section describes some of the most common activities. You can contribute by being active on the project mailing lists and issue tracker or by supplying patches as described later in this section.

Of course, you can always ask on the developer mailing lists if you need any help making your first few contributions.

User Experience

We need to understand how our users are using Project X and how they would like it to behave. We welcome feedback about the project in the form of discussion on user mailing list and in the form of feature requests via the issue tracker.

We often find that people are cautious about making requests or providing constructive criticism for fear of seeming to be critical. However, we love it!

Without your input the project cannot become more usable and usability is what makes the project outputs useful. Please, send us your ideas and suggestions, we don't promise to implement every feature request or tweak every existing feature, but we do promise to consider each comment and provide feedback on how important it is to us.

Helping Users

A simple and low level way to help out is by answering user questions. In doing this you will also help developers since answering questions takes time, time that could be spent adding features and fixing bugs. Furthermore, helping other users is an excellent way to learn a lot about the project yourself.

Another nice side effect is that those who help others are more likely to receive help themselves. So when you hit a sticky issue other users and developers will be there to help you.

Finally, the archives you generate helping users form an important part of the documentation for the project.

In order to help users please join the [user mailing list].

Marketing

The lifeblood of any open source project is its users. More users means more opportunities for success. It is the users who tell us what they want and help ensure the product is of sufficient quality.

You can help us attract users by telling people about our project and encouraging them to try it out.

Design and Implementation

In a software development project programming is often thought of as the most important form of contribution. Whilst it is obviously critical, a good design and a useful feature set are also vital. All significant code contributions should be discussed on the developer mailing list before implementation. This allows us to ensure the design is appropriate and the user experience is not adversely affected.

Smaller contributions, such as bug fixes, can be provided as a patch on the issue tracker without discussion.

Quality Assurance

Quality Assurance (QA) is one of the most important elements of any project. It is also something most almost anyone can contribute to. Users can help by testing release candidates before they are formally released, programmers can help by fixing bugs identified in our issue tracker.

Another important element of quality assurance is keeping people informed of activity on issues in the issue tracker. For example, each new issue should be examined and commented on. Duplicates should be marked as such and workarounds should be highlighted.

Graphics and Art

Have any art skills? Then you can help us create icons, logos, banners, labels, and more! These will be seen every day and used throughout the project and its products.

We've found that programmers are generally rubbish at interface and web design. If you think you can improve on things please join our [developer mailing list] and make your proposal.

Writing

Documentation is critical to new users of a project. One of the best ways for you to contribute is to document your experiences. We can always use tutorials, guides, HOW TOs and FAQs. They don't have to be perfect, in fact, a skeleton document with bullet point instructions is better than nothing at all. Those who use your document will ask questions and, once they understand, will help pad out the details.

Below are some some ideas for contribution.

User FAQs

The User FAQs (Frequently Asked Questions) are an excellent place to start contributing to Project X. You can contribute by supplying patches as described below, or if you are not a technical person simply raise an issue in the issue tracker with your proposed FAQ entry.

HOW-TOs and Tutorials

These are short, self-contained documents, as such they are a great place to start both for users and contributors. If there is a particular feature you enjoy, then documenting it for others is a very welcome contribution.

User Guide

We are writing a comprehensive User Guide for Project X, and we need your help. However, documenting a fast moving project like this is a hard job. We welcome additions, clarifications and corrections to our documentation. You'll find lots of material in the archives of the userr mailing list, you'll also find the community is always willing to help documentation authors.

Developers Guide

To contribute to the developers guide you'll need some technical expertise. This is a great place to start if you are trying to understand how to develop with or for Project X. You can help improve existing docuemntation or wrtie new content. You'll find lots of material in the archives of the developer mailing list, you'll also find the developers are always willing to help documentation authors.

Language Communities

The first language of Project-X is UK English. However, this is not true of the rest of the world. Can you help with translating Project-X into another language? Join us on the developer mailing list to find out how.

Monetary Donations and Developer Support

For an open development project money is less important than active contribution. However, we recognize that some people/organisations are cash rich and time poor.

At present we do not have a mechanism for accepting cash donations to the project. However, if you find that a developer, or group of developers, has been especially helpful to you why not send them some kind of reward? A voucher for an online store usually goes down well and is easy to provide.

We ask that you do this privately rather than through the public lists.

If you should want to make a significant cash donation then we'd rather you sponsored a developer to implement some new feature or fix some bugs. If you don't know how to do this join us on the developer mailing list where we can point you towards an independent third party who will help find the developer and will handle all cash transactions for you.

OSSWatchWiki: MeritocraticGovernanceModel (last edited 2013-04-15 13:56:24 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.