OnBoard Suite Development Charter, v1.3

The admins of the OnBoard C SourceForge project thought some ground rules might help reduce some of the chaos of open source development. This document describes those rules. We're all learning, here, so the admins reserve the right to tweak, modify, add to, revoke, or simply frobnicate these rules. We may do so on a temporary or permanent basis. If we do, though, we'll let everyone know and we'll react appropriately to user input.

1. Introduction

Summary Of The Process. We're developing the OnBoard Suite using a system similar to the patch pumpkin system used for Perl. The system hopefully decreases the chances of two developers committing mutually incompatible patches to the source through a few simple rules:

2. Development

Revision Control. We're using SourceForge for OnBoard Suite development, so we're using CVS for revision control.

Task Lists. With the exception of bug fixes (described later), only stuff on the OnBoard Suite task list is supposed to be implemented and checked-in. Each task on the list is numbered -- all references to a task should include the task's number.

Getting Tasks On The Task List. Anything that changes in the OnBoard Suite must go through the OnBoard Suite's task list. That path is described here.

When someone wishes for one or more of the programs or documentation entries in the OnBoard Suite to be changed, they add an entry to the OnBoard Suite's bug list or feature list. The item can be moved to the task list (the "Data Type" of the item is changed to 'Tasks') in one of the following ways.

Point Of Contact. Each task needs needs a Point of Contact (PoC) before work can start on it. A task's PoC is the lead developer working on the task and he is responsible for committing the task's source code changes into CVS when he gets the Roger. Anyone who wants to work on a task must either work with the task's PoC or, if one doesn't yet exist, become the task's PoC. Note that a task's PoC has the right to work alone or with others on his task.

If you want to be Point of Contact for a task, ask by emailing an administrator with a subject-line that includes "PoC-REQUEST" and task's the number (found in a task list or a task's vote in the developers' forum). The developer who initially requests a feature or bugfix gets the first opportunity to become the task's PoC but, after that, it's usually first come, first served.

Development Work. A task's PoC can choose to begin work on a task before he has the Roger (see below). If he wishes to check-in intermediate results, he agrees to do this only by making a branch from the main trunk of the CVS repository and checking-in those changes to the branch. When the task is complete and the PoC gets the Roger he can merge the branch back into the repository.

If developers see a bug in the code while working on their task, they may fix the bug without having a task added to the tasklist. Before addressing the bug, however, someone on the team must email the OnBC Project email list with a subject line including "BUGFIX" and a body describing the bug being fixed. This way, multiple teams aren't attacking the same bug.

If a developer doesn't have time to (or, for some reason, doesn't want to) fix a bug, he should submit that bug to the bug tracker.

Checking Stuff Into CVS and the Roger. A developer must have the Roger to legally check something into the main branch of the CVS source tree. The 'roger.txt' file in CVS indicates who, if anyone, has the Roger. When you check things in, PLEASE include the task number from the task list in your CVS log message.

To get the Roger, the developer must be the PoC for the task and he needs to do the following:

There is no set maximum time a task's PoC can keep the Roger but developers are urged to be both considerate and patient: considerate in giving-up the Roger if others are waiting; patient in waiting for other developers to work out the bugs in their patches.

3. Developers

Anyone who wants to be a developer can join the group by asking an administrator to add them -- this is pretty-much automatic as long as the prospective developer agrees to the following.

Once added to the group, the developer can vote on tasks and task priorities, or offer help on tasks that have been called for.

4. Administrivia

The Administrators are the men behind the curtain. The developer community guides the development of OnBoard C democratically, but the Administrators are the ones charged with keeping the wheels of this democracy turning. The responsibilities of an Administrator include:

The bad stuff. A developer who breaks one of the developers rules may, at the administrators' discretion, lose voting privileges for a time or, in extreme cases, be removed from the list of developers.