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:

• Only one person at a time has the authority to commit a patch into the main branch of the revision control system.
• That authority is represented by a token we affectionately call the Jolly Roger or the Roger for short.
• The Roger rotates from one developer to the next based on a prioritized task list.
• Each task on the task list that is being worked on has a primary developer, known as the task's Point of Contact. The Point of Contact is the person that gets the Roger and checks in the changes.

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.

• A regular vote. This process is as follows.
  • A developer (other than the one that made the entry) attaches a comment to the entry 'seconding' the call for vote before the vote can proceed.
  • Next, an administrator posts on the Developers' Private Forum, a ballot.
  • All developers get one vote per feature (though, any developer can register an I-abstain-unless-I-explicitly-vote with the administrators).
  • A regular vote lasts for a minimum of 48 hours. After that period of time, the vote lasts for a week or until the majority of non-abstaining developers (that is, all of the I-want-to-vote-explicitly-in-every-vote developers plus anyone else who votes) agree (for or against the task), whichever is shorter.
  • If a majority of non-abstaining developers vote for the task and at least two votes are cast, the administrators will move the item to the task list. Otherwise, the status will be changed to 'closed' with a resoultion of 'rejected'.
• A 'Quickfix' vote. Administrators can call for a 24-hour approval process for certain "quickfixes" that are not expected to create conflicts with upcoming tasks. This process proceeds as follows.
  • An administrator posts on the Developers' Private Forum, a ballot stating 'QUICKFIX' in the title.
  • Each developer gets one vote per feature (rules for abstaining developers apply).
  • A quickfix vote lasts for 24 hours.
  • As long as there are not 2 dissenting votes within the 24 hours (and dissent could be either with the task as proposed or with classifying it as a quickfix) the task will be approved.
  • If the task is approved, administrators will move the item to the task list. Otherwise, the status will be changed to 'closed' with a resoultion of 'rejected'.
• Administrative action. An administrator can modify any item on any of the lists including moving or adding an item to the task list.

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:

• Update his local copy of the 'roger.txt' document from CVS. If the Roger he desires is not (available), he must wait until it is before he can get the Roger.
• If the Roger is (available), he should replace the string '(available)' in the 'roger.txt' document with his email address.
• Attempt to check the local copy of the 'roger.txt' document into CVS. If it checks-in, he has the Roger.
• If CVS complains that he doesn't have the latest version, then someone has checked in the document -- he should update his local copy of the 'roger.txt' document. If there are no conflicts, he can check-in the document to get the Roger. If there are conflicts, someone got the Roger just ahead of the developer.
  
  Do _not_ replace an existing email address with your own -- wait for your Roger to be (available).
• When a developer is done checking-in his code, he should replace his email address and check-in the 'roger.txt' document. The developer may have to update the document in case someone has modified a different Roger in the mean time.

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.

• to register with the Administrators one of the following:
  • I-abstain-unless-I-officially-vote, or
  • I-want-to-vote-explicitly-in-every-vote statement
• not to spam
• not to post flame bait
• not to be mean to others on the list
• not to vote more than once in a vote
• not to commit to the trunk of the CVS tree without having the Jolly Roger (a token used to indicate which developer has the task that is at the top of the task list).

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:

• announcing a vote (after there has been discussion, a call for a vote by a developer, and a second),
• maintaining the site documents including the list of approved tasks and this charter,
• acknowledging when a task has been assigned to a developer (on a first-requested basis) and updating the task list accordingly, and
• moderating discussions and occasionally making an executive decision.

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.