Users

Users are the people who use the products of this project. People in this role aren't contributing code, but they are using the products, reporting bugs, making feature requests, helping other users, extending an online FAQ and such. This is by far the most important category of people as, without users, there is no reason for the project.
When users start to contribute code or documentation patches, they become contributors.

Contributors

Contributors are the people who write code or documentation patches or contribute positively to the project in other ways. A volunteer's contribution is always recognized. In source code, all volunteers who contribute to a source file may add their name to the list of authors for that file.

Committers

Contributors who give frequent and valuable contributions to the project can have their status promoted to that of a "Committer". A committer has write access to the source code repository and gains voting rights allowing them to affect the future of the project.
In order for a Contributor to become a Committer, another Committer can nominate that Contributor or the Contributor can ask for it. Once a Contributor is nominated, all of the Committers of this project will vote. If there are at least 3 positive votes and no negative votes, the Contributor is converted into a Committer and given write access to the source code repository for the project.
Before receiving write access, a Committer must also affirm that they have read and understood these guidelines, and agree to abide by their terms, as they may be revised from time to time.

At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose his or her status as a Committer.

A list of some of our current Committers can be found in our project credits.

Release Manager

Product releases will be managed by a selected committer. A release manager should actively manage the release process, watch the deadlines, release and make announcements.

Action Items

All decisions revolve around "action items". Most action items require a vote to be approved. Votes can either be by majority or by consensus.

Action items include the following:

• Long Term Plans: No vote required.
• Short Term Plans: No vote required.
• Release Plan: Lazy majority vote on each issue, or lazy consensus if issue involves a product change.
• Release Testing: No vote required, once Release Plan is approved.
• Public Release: Majority vote, if no showstoppers are listed in the status file.
• Showstoppers: Lazy consensus until resolved and removed from status file.
• Product Changes: Lazy consensus.

Voting

Action Item Votes

The act of voting on an action item carries certain obligations. Voting members are not only stating their opinion, they are also agreeing to help do the work.
Any Contributor or Committer ("member") may call for an action-item vote on the Developer mailing list. It is preferred that a vote be preceded by a formal proposal offered for discussion purposes. The message announcing a vote should contain a Subject beginning with "[VOTE]", and a distinctive one-line summary corresponding to the action item for the vote.

Each vote on an action item can be made in one of four flavors:

Votes cast by the project's committers are considered "binding". When needed, at least 3 binding +1 votes are required for approval of an action item.

An action item may need one of two types of approval:

1. Consensus approval:
   An action requiring consensus approval must receive at least 3 binding +1 votes and no binding vetos.
2. Majority approval:
   An action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes.

Except for a public release, all action items are considered to have lazy approval until somebody votes -1, at which point the action item is converted to a formal consensus or majority vote, depending on the type of action item .

Any member may vote on any action item or related issue. When voting on an action item, the project's committers may also include the word "binding" next to their vote, to simplify a tally if it is needed. All binding vetos must also contain an explanation of why the veto is appropriate.

Voting Caveats

• A +1 vote regarding product code can only be made binding if the voter has tested the action on their own equipment.
• A binding +1 vote on a public release means the project's committer agrees to provide ongoing support for that release while it is current.
• An abstention may have detrimental effects if too many people abstain.
• Vetos with no explanation are void. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately so that the problem can be remedied as early as possible.
• If a committer believes the explanation for a veto is invalid, an affirmation of the veto can be requested. If some other committer does not affirm that the explanation for the veto is valid, the veto shall be void.
• Members who wish to discuss a vote before replying, may open another thread to help avoid premature vetos. Any +/-1's or +/-0's posted to an alternate thread, or any other thread not labeled "[VOTE]", are considered conversational, and do not qualify as an valid action-item vote. A "lazy item" remains subject to lazy approval until a valid -1 reply is posted to the "[VOTE]" thread.

Vote Results

Most action items are subject to lazy approval, and do not require the posting of a formal result. However, any other majority item that receives any -1 reply (later rescinded or not) must be followed by a "[VOTE-RESULT]" message before the action item is considered approved.

Likewise, any consensus item that receives any binding veto must post a "[VOTE-RESULT]" message summarizing the result, and show that each veto was rescinded, before it is considered approved. In either case, the member who requested the vote should also post the result within 120 hours (5 days).

A Public Release is not considered approved until the Release Manager posts a followup message with the legend "[VOTE-RESULT]" summarizing the replies.

Proposals (and plans)

Proposals are not a formal action item; however, the message offering a proposal should contain a Subject beginning with "[PROPOSAL]".
It is strongly recommended that a proposal be circulated before calling for a formal vote. Often, once members have had the chance to critique a proposal, an updated copy of a proposal can be reposted as the vote document.

Most other messages posted to the Developer's List usually involve either short-term or long-term plans. Often, a long-term plan will be made in the form of a "[PROPOSAL]". If appropriate, the proposed change or feature may then be entered to the project's STATUS file or TODO list.

Voting on other matters

There are other matters upon which members will vote that do not involve action items. The same general voting structure is used in these cases, except that the "flavors" are taken to mean:

Branches

In any software development project there is a natural tension between revolution and evolution. Many software development teams, open or closed, have a team leader who can declare whether the code base is in evolutionary or revolutionary mode. In a volunteer meritocracy, this type of decision is difficult to make and impossible to enforce. Our meritocracy is fueled by voluntary contributions, and so we must allow everyone to contribute and then base our final product decisions on the contributions we actually receive.

Accordingly, as a matter of project policy, these principles are adopted:

1. Every committer has the right to revolution. Anyone can establish a branch or seperate whiteboard directory in which to experiment with new code seperate from the main trunk. The only responsibility a committer has when they do this is to announce their short and long term plans and allow others who want to help to do so. Committers working on a revolutionary branch have the right to develop their approach free of interference.
2. When a revolution is considered ready for prime time, the committer(s) shall propose a merge to the developers list. At that time, the overall community evaluates whether or not the code is ready to become part of, or to potentially replace, the trunk. Suggestions may be made, changes may be required. Once all issues have been taken care of and the merge is approved, the new code may become the trunk.
3. All development branches should be unversioned. No branch, evolutionary or revolutionary, should have any official version standing. This allows several parallel tracks of development to occur with the final authority of what eventually becomes the trunk resting with the entire community of committers.
4. The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted.

License

All source code committed to the Project's repositories must be covered by the project license or contain a copyright and license that allows redistribution under the same conditions as the project license.

Status

The project's active source code repository contains a file named STATUS.xml which is used to keep track of the agenda and plans for work within the 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 volunteers are working on or want discussion about, and anything else that may be useful to help the group track progress.

Branches

It is allowed to create a branch for each release cycle, etc. They are expected to merge completely back with the main branch as soon as their release cycle is complete.

A branch is considered "evolutionary" by lazy consensus. Upon any dispute (binding veto), a branch must be converted to "revolutionary" status, and must be assigned a working name that does not imply it will be the next version of the product. Once a release plan for the branch has been approved, and the proposed release is ready for testing, it may be assigned a version name reflecting it is a product release candidate, and merged back with the main branch, as appropriate to the circumstances. Any branch, "evolutionary" or "revolutionary", shall meet the same standard for release approval.

Changes

Simple patches to fix bugs can be committed then reviewed. With a commit-then-review process, the committer is trusted to have a high degree of confidence in the change. Doubtful changes, new features, and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, the size of the program, configuration data formats, or other major areas must receive consensus approval before being committed.

Related changes should be committed as a group, or very closely together. Half complete changes should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the contributor's platform before being committed. The current source code tree for the project should be capable of complete compilation at all times. However, it is sometimes impossible for a contributor on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message.

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.

Patches

When a specific change to a product is proposed for discussion or voting on the appropriate development 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.

Related changes should be committed as a group, or very closely together. Half complete changes should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the contributor's platform before being committed. The current source code tree for the project should be capable of complete compilation at all times. However, it is sometimes impossible for a contributor on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message.

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

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

or

cvs diff -u Main.java >> patchfile.txt

On Win32 you can use WinCVS for a nice GUI or you can install Cygwin which will enable you to use the bash shell and also installs a lot of other utilities (such as diff and patch) that will turn your PC into a virtual Unix machine.

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