CS 294-105: Class Reports

Overview

1. Background material sufficient to understand the problem domain, data you are using, and analysis considerations. It is fine to craft this to me as a particular reader if you wish. (So, for example, the background could be very short or even skipped for topics I've worked on; and should be pitched for a general CS audience for topics outside of networking and security, which is what I focus on.)
2. An overview of your analysis target(s). Include any reflections you have on the implications of those targets (e.g., particular data or analysis challenges that they pose).
3. A thoughtful presentation of the measurements on which you base your analysis: how you gathered it, a summary of their salient features, and an assessment on any issues (such as biases) arising from the particular measurement process.
4. An examination of data quality issues. Explain what you assessed in this regard (including potential issues that turned out not to be problems).
5. If appropriate for your particular analysis target, discuss the data exploration you undertook to illuminate the nature of the data as it relates to what you want to analyze.
6. Discussion of your analysis process and associated issues.
7. Brief discussion of argumentation for presenting your results. That is, which aspects of the preceding facets of empirical analysis (presentation of measurements, data quality, data exploration, analysis process) would you include in a paper presenting your results? What "narrative" would you employ and what new illustrations would you want to create, if any? This unfortunately isn't a topic that we've been able to spend much class time on, so you do not need to delve into these considerations in any depth. This is more an opportunity for you to get feedback on your proposed argumentation approach.

What to Turn In

Submit either PDF or HTML, via email attachment. I will primarily be reviewing reports from hardcopy, so the writeup needs to print clearly and with sufficiently large text (11 point font) and figures. If you use color figures, mention that in your cover note so I can send it to an appropriate printer.

In addition, also submit your document source. It doesn't need to build (e.g., okay to leave out LaTeX packages and figures; it can be helpful to include your bib file, though). I sometimes use source as a convenient way of commenting on different parts of writeups.

Reports are due Monday Dec 15 at 2PM.

Finer-grained Writing Considerations

Here are some pointers regarding writing your report (subsetted from a more general list from CS261N):

• Use active voice (verbs that convey action) rather than passive voice ("is" verbs). For example, "We need to consider the problem of spoofing" rather than "The problem of spoofing is something to consider". Passive voice, especially lengthy sequences (occasional uses are fine), reads stilted, and makes it harder for the reader to keep their train of thought focused.

• Avoid sans serif fonts (those without any tails or hooks on the letters) such as Helvetica. These are significantly harder to read than serif fonts such as Times Roman.

• Beware of excessive significant figures. For example, if you have 310 data items, 46 of which have some property, then don't express that as 0.148387096 of the items having the property. You have at most 3 digits of precision to start with, so stick to 0.148.

• Be sure to number your pages. Doing so allows the reviewer to refer to particular text in their comments.

• Make your figures large enough so that they clearly show the points you want them to illustrate. (If you typeset your report in two-columns, consider using double-column figures if necessary.) In an actual conference submission, you often can get into trouble with page limitations, and then have to squeeze down figures to stay within the length requirements. But that's not an issue for your class report.

• Likewise, for a writeup like this where you don't have space restrictions, use an 11-point font or larger, so the text is physically easy to read.

• If possible, your figures should work if printed in black-and-white, since some reviewers do their reviewing using hardcopy. (I'm one of them, but if your figures need color, let me know and I'll print them accordingly.)

• Spell-check and proofread to correct grammar errors. If your text has too many of these, it can cost you in terms of assumptions the reviewers may make regarding your general attention to detail (and thus whether they trust that you conducted your analyses carefully). If your English is not fluent, it's worth getting help with it. Unfortunately, for "blind reviewing" (conferences that require anonymized submissions), deficiencies in English can prejudice the reviewers towards expecting inferior quality in the work. Conversely, engaging writing can really help in subtly suggesting to the reviewer that you know what you're doing and they should trust you on unclear fine points.

  To automate some of this, you might want to check out this tool by UCB grad student Devdatta Akhawe, these scripts, and, if you're an emacs user, flyspell or writegood modes.

• Some nits to proofread for:
  • Using the same word twice in the same sentence, or (sometimes) in nearby sentences.
  • Typos of repeated words, such as "and and".
  • Regularize your bibliography. Avoid redundant dates like "Proceedings of the 2003 Foobar Conference, March 2003", instead listing them as "Proceedings of the Foobar Conference, March 2003". Beware of how Bibtex can mangle your capitalization. Avoid abbreviating journal or conference names if they don't correspond to venues well-known to your audience.
  • Avoid phrases like "and more" or "etc.", which beg the reader to try to imagine what else is missing, and (subtly) convey a sense of "we the authors can't be bothered to make this more clear".
  • Right-align numbers when putting them in tables, and use commas for numbers larger than 3 digits. This makes the magnitude of numbers easier to visually assess.
  • If using LaTeX, make sure you use open-quotes (``) and close-quotes (' ') rather than double-quotes ("), which it renders in only one direction.
  • In LaTeX, you will usually want to use \sloppy (less uptight regarding line-filling), and \url for displaying URLs.
  • In LaTeX, don't use math mode, like $emphasis$ to italicized for emphasis, as it messes up the spacing between characters. Instead use \emph{emphasis} (or, if you're a literalist, \textit{emphasis}).
  • Avoid contractions like "don't". These stand out as too informal in technical writing.

  These might seem trivial, but they can convey to the reader a sense of whether you took the time to carefully read over your draft.

What If I Still Have Questions?