| JOpenZip Project Bylaws |
The bylaws under which the JOpenZip Project will operate are defined here. Essentially the bylaws define roles and responsibilities within the project and how voting works.
|
| Roles and Responsibilities |
A set of roles with associated responsiblities is defined in the project. These roles determine the actions and individual may perform within the project. There are four major roles defined:
- Users
- Developers
- Commiters
- Administrators
|
| Users |
The people who use the software are fundamentally the most important participants in the project. Most developers will start out as users and become developers as they begin to understand how the software works. Users also contribute by providing valuable feedback in the form of bug reports and suggestions.
|
| Developers |
Any participant that contributes any resource, be it time, code or documentation is considered a developer. Developers that make regular and welcome contributions may be promoted to commiters.
|
| Commiters |
Any participant who has write access to the project's CVS source repository is regarded as a commiter. Admninistrators automatically fall into this category. Commiters may cast binding votes on all technical aspects related to the project. A participant will become a commiter only through invitation by an administrator, and then through lazy consensus of all the administrators.
A Commiter may be relinquished from their duties by their own declaration or through non participation within the project for a perdiod of at least three months. An emiritus commiter may apply for reinstatement, however each case will be considered individually and reinstatement will only be granted on the merit of the applicant through lazy consensus of all the administrators.
Write access to the CVS repository may be revoked through unanimous vote of the administrators.
A Commiter who makes regular welcome contributions of any kind, not necessarily contributions of code, may be invited to become an administrator. Administrators are selected through invitation and unanimous vote of the administrators.
|
| Administrators |
Administrators are responsible for the management of the project. Duties include:
- Deciding what products are released as part of the project.
- Maintaining the projects resources: source repsoitories, mailing lists and web sites.
- Nominating new commiters and administrators.
- Maintaining these bylaws and project guidelines.
A participant can only become and administrator through invitation and unanimous vote of the all the active administrators. An administrator is considered emeritus by their own declaration or by not contributing in any form to the project for a period of no less than six months. An emeritus member may request reinstatement. Such reinstatement is subject to unanimous vote of the active administrators. Membership can be revoked by an unanimous vote of all the active administrators other than the member in question.
|
| Decision Making |
Many actions within the project require certain approval. This section deals with how voting works in terms of the types of approval and which type of decisions requires which type of approval.
|
| Voting |
Voting typically takes place on the project's development mailing list. Votes are clearly indicated by subject line starting with [VOTE]. Votes may not contain separate items. Each item requiring vote should use a separate post. Voting is carried out by replying to the vote mail. The three approval types are:
- +1 - An agreement or approval with the action. This indicates a willingness on the voter's behalf to "make it happen".
- 0 - Neutral or Veto. The voter does not agree with the action but does not mind if it goes ahead.
- -1 - A disagreement or disapproval of the action being taken.
All participants of the project are encouraged to vote. In respect of technical decisions, only commiter's votes are binding. Non binding votes are still usefull in determining the general consensus. Project management voting will typically take place on a private mailing list, and only administrato'rs votes are binding.
|
| Approvals |
These are the types of approvals that can be sought. Different actions require different types of approvals .
| Consensus |
All voters with binding votes must vote and there should be no vetoes. |
| Lazy Consensus |
Requires at least 3 binding votes and no vetoes. |
| Lazy Majority |
Requires at least 3 binding votes with the additional requirement that there are more +1 votes than vetoes (0). |
| Lazy Approval |
An action with lazy approval is implicitly allowed unless a -1 vote is recieved in which case a Lazy Majority should be obtained. |
| 2/3 Majority |
Requires at least two thirds majority binding vote to pass. This high threshold is required to ensure that the action is strongly supported. |
Where an action requires an approval with no vetoes and a veto is recieved, a valid reason must be given for the veto. In such a case, the veto may be challenged. If the veto is withdrawn, the action may occur. If not, the action may not occur or must be reversed in a timely manner.
|
| Actions |
The following is a list of actions that may be taken within the project and the required approval.
| Action |
Description |
Approval |
Binding Votes |
| 1. Code Change |
A change made to a codebase of the project and committed by a committer. This includes source code and documentation. |
Lazy approval and then lazy consensus |
Active committers |
| 2. Release Plan |
Defines the timetable and actions for a release. |
Lazy majority |
Active committers |
| 3. Product Release |
When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. |
Lazy Majority |
Active Administrators |
| 4. New Commiter |
When a new committer is proposed for the project. |
Lazy consensus |
Active Administrators |
| 5. New Administrator |
When a committer is proposed as an Administrator. |
Consensus |
Active Administrators |
| 6. Commiter Removal |
When removal of commit privileges is sought. |
Consensus |
Active Administrators |
| 7. Administrator Removal |
When removal of administrative privileges is sought. |
Consensus |
Active Administrators (excluding the member in question) |
|
| Voting Timeframe |
Votes remain open for a period of 1 week only.
|
