jwma Development - Guidelines
Main | Deployment | Configuration | Architecture | Development | Screenshots | SF Project Site
Index | Overview | Guidelines | Lists | Building | API Docs | Credits

• Roles and Responsibilities
  Defines the recognized roles in the project
  • Users
  • Developers
  • Committers
  • Release Manager
• Communication
  Defines how users and developers communicate.
  • Announcement Lists
  • User Lists
  • Developer Lists
  • Commit Lists
• Decision Making
  Defines how action items are proposed and voted on.
  • Action Item
    • Long Term Plans
    • Short Term Plans
    • Release Plan
    • Release Testing
    • Public Release
    • Showstoppers
    • Product Changes
  • Voting
    • Action Item Votes
    • Voting Caveats
    • Other Items
    • Voting on Other Matters
  • Branches
• Source Repositories
  Defines how the Project's source code is organized and developed.
  • License
  • Status Files
  • Branches
  • Changes
  • Patches

• Announcement Lists:
  Announcement lists are very low traffic designed to communicate important information, such as final releases of the project's code, to a wide audience.
• User Lists:
  User lists are for users of a product to converse about such things as configuration and operating of the products of the Project.
• Developer Lists:
  Developer lists are for the contributors to the project. On these lists suggestions and comments for code changes are discussed and action items are raised and voted on. For the developer community, these lists are the very center of the project where all the "action" is.
• Commit Lists:
  The commit lists are where all CVS code commit messages are sent. All committers are required to subscribe to this list so that they can stay aware of changes to the repository.

All Contributors are encouraged to participate in decisions, but the decision itself is made by those that have Committer status in the Project. In other words, the Project is a "Minimum Threshold Meritocracy".

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.

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.

Note: "Lazy" means the action item has immediate tactic approval, and it is not necessary to tally the vote until a -1 reply is posted. Once a -1 reply is posted, the vote must be tallied and reported before the action item is considered approved. All action-item votes are lazy except for a public release vote.

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.

Other Items
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

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 range 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.

© 2000-2003 The jakarta Project of the Apache Foundation.