ColdX Project Charter
---------------------

The ColdX Project is a conglomeration of programmers dedicated to
advancing the ColdX driver and any relative databases associated with
this driver.  The ColdX Project directly manages the development of the
driver.  Development of various databases are of interest and related to
the ColdX Project, but the ColdX Project does not assume any
responsibility over them.

Membership of the ColdX Project is not a tangeable item.  Anybody may
partake in the ColdX discussions.  Anybody may submit source code for
the driver, following the ColdX Submission Guidelines.

Submission Guidelines
---------------------

Anybody may submit changes to the driver, assuming they are appropriate
and comply with the following guidelines.

1)  Source Code Changes:

    Source Code Changes are seperated into two categories:

    a) Non-Impacting Changes: These include simple bug fixes (either
       reported or not, although it is usually best to report a possible
       bug, as it may be a known feature) and code optimization.
    b) Impacting Changes: This category encompases all changes not
       covered by the first category.  Changes which impact the
       functionality or interface of the driver as well as those which
       effect the database or database language (ColdC) must first be
       considered by the ColdX Project team and pass through the
       development list.

2) Development List:

    The Development List contains all impacting changes which are
    currently under scrutiny of the ColdX Project.  Changes are
    defined by a unique name, a quick explanation, and a URL
    pointing to the file which completely outlines the change (including
    pros and cons as well as driver and database impacts, if applicable).
    The URL is only specified if the change is of the calliber to
    require an indepth explanation (most are).  The Development
    List is divided into five sub categories:

    a) Suggested Changes

        This list contains all suggested changes which have not
        yet been discussed, considered and/or accepted.

    b) Considered Changes

        This list contains changes which are currently under scrutiny
        of the ColdX Project.  This is the discussion list for changes
        to be Accepted.

    c) Accepted Changes

        This list contains all changes which have been accepted by
        the ColdX project.  It also contains a reference for who
        is currently working on the change (if anybody), and when
        they started.  Anybody can claim unclaimed Changes on
        this list.  To do so simply email the ColdX Project manager
        with your intentions and a brief outline of your
        implementation ideas (if applicable).  The manager will
        update the list and announce the change in the appropriate
        medium.

    d) Suggested and Completed Changes

        Once an Accepted change has been completed, it is moved to
        this archive list.

    e) Suggested but not Accepted Changes

        This list contains all changes which have been discussed
        and rejected by the ColdX Project.  It also includes what
        the reasons were for dismissing it, as well as it's
        possible impacts.

3) Submitting Changes

    Submitted Changes which do not comply with the following guidelines
    will not be integrated into the distribution. 

    a) Submit the change to the manager in the form of a patch (unless
       a previous arrangement has been made with the manager), using
       the application "diff" with the flags "-rc".  The diff
       must have been executed from the base ColdX tree.  This will
       require a few seperate executions (to include each applicable
       directory).  For instance, patch creation may involve:

        prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/src src > patch
        prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/doc doc >> patch
        prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/bin bin >> patch
        prompt:/path/ColdX-Version> diff -rc ../ColdX-Old/test test >> patch

    b) Changes must be clean and commented.  This includes no debug
       functions or lines (including those commented out), and
       gratuitous or local changes.  Comments need not be extensive,
       although it is best to explain what new functions do--if
       applicable--at the top of the function definition.

    c) Every patch must update doc/CHANGES, where the first line of
       the change specification (index) includes the version, date
       of release (in brackets, and using the syntax 
       "day(integer)-month(3 characters)-year(integer)", such as
       [02-Jan-95]), a colon, and a list of contributors to the
       patch.  The body of the change description must be indented
       at least six spaces, and it is common practice to identify
       each seperate change with the relative contributor (in the
       case of multiple contributors).