Group Directory Requirements

As part of your project you will submit a package of documentation and source of the 
software your team has built or incorporated into your design.  The structure of your 
documentation and source should follow the format below.


[grpX] (X is your group number)

  --- [docs]
     --- [external] (any documentation you used during the course of
                    development E.g. manuals or datasheets)
     --- [biweekly] (your biweekly reports)  Naming convention should
                    be biweekly_X.(txt|doc|pdf|ps) where X is the week number
     --- [htdocs]   (your project website, index.html should include
                    team member contact info, project name, project
                    description/abstract, links to your midterm and final reports,
                    and any other appropriate information)
     --- midtermreport.(txt|doc|pdf|ps)
     --- finalreport.(txt|doc|pdf|ps)
     --- midtermreport(.ppt) presentation (most likely PowerPoint)
     --- finalreport(.ppt) presentation (most likely PowerPoint)

  --- [src]
     --- _readme.txt (This file should contain information about your
                      source tree layout, installation procedures, and any other
                      information needed to use your system.)
     --- [final_release] (This directory should contain the final version of your code)

You may organize your source tree as you like, as long as the final_release directory 
includes everything for your system.  Try to minimize the size of your source directory by 
organizing such that you do not duplicate files.  

Filenames should only use the following characters 0-9, a-b, A-B, dash
and underscore.  Do not use spaces or other strange characters that
can cause problems across platforms.

Zip your grpX directory into one zip file with your semester and group name and 
place this in the grpX directory before your project demonstration.  For example, the fall 
semester 2001, group 8 zip file would be named 01C_g8.(zip|tar.gz|tgz)

The purpose of having a documentation/source guideline is to ease maintenance of project 
data so that future teams may efficiently, accurately, and successfully use the 
advancements you make.

Email questions and/or problems to Rabi Mahapatra