CS Programming Project Writeup and Proposal Checklist

Writeups (or Technical Reports)

Strategy

There should be a hypothesis, problem, or a plan of work motivated by curiosity, by the problem statement, by reading. The technical report:

documents why the hypothesis or problem is interesting and important
describes the technical approach used to verify or falsify the hypothesis, solve the problem, or complete the work plan
describes the results, preferably with graphics and figures, less preferably with tables, least preferably with prose.
discusses the results; their relation to the hypothesis, plan, or problem, their interesting points, their predictable points, what questions they raise, and what to do next.

Form

Descriptive Title
Concise, accurate Abstract
Sections: These are not all necessary (Prior work could be included in the intro, future in the discussion). They may not be sufficient either, in that different aspects of the work may need their own main sections, especially in a group project with separate efforts amongst the members. But almost always the format resembles the following.
- Introduction, Background, Motivation, Goals -- What's the problem or hypothesis, why important, what's the problems's history?
- Prior Work (yours and others') -- what's the current state of knowledge and accomplishment?
- Methods -- hardware, software, mathematical tools, experimental setup.
- Results -- no editorializing, just the facts. Graphs and tables are best. A VERY BAD MISTAKE is to assume the reader or grader wants to, or even can, compile and run your code to see your results! NEVER DO THIS! Too much can go wrong. Devote an appendix to transcripts of interactions, to sample inputs and outputs, whatever it takes to show what your program does! Imagine it's a live demo and you want to show off all the features. Repeat: Include Your Results Explicitly Or Else.
- Discussion -- NOW you can editorialize. Is hypothesis verified or falsified? What's still unclear? How are results to be interpreted?
- Future Work -- what further work do the results motivate, what further hypotheses spring to mind? How can current work be strengthened or carried further?
- References -- related work from the literature backing up statements and justifying your approach. More is better.

Style

Nothing deep, just good writing!

Don't start abstract with ``this paper''. Don't peeve CB! . He's pretty prickly.

Stay away from passive if it obscures who did what. Eschew informality of all sorts. Use complete sentences. Read your paper aloud to see how it sounds. Spelling shouldn't be a problem nowadays but... Use paragraphs and sectioning to organize things. Pick one term for a concept or artifact and use it consistently throughout (e.g. Not: ``The system, our project, the program, GRIFLOG...'' in various places). If you use mathematics, make sure it reads like English. Reference all figures and tables in the text, and make sure they all have self-explanatory captions. Assume your reader is looking for the first excuse to stop reading (e.g. "doesn't reference my work"), and that the paper will be read in this order: title, abstract, conclusions, references, and only THEN if it passes all the readers' filters will it be looked at somewhat in order.

Proposals

Strategy

Proposals are all alike, from proposals of marriage (to the Father of the Bride) through sales pitches, proposals for funding, and proposals for projects.

In every case you need to convince someone that you are the person to do a particular thing.

Form and Content

For a project, your proposal describes the background, and the what, why, how, current state, schedule of your project. You can make up zippy titles for these sections -- the main thing here is content. As always, graphics and diagrams to show you are organized and you CAN organize are quite good.

Background and Motivation: What is the current state of knowledge or achievement concerning the problem you want to work on? (You can leave details to the ``Prior work'' section). What does the reader need to know to appreciate the motivation for and importance of the problem? What are the (possibly currently open) questions you'll be investigating, why are they interesting or important? Why should I keep reading this proposal?
Prior work: What has been done so far and by whom? This section is an annotated bibliography of references to the literature and explanations of what lore and techniques are out there and how they relat to your problem. What was left undone that you are going to do, or what body of work is your project closest to and how might it differ? Sometimes this section is incorporated into the ``Background and Motivation'' section.
A super good idea if you can do it: for work you consider original, find a set of axes (one or two, usually, that describe the domain of your problem. (Luckily, you get to make these descriptive concepts up.) Then make a table using those axes. Divide up the prior work into the appropriate cells. There is a cell that is sparsely populated or totally empty. Guess what? That is what you are propsing to do! The art comes in synthesizing the state of the art so you can come up with axes that make sense and that leave a hole for your proposed topic. For example, say computer vision could use inputs that are black and white or color (this is one axis), and that are still or moving images (another axis). So you have a 2x2 table. If all the work so far was in still B&W, still color, motion B&W, and there wasn't any in motion color, you could populate the proper cells with the proper references, and the empty cell demonstrates first how your work fits in, and second that it MUST be worth doing since there's this hole.
What: What are you proposing to learn, demonstrate, do, solve, try? Be specific. What question are you trying to answer? How will you know you've succeeded or failed? Remember there's a famous AI paper entitled ``I've seen your demo. So what?'' Ideally, you are trying to come to some conclusion about a hypothesis, not just, say, ``write some code to do X''.
How: How are you going to proceed? What subproblems, subtasks, are involved? How will you organize your approach to them? Flow diagrams are good in this section, showing who is going to do what in what order, what can be done in parallel, etc. (e.g. team members work in parallel for a while, integrate, test, experiment in parallel, meet and discuss, rewrite, take data, do statistics, write report). Which problems are easy and which are hard?
Current Assets: This is related to prior work, yours and others'. If you have done a pilot project, if this is an extension of a homework problem, if there is existing code you can or will use, if another professor is interested....All these and similar considerations are useful to give the reader confidence that you are not just jumping off a cliff. Quite often there are MORE assets out there than the proposer knows about, and so this list is a chance for the reader to make suggestions for substantial shortcuts. Personnel are relevant too: what is the composition of the team; how does this proposal play to their strengths? Put another way, why should the reader believe this team can do the job?
Schedule: A list of milestones, possibly related to the steps in the ``How'' section, with dates for expected completion.
References: WARNING -- these are often read FIRST. You need the usual bibliography in good academic style listing all the literature you cite in the proposal. It is suspicious-to-deadly if there are inadequate references. That says to the reader: These guys aren't serious players, they don't know what's been done, they are doubtless clueless about how to go about things, and will spend all their time learning or reinventing stuff. If for some reason the proposal is so far out there that no one has ever tried to work on a related problem, that had jolly well better be fully explained in the ``There IS no Prior Work'' section.