Final Report and Presentation

The two (and a half?) main products that your team is responsible for producing:

• A written report, which is due on Friday, December 20th at 5:00pm
  • A draft of your report is due on Friday, December 6th at 5:00pm
• A presentation, which your team will give on December 17th.

Final Report

One of the best essays I know on the topic of technical/scientific writing is The Science of Scientific Writing. You should read it. I reread it at least once a year.

Your written report should be submitted to your team repository. You should write your report in LaTeX and submit files called final_report.tex and final_report.pdf in the main directory of your repository.

Your report should contain the following:

• The title of your project
• The names of your team members
• A short abstract
• Introduction
• Background and related work
• Your idea
• Evaluation
• Conclusions
• Citations

Abstract

The abstract should be a 1-3 paragraph description of the main ideas behind the project. Abstracts should be comprehensible without reading the rest of the proposal/paper. Abstracts are advertising; you should strive for interesting over precise. It is usually best to write the abstract last. You should probably try throwing away the abstract from your proposal and rewriting it from scratch. You might even consider having each team member write their own abstract and then compare and contrast.

Introduction

The introduction should include the following:

• Enough background that anyone who has studied computer science should be able to understand the general outline of your project.
• Motivation. What specific kinds of people might benefit from your project, and how specifically will they benefit? The further you can zoom out to describe the potential broad implications of your project, the better.
• Contribution. How is your project different from all the related projects that have been done before? This is a concise (i.e. a very small number of paragraphs) description of the novelty of your project, not a survey of related work (that comes later). Your project need not be earth-shattering, but it must have some element of novelty to be research.

Background

What has already been done that is related to your project? You should cite as many closely related papers and/or other sources as you can. (If your project is on the applied end of the spectrum, it might make sense to cite a manual or technical documentation of some sort, but do your best to find published material also.) Researchers get very ornery when they see someone trying to publish work related to their own that doesn't cite them. Missing related work is a very common source of negative peer reviews.

There is disagreement about whether related work should come near the beginning or the end of a paper. Near the end is more common, but near the beginning is also done, and I think it makes papers somewhat easier for non-specialists to digest.

Your Idea

Exactly what goes in the core part of your report depends highly on what kind of project you did/are doing. It can be proofs, high-level algorithm descriptions, system outlines, experimental designs, etc. The main balancing act that you need to learn as a researcher is that you need to say enough that the reader understands what you did and what is interesting about it, but you should not include superfluous details of your development process.

A few good diagrams and/or concrete examples of your ideas can be extremely valuable.

Evaluation

For CS97, many of your projects will not be fully developed enough to wrap with a bow and send out for publication at the end of the semester. However, it is important that you demonstrate that you made non-trivial concrete progress towards the larger goals of the project. What evidence do you have that you actually made such progress?

Conclusions

The conclusions section of reseach papers is often wasted space. It is common to see basically a rehashing of the introduction. Try to avoid this. Try to zoom out and describe the broader connections and implications of your work. This is the place to discuss what further research your project motivates.

Citations

Your report needs citations. The number will vary considerably, based on how much related work there is, but less than 5 would probably be a red flag that you didn't do enough background reseach. You should use bibtex.

Grading

Your grade for your final report will be based on the quality of the report itself and the success of your project more generally. If you feel your project ended up being a "negative result", talk about what you learned and how specifically that will inform your next effort at this kind of project. If you're in this camp, you should think of your report as an expanded and deeper version of your proposal.

The three things that you really should nail in your final report:

• Context. Can anyone in computer science pick up your report and understand the importance of the kind of work you did for your project? This should mostly be handled in the introduction. When you're writing this part, think of cheerleading for the sub-(sub-)area that your project fits in.
• Novel contribution. What is the new idea or bit of evidence or analysis that your project gives to the world? You'll come at this from a couple different sides in different parts of your report, but it must be directly and plainly stated at least one. What is your novel contribution? (Don't feel anxious if your contribution is small or your plan didn't quite pan out. Talk to the instructor if you can't identify a novel contribution at all.)
• Related work. Reviewers love to shoot down conference submissions and proposals by saying "they didn't cite XYZ, which is clearly related." Don't give the reviewers that opportunity. Make sure you mention relevant related work and explain the connection to your own project.

The main question I will be trying to answer when I grade your reports is, how likely would I be to fund further work by these people on this (or a closely related) project? See the proposal assignment for a breakdown of what goes into that kind of decision.

There are no specific length limits on your report. I would be surprised if you could get everything in less that 5 pages. I will be grouchy about reading long reports that include unnecessary details. 10 pages is probably a fairly reasonable target, but I encourage you to not focus too much on length. You will get feedback on whether you need more or less material based on your draft.

Final Report Draft

You must submit a draft of your final report. Like many components of CS97, the draft will be graded basically pass/fail. As long as you submit something more than your proposal you'll get full credit. This is your one opportunity to get detailed feedback from me on your writing, so I encourage you to put a reasonable amount of effort into the draft.

Your draft should be submitted to your team repository. You should submit files called final_report_draft.tex and final_report_draft.pdf in the main directory of your repository. I will read and respond to drafts in the order in which they are submitted.

Presentation

Read Simon Peyton-Jones' advice about giving research presentations. In contrast to your report, your presentation score is based entirely on the presentation, not the success of your project. Even if you're luke-warm on how your project turned out, make the presentation compelling. A few good diagrams/pictures/graphs are infinitely better than slides full of text. PRACTICE! You will lose points if at any point teammates are staring at each other with the "uh, what next?" look.