The admins of the OnBoard C SourceForge project thought some ground
rules might help reduce some of the chaos of open source development.
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
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
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
If you want to be Point of Contact for a task, ask by emailing an
administrator with a subject-line that includes
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.
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
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
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
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
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
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.
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
(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.
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
- 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
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.