Login | Register
My pages Projects Community openCollabNet

Axion: Project Guidelines

Axion Project Guidelines

This document defines the guidelines for the Axion Project. It includes definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to Axion.

This document is a draft. It has not been officially voted upon by the Axion development team, but represents an attempt to make official the conventions we've been following up to this point.

Acknowledgement: Much of the text and spirit here is derived from various documents and guidelines established by the Apache Software Foundation, notably those of the HTTPD, APR, and Jakarta projects.


The Axion project recognizes two roles for the sake of conflict resolution and decision making: Contributors and Committers.


Contributors are the group of volunteers contributing time, code, documentation, or resources to the Axion Project.

A Contributor that makes sustained, welcome contributions to the project, follows the general guidelines, and appears to "get the process", will usually be invited to become a Committer, although the exact timing of such invitations depends on many factors.


Committers are the group of volunteers that are responsible for managing the Axion Project. This includes deciding what is distributed as products of the Project, maintaining the Project's shared resources, nominating new Committers, and establishing these guidelines.

This group has write access to the appropriate source repositories and may cast binding votes.

Membership as a Committer is by invitation only and must be approved by consensus of the active Committers.

A Committer is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive Committer can become active again by reversing whatever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Committer status can be revoked by a unanimous vote of all active Committers (except the Committer in question).

Voting and Decision Making


Any Contributor may cast a vote on any issue. The only binding votes are those cast by active Committers.

The act of voting carries certain obligations. Voting members are not only stating their opinion, they are agreeing to help do the work in question. It is therefore unlikely that the entire group membership will vote on every issue. To account for this, all voting decisions are based on a minimum quorum.

Each vote can take on one of three values:


Yes, the proposed action should be performed and the person casting the vote volunteers to help with executing the action as needed.


An abstention.

Occasionally Committers may choose to an express a non-binding opinion by voting +0 or -0, often indicating "I agree, but can't help" or "I disagree, but won't stand in the way". These opinions are welcome, and these votes are still considered abstentions.


No, the proposed action should not be performed. On issues where consensus is required, this vote is considered a veto.

Committers are strongly encouraged to describe the nature of or reason for their opposition along with the vote.

Types of Approval

We identify three types of approval, determined by voting. The next section describes which actions require which kinds of approval.


A unanimous decision requires explicit approval (+1 votes) from all active Commmitters.


A consensus decision requires "lazy" approval from everyone, and "active" approval from at least three Committers. A consensus vote passes if and only if no binding -1 votes have been cast, and at least three binding +1 votes have been cast.

Lazy Consensus

A lazy consensus decision is considered to have passed until at least one binding -1 vote has been cast.


A majority decision is considered to have passed if and only if at least three binding +1 votes have been cast, and more binding +1 votes have been casts than binding -1 votes.

Types of Action

Accepting a new Committer

Accepting a new Committer requires consensus approval from the active Committers.

Revoking Committer Status

Committer status can be revoked by unanimous approval from the active Committers. The vote of the Committer in question is not binding in this circumstance.

Changes to these Guidelines

Changes to these guidelines require majority approval from the active Committers.

Approving a Release

Releasing a new Axion product or a new version of an Axion product requires majority approval from the active Committers.

All Other Decisions

All other decisions, including changes to the source, documentation, etc. of Axion, require lazy consensus approval from the active Committers.

The Mechanics of Voting

Any Committer can call for a vote by posting a ballot on dev@axion.tigris.org including "[VOTE]" as part of the subject line. Votes are cast by mailing to dev@axion.tigris.org as well, and should also include "[VOTE]" as part of the subject line. Votes called by non-Committers are not binding.

How to Propose a Change


For items requiring lazy consensus approval, Committers may follow a "commit-then-review" process, simply committing the changes into the relevant source repository.

For items that are difficult to undo, large scale, or reasonable expected to be contriversial, Commiters are strongly encouraged to discuss these with the community first.

For other items, Committers may call for a vote on dev@axion.tigris.org, as described above.


Contributors are strongly encouraged to raise any issues or proposals on the dev@axion.tigris.org list.

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.

Create the patch by using the diff -u command from the original software file(s) to the modified software file(s). For example:

diff -u Foo.java.orig Foo.java >> patchfile.txt


cvs diff -u Foo.java >> 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 completed patchfile should produce no errors or prompts when the command:

patch -s < patchfile

is executed.

Axion - Open Source Java Database Engine
$Id: guidelines.html,v 1.28 2007/11/15 15:09:27 rwald Exp $
Published 15 Nov 2007 at 3:07 PM GMT.