This is a project log file that records action items to be completed as well as
the actions taken to complete the items.  Each entry in the log file is defined
with the following five information fields:

    DATE	Date the log entry is made.  The date format is

		    ddmmmyy

		where dd is a one- or two-digit date, mmm is a three-character
		month name, yy is a two-digit year.  E.g., 15apr97

    AUTHOR	Two- or three-character uppercase initials of person making the
		entry, e.g., GLF.  Non-unique initials are suffixed with a
		disambiguating digit as the third or fourth character.  E.g.,
		JJS1, JJS2.

    STATUS	Entry status information, defined further below.

    FILE(S)	File(s) affected by the log entry.

    DESCRIPTION	Prose description of the entry.

The entries are ordered by DATE field, from most recent to most distant date.

Log entry status values are the following:

    BUG         Something that needs to be fixed ASAP.

    TODO        An small enhancement that needs to be made, where the
		enhancement is considered sufficiently minor not to be entered
		into the project schedule.

    FIX		A response to a BUG item that fixes the bug.  The second line
    ddmmyy	of the status entry of the FIX has the date of the BUG to which
		the FIX corresponds.

    DO		A response to a TODO item that does the thing to be done.  The
    ddmmyy	second line of the status entry of the DO has the date of the
		TODO to which this DO corresponds.

    NIX		A response to a TODO item that explains why the thing to be
    ddmmyy	done wasn't done, i.e., why we decided against doing it.  The
	    	second line of the status entry of the NIX has the date of the
		TODO to which this NIX corresponds.

    FIXED	Suffix attached to a fixed BUG item; a corresponding FIX entry
    ddmmyy	appears at the given date.

    DONE	Suffix attached to a completed TODO item; a corresponding DO
    ddmmyy	entry appears at the given date.  If a DO response is simply
		that the item has been completed, then the separate DO entry
		can be omitted, with only the DONE suffix being added to the
		TODO entry.  This is different than the convention for a BUG
		fix, since in general the report of a bug and its fix require
		separate explantations, whereas the completion of a TODO item
		may often not require any additional explanation.

    NIXED	Suffix attached to a nixed TODO item, i.e., a TODO that was
    ddmmyy	decided against doing.

    RELEASE	A regularly scheduled project release, as defined in the
    number	project schedule.  The format of the release number is project-
		specific, e.g., 4.2-beta.  RELEASE entries do not need to be
		made manually in the LOG unless they are particularly
		noteworthy "action items" which warrant appearinng in both the
		normal project schedule as well as the LOG.

    UPDATE	A reqgularly scheduled update to the project, where regularly
		scheduled means it appears in the project schedule.  UPDATE
		entries do not need to be made manually in the LOG unless they
		are particularly noteworthy "action items" which warrant
		appearinng in both the normal project schedule as well as the
		LOG.

BUG and FIX entries are paired -- the BUG entry is made when a bug is
discovered; the companion FIX entry is made when the BUG is fixed.  Similarly,
TODO and DO entries are paired -- the TODO entry is made when the need for the
enhancement is disovered; the companion DO entry is made when the enhancement
is completed.  RELEASE and UPDATE are standalone entries, made whenever a
scheduled task is completed.

Since entries are sorted by date, entry pairing does not mean that entries are
paired lexically within the file.  I.e., a BUG appears in the file at the date
where the bug is discovered.  The companion FIX entry appears in the file in
its appropriate date position, which is only lexically adjacent to the BUG if
the FIX is made immediately.

Given that BUGs and FIXes may be lexcially non-adjacent in the log file, they
are logially related as follows.  When a FIX entry is made for a BUG, the date
of the fixed bug is entered, immediately below the "FIX" entry tag.  Also, the
suffix "FIXED" is added to the corresponding BUG entry, with the date of the
fix appended.  This provides a two-way cross reference between paired BUGs and
FIXes.  TODO and DO items are cross referenced in the same way.

This status convention is designed to leave historical BUG and TODO information
in tact.  I.e., instead of changing the status of a BUG or TODO item
permanently to FIXED or DONE, the suffix is attached and an additional FIX or
DO item is added to the log.  This retains the history of bug discovery and
repair.

For convenience and brevity, a BUG or TODO item may be handled immediately when
it is entered.  In this case, the FIXED or DONE suffix is added immediately
with the suffix "today", and there is no separate FIX or DO entry made.

The following linguistic conventions are used in the text of descriptions:

    * The descriptions of UPDATE entries are written in past tense, declarative
      voice.

    * The descriptions of BUG and TODO entries not fixed immediately are
      written in present tense, imperative voice.

    * The descriptions of FIX and DO entries are written in past tense,
      declarative voice.

    * The description of a FIX is as long as necessary to explain fully how the
      bug was fixed.

    * As noted above, a separate DO entry is only necesssary if additional
      explanation is needed to describe how the TODO item was accomplished.

The best way to maintain the currency of LOG files is the following:

    * Small TODO entries and all bugs should be added as soon as they are
      discovered.  The definition of "small" for a TODO item is a reasonably
      immediate task that is considered too small to be added to the main
      project schedule.  The deciding authority for defining "small" is the
      project manager.

    * All of the tasks in the main project schedule are considered items to be
      logged with UPDATE entries, made when the tasks are completed.  The
      description of such scheduled tasks is brief, referring by name to the
      scheduled task, e.g., "Milestone 1".

    * An effective way to deal with task-related log entries is to make them
      whenever a file is checked in.  When this occurs, diff the file being
      checked in with the previous version and make log entries for each
      "major" change, where major is a change separate from other changes.  The
      diff file itself can be discarded after the affected file is checked in.


DATE	AUTHOR	STATUS	FILE(S)		DESCRIPTION
===============================================================================

	-- See ./LOG for a sample set of entries. --