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.

Roles

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

Contributors

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

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

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

Committers

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

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

or

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.