# Formats for 699 Project Proposals

Your project proposal (due at the beginning of each 5 week period)
must contain the following (you can even use this section numbering to
make it easy). 

For 699 students: if you're working on a team, each team member should
send their own proposal (to force everyone to go through the thought
process of planning), however it is important that you coordinate. For
class projects, a team can submit a single proposal.

0. <strong> Title and Due Date </strong>

   Picking a descriptive title is suprisingly valuable.

   Also, be clear on the day that the "deliverables" will be due (see
   below). While the date should be about 5 weeks away, you might want
   to adjust a day or two so it doesn't conflict with an exam in
   another class or something.

   Ideally, due dates should coincide with the weekly meeting so we
   can discuss the results then.

0. <strong> Problem Statement </strong>

   Briefly describe the _problem_ that you will solve. 

0. <strong> Methods </strong>

   Briefly describe how you intend to solve the problem. If you don't
   know, be sure to say so - but try to give some indication of the
   ideas that you have. If you have no idea, there might be an issue.

   In the course of doing the project, it could be that you're
   proposed methods won't work out, so its more likely that you will
   change methods over the life of the project than change the
   problem. That's why methods and problem are different.

0. <strong> Plan </strong>

   Give a rough outline of your plan of attack. This might change, but
   you should have at least thought about it. One way to phrase this
   is as a series of milestones or subgoals to the overall goals

   In your plan, you should be specific about what the first steps are
   (roughly the first week of the project). While the future might be
   hazy, you should have a clear picture about where to start.

   Also, if you are working on a team, you should discuss how you will
   distribute the labor.

0. <strong> Evaluation Criterion </strong> 

   How we will decide that you've been successful? How will you decide
   that you've solved the problem?

0. <strong> Deliverables </strong>

   What (specifically) do you intend to deliver. An interactive
   program? A library? Documentation? A written survey? Some pictures?

0. <strong> Readings </strong>

   This should have two parts: first the things that you've already
   read to prepare the document; and second, any readings that you
   expect to need to read in the process of doing the project.

   This may not be all of the reading you do for this class. If you
   don't expect your project to require a lot of reading, you should
   say so. Give some indication of what other things you will be
   reading. 

0. <strong> Risks </strong>
   
   Can you foresee any potential pitfalls that would prevent you from
   succeeding at reaching your goal? Being aware of these at the
   outset can help you plan around them.

0. <strong> Motivation </strong>

   Why are you doing this? It might just because you want something
   that solves the problem. Often there will be other kinds of
   objectives like learning something specific, or to enable some
   later project, or because its a research question and if you
   achieve the goal you can write a paper.

   If possible, your motivation should relate the project to the
   bigger picture.

## An Example

Here's a somewhat contrived example, based on what I've spent the past
week doing... (note: this is a one week project, so putting into the 5
week plan format is a little contrived)

0. Title and Due Date

   **TextWeb** due Jan 20, 2006

0. Problem Statement

   To create a system that will allow me to put materials on the web
   by putting text files into a directory. 

   The system should be able to take text files and dynamically
   translate them into web pages, surrounding them with a template and
   applying _Blosxom_ filters (like _MarkDown_). It should also
   provide for directory navigation.

0. Methods

   Use PERL/CGI (so its compatible with _Blosxom_ plugins).

   Keep a tree of the texts, have the URL's "PATH_INFO" point to the
   file or directory to be rendered.

   If its a text file, first send over the template, replacing the
   "body" with the text. Apply _Blosxom_ plugins to the text.

0. Plan

   - milestone 1: serve blank pages (just the template)
   - milestone 2: show the text file in the template
   - milestone 3: support directory listings
   - milestone 4: applying _Blosxom_ plugins
   - milestone 5: deploy for class web pages, tuning as needed

   The first step is to read enough of a perl/cgi book and figure out
   how to write CGI scripts and do file I/O. By the end of the first
   week, I should be able to have a CGI script that can get the
   PATH_INFO and use it as a file name for a file to send across text
   to a web browser.

0. Evaluation Criteria

   - I'll be done when its ready to be used for making the class web
   - I'll know its good if I really use it for the class web
   - The real long term test is if it proves easier to make webs this
     than just hacking the html with Dreamweaver

0. Deliverables

   - The textweb PERL program
   - A sample web / or a real production web to show it off

0. Readings

   PERL books to learn about PERL and CGI. Web resources on CGI and
   PERL as well.

   The PERL books I have from the library are:
   - PERL in a Nutshell (Siever et al, O'Reilly)
   - CGI Programming (Guelich et al, O'Reilly)

0. Risks

   - Learning PERL might be a bigger endeavor
   - Trying to interface with _Blosxom_ plugins requires deciphering
     _Blosxom_ source code
   - It might just be better to make web pages by hand

0. Motivation

   I'd like to be able to just type small text files and not have to
   think about how to make the web look nice. In particular, using
   _MarkDown_ sounds attractive.