Type Classification

All products will be divided maintained under three categories:
1. Web Documents
   • All products not dealing with code or formal reports will be Web Documents
   • The main documents in this class are
     1. Short and Long Term Plans
     2. Schedule
     3. Configuration Management Plan
     4. Design Document
     5. Testing Plan
2. Code
   • All products involving code-based work (The actual project and "learning" projects) will be considered code.
3. Reports
   • All documents that are to be submitted for evaluation will be classified as reports.

Naming Conventions

1. Web Documents
   • Documents will be maintained in a Talisman directory on Dan Singhal's machine. They will be available via http://elvandar.gt.ed.net/Talisman.
   • Naming convention for Web Documents will be as follows:
     <Document.Title>.html
     Where Document.Title is from:

     Requirements Document	require.html
     Configuration Management Document	config.html
     Design Document	design.html
     Testing Plan	test.html
     Short Term Plan	short.html
     Long Term Plan	long.html

2. Code
   • The naming convention for the Code has not yet been determined
3. Reports
   • Reports will be named for the type of report they are. They will also indicate which group the report is submitted for.

Configuration Management Tools

Revision Control

1. Web Documents
   All Web Documents will be handled by a single person. This person will henceforth be known as the Web Manager. They will be in charge of maintaining the accuracy and up-to-datedness of the Web Documents.
   Portions of documents may be written at other times by other members of the team, but shall then be submitted to the Web Manager for integration into the current Web Space.
2. Code
   Since the language of development supports multiple modules in an OO fashion, an OO approach will be taken in development. Each module will be written by a single entity at any given time, and they will control what changes are made to it. They will also be required to test their own code internally, and to be present at any integration steps.
3. Reports
   Reports will be written collectively. Sections of a report will be left for the member most knowledgeable of that area to write, and will be merged with other sections for the completed Report by a single entity. This entity will not necessarily be the same for all Reports. They are responsible for making sure that the report is merged.

Revision Monitoring

All products (Web Documents and Code, and Reports as applicable) will have header information indicating:
• Original Author
• Creation Date
• Purpose of Module
  In addition there will be added, whenever necessary, a revision header. This header will indicate:
• Revision Author
• Revision Date
• Reason For Revision
  These headers may be reduced or obviated if an RCS-like method is used for revision monitoring.