|
Final Report and PresentationThe two (and a half?) main products that your team is responsible for producing:
Final ReportOne 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:
AbstractThe 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. IntroductionThe introduction should include the following:
BackgroundWhat 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 IdeaExactly 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. EvaluationFor 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? ConclusionsThe 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. CitationsYour 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. GradingYour 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:
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 DraftYou 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. PresentationRead 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. |