- While we strive for consensus decision making, the Project Admin reserves the right to mediate conflicts of opinion on project direction and proposed features.
- Ease of use and ease of installation must not suffer for the sake of added functionality. You may have the latest and greatest feature but nobody will use it if the install is complex or if the interface is not user friendly.
- We want to support the widest possible library user base. Therefore OpenBiblio is committed to supporting both Windows and Unix-like operating systems.
- Contributions should follow the agreed upon programming, documentation, and look-and-feel standards. That is, they should follow these guidelines and mesh with the rest of OpenBiblio as seamlessly as possible.
- All code or documentation contributions not from project members should be submitted to the patch tracker.
- Unless explicitly stated otherwise, contributions submitted to the patch tracker are assumed to be licensed under the same terms as OpenBiblio itself. For more information about those terms, see the file COPYRIGHT.html at the top of a recent distribution (basically, it's the GPL with one minor exception).
- New members should meet the following qualifications:
- They must be supporting a real library with vested interest.
- If joining as a code contributor, they must have submitted code that shows they understand our direction and can code in a clean, well-structured way that fits the overall design.
- If joining as a non-code contributor, they must have submitted work that we find useful, appropriate to the work they will be doing.
- We intend to keep the core development team relatively small, so a person who meets the above requirements will not be made a member unless they fill a percieved need of the team and are approved by all active team members.
- Project members may remove themselves from the project by request. The Project Admin may remove inactive members from time to time.
- All project members should subscribe to the obiblio-members mailing list for project member communication. This mailing list is private. All subscription requests must be approved by the Project Admin.
- Write access to the CVS repository will be granted by the Project Admin to project members as he sees fit.
- Trivial bugfixes to any part of the project may be committed by anyone with CVS access.
- Check with Micah before you do anything major.
- Pure bugfixes should be applied both to the HEAD and to the current release branch.
- No new features should be committed on a release branch.
- Release branches are named RB_x_y where x and y are the numbers of the release series, e.g. RB_0_6 for the 0.6.x series.
- Individual releases are tagged RELEASE_x_y_z where x, y, and z are the components of the release version number, e.g. RELEASE_0_6_0 for 0.6.0.
- If a commit fixes a bug or incorporates a patch from the tracker, please include the bug/patch number in the log message.
- When a project member finds a bug and submits it to the tracker, he should assign it to himself if he intends to fix it soon. Otherwise, he should leave it unassigned so other developers know that they can fix it for him.
- All changes made to CVS should be in the unix line separator format ('\n' only)
- Commits should include a log message, but it should be kept short.