OMC-governance

How the OMC Project Works

Introduction

This page will give you everything you always wanted to know about how the OMC project works, but were afraid to ask. It covers topics such as the difference between a contributor and a committer, how conflict resolution is done, the voting policy, how the infrastructure is setup, and what PMC is.

Related Pages

For information on what the OMC project is, see the OMC Charter page.

For information about how to actively participate, see Voting and Participation pages.

Meritocracy

Meritocracy: "Govern of Merit".
The basic concept behind a Meritocracy is that the more you participate, the more responsibility you merit. In the OMC project, there are several levels of responsibility ranging from a simple user or contributor to being a member of the OMC Project Management Committee (PMC). All users or interested parties in the OMC project are classified as contributors. The simple definition of a contributor is a person who has an interest in the project and starts to contribute to it (such as posting code or documentation patches, contributing ideas to or replying to email on the mailing list). As their participation or contributions to the project expand and the PMC recognizes this fact, the PMC may determine that the person has "merited" the right to become a project committer. Amoung other responsibilities, being a project committer gives the person commit rights to the project's source code repository. The person's role or responsibilities may continue to increase as merited by their actions and participation in the project. The benefit that this has on the project itself is to make sure that those that govern the project are those that maintain a vested and sustained interest in the project, therefore ensuring that the project is always moving forward in the direction that benefits both the project and the community.

For more information on the principle of Meritocracy, visit The Apache Foundation.

Project Management Committee (PMC)

The Project Management Committee is responsible for actively managing the OMC community and project itself.

The PMC chair is elected by the members of the PMC. The PMC chair, with the consent of the PMC as a whole, has the power to establish rules and procedures for the day to day management of the communities for which the PMC is responsible, including the composition of the PMC itself.

The primary role of the PMC is project oversight. The PMC itself is not necessarily concerned with source code or technical issues but exists to ensure that all legal issues are addressed, that procedure is followed, and that each and every release is the product of the community as a whole.

Secondly, the role of the PMC is to further the long term development and health of the community as a whole and to ensure that balanced and wide scale peer review and collaboration happens. The intent of the OMC project is not a community that centers around a few individuals who are working virtually uncontested but rather a true community-developed project.

Membership on the PMC and the role as chair of the PMC is merited through sustained participation in the project as well as demonstrating an interest in the day to day administration of the project as recognized by your peers. It is not tied to your job, current employer, or corporate status.

Roles

A meritocracy enables various roles:

• User/Contributor
• Committer
• PMC member

User/Contributor

A user is someone that uses our software. A user may also be a contributor by providing the OMC projects with feedback in the form of bug reports and feature suggestions. Contributors may participate in the OMC community by helping other users on the mailing lists and user support forums. A contributor may also contribute code or documentation to the project in the form of a patch. They usually take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions, and criticism. However, users or contributors do not have rights to commit patches directly into the source code repository nor do they hold a binding vote within the project.

Committer

A committer is a contributor who has demonstrated a sustained interest in the OMC project. As such, they have been invited by the OMC PMC to become a committer on the project. By accepting the invitation, they are asked to sign a Contributor License Agreement (CLA) and be given Write access to the code repository. With Commit rights to the repository, a committer no longer needs to depend on other committers in order to commit patches to the source code repository. They are also allowed to vote on issues that involve the technical direction or design of the source code itself. However, a committer does not carry a binding vote on issues that concern the project as a whole, although their feedback and opinions are always welcome.

PMC Member

A PMC member is a committer who has demonstrated a sustained interest in not only the technical aspects of the OMC project, but the administrative aspects and direction of the project as well. Those who merit this level of responsibility are invited by the existing PMC to become a PMC member. They have Write access to the code repository, the right to vote on community-related issues, and the right to propose an active user for committership as well as an active committer to become a member of the PMC. The PMC as a whole is the entity that defines and determines the direction of the OMC project.

Project Management and Collaboration

Communication

Communication is done via mailing lists. Mailing lists can be thought of as "virtual meeting rooms" where conversations happen asynchronously. The asynchronicity of mailing lists allow for a geographically distributed community that covers many different time zones, to communicate in an efficient and effective manner. They also provide a public forum where in all voices can be heard and considered.

If the need arises, the PMC may additionally allow the use of more synchronous messaging, such as IRC. This may be used for support questions or for synchronous discussions of predetermined topics. If there are decisions made in these discussions, they should be posted to the mailing list, either summarized or the entire IRC chat log.

In general, asynchronous communication is much more important because it allows archives to be created and it's more tolerant on the volunteer nature of the various communities.

Documentation

Each sub-project is responsible for its own page on the omc-project website.

Decision Making

The OMC project is auto governing and driven by the people who volunteer for the job. This is sometimes referred to as "do-ocracy" -- the power of those who do. This functions well for most cases.

When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going.

Voting is done with numbers:

• +1 -- a positive vote
• 0 -- abstain, have no opinion
• -1 -- a negative vote

The rules require that a negative vote includes an alternative proposal or a detailed explanation of the reasons for the negative vote.

The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed.

This process is called "consensus gathering" and we consider it a very important indication of a healthy community.

See more about this on the Voting page

Philosophy

While there is not an official list, these principles have been cited as the core beliefs or philosophy behind the OMC project:

• collaborative software development
• use of standard open source licensing
• consistently high quality software
• respectful, honest, technical-based interaction
• faithful implementation of standards
• security as a mandatory feature

Operation

All projects are composed of volunteers and nobody (not even members or officers) are paid directly by the OMC Project for their efforts. There are many examples of committers that are paid to work on parts of the OMC subprojects by companies or institutions that use the software and want to enhance it or maintain it, but they never get paid by the OMC project.

Individuals Compose the OMC Community

While many participants of the OMC Project participate as part of their assignments by their employer, all participants of the OMC Project are participating as individuals.

Unless they specifically state otherwise, whatever they post on any mailing list is done as themselves. Their posts are the individual's point-of-view, wearing their personal hat and not as a mouthpiece for whatever company happens to be signing their paychecks right now.

The Chair of the PMC implicitly has multiple hats (responsibilities), and sometimes needs to talk about a matter of policy. To avoid appearing to be expressing a personal opinion, the chair will state that he/she is talking in his/her special capacity. However, most of the time this is not necessary; personal opinions work well.

Balancing Confidentiality and Public Discussion

We endeavour to conduct as much discussion in public as possible. This encourages openness, provides a public record, and stimulates the broader community.

However sometimes internal private mail lists are necessary. You must never divulge such information in public without the express permission of the PMC. Also never copy an email between private and public lists (no Cc). Such an event would go beyond the normal need for email ettiquette and be a serious breach of confidence. It could have serious ramifications, causing unneccessary confusion and ill-informed discussion.

How to Commit Code

STATUS file

Each subproject repository contains a file called "STATUS" which is used to keep track of the agenda and plans for work within that repository. The STATUS file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual developers are working on or want discussion about, and anything else that might be useful to help the group track progress.

Many issues will be encountered by the project, each resulting in zero or more proposed action items. Issues should be raised on the mailing list as soon as they are identified. Action items must be raised on the mailing list and added to the relevant STATUS file. All action items may be voted on, but not all of them will require a formal vote

CHANGES file

Each subproject repository contains a file called "CHANGES" which is used to keep track of the code changes within that repository. Not every code change need be entered in CHANGES. Use discretion. If it is a significant change, if it affects the interfaces, or if it affects the end user, post it in CHANGES. If the fix is a 'tweak this bit' or 'removed an erroneous semi-colon' don't bother, unless it caused a significant bug. Bug fix entries should include the bugzilla bug number.

When to Commit a Change

Ideas must be submitted as review-then-commit (RTC); patches can be submitted as commit-then-review (CTR). With a CTR process, we trust that the developer doing the commit has a high degree of confidence in the change. Doubtful changes, new features, and large-scale overhauls need to be discussed before being committed to a repository. Any change that affects the semantics of arguments to configurable directives, significantly adds to the runtime size of the program, or changes the semantics of an existing API function must receive consensus approval on the mailing list before being committed.

Each developer is responsible for notifying the mailing list and posting an entry to the STATUS file when they have an idea for a new feature or major change to propose for the product. The distributed nature of the OMC project requires an advance notice of 48 hours in order to properly review a major change. Consensus approval of either the concept or a specific patch is required before the change can be committed. Note that a member might veto the concept (with an adequate explanation), but later rescind that veto if a specific patch satisfies their objections. No advance notice is required to commit singular bug fixes.

Ideas for new subprojects should be proposed to the mailing list as an RTC proposal. If the project fits within the charter of OMC, it will likely be accepted by the PMC at which point the repository will be created. If the idea is proposed by a member without commit rights, that person must still gain commit rights on merit, according to the procedures outlined.

Related changes should be committed as a group or very closely together. Half-completed projects should not be committed unless doing so is necessary to pass the baton to another developer who has agreed to complete the project in short order. All code changes must be successfully compiled on the developer's platform before being committed.

The current source code tree should be capable of complete compilation at all times. However, it is sometimes impossible for a developer on one platform to avoid breaking some other platform when a change is committed, particularly when completing the change requires access to a special development tool on that other platform. If it is anticipated that a given change will break some other platform, the committer must indicate that in the commit log.

The committer is responsible for the quality of any third-party code or documentation they commit to the repository. All software committed to the repository must contain a copyright and license that allows redistribution under a standard open-source license.

A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release.

Patch Format

When a specific change to the software is proposed for discussion or voting on the mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary corresponding to the action item for that patch. Afterwords, the patch summary in the STATUS file should be updated to point to the Message-ID of that message.

The patch should be created by using the diff -u command from the original software files to the modified software files. For example:

   diff -u http_main.c.orig http_main.c >> patchfile.txt

or

   cvs diff -u http_main.c >> patchfile.txt

All patches necessary to address an action item should be concatenated within a single patch message. If later modification of the patch proves necessary, the entire new patch should be posted and not just the difference between two patches. The STATUS file entry should then be updated to point to the new patch message.

The completed patchfile should produce no errors or prompts when the following command is issued in the target repository:

   patch -s < patchfile

The OMC Project Infrastructure

The OMC Project does not have offices or buildings, it's a virtual entity that exists only on the Internet. It's only physical existence is the technical infrastructure that enables it to operate. This infrastructure is donated by a participating company (currently Novell).

The OMC Infrastructure is mostly composed of the following services:

• the web serving environment (Web sites and wikis)
• the code repositories
• the mail management environment
• the issue/ bug tracking
• the distribution mirroring system