Proofreading

• Correct errors noted in reviews.

• Carefully proofread for spelling, grammar, unclear language, and unhelpful redundancy. Make sure tense and pluralization are appropriately consistent in all sentences.

• Check that figure and table references are consistent. Specific points:

  • “Fig.” vs. “Figure” and “Table” vs. “Tbl.”; can mix and match e.g. “Fig.” and “Table”, but not “Fig.” and “Figure”.
  • Capitalization — when a reference is in the middle of a sentence, is the label (e.g. “Fig.”) capitalized? (At the beginning of a sentence, it should always be capitalized.)
  • Some journals or publishers have a specific style regarding how figures and tables are referenced: follow that if applicable. Springer is one such publisher.
  • If the publication venue does not specify a style, be consistent within the document. Look at a few recent papers to see what other authors usually do.
  • Typical style for ACM publications is to use “Fig.” and “Table”, and to always capitalize.

• When using LaTeX to render the final version: edit paragraphs so we don’t have last lines with only 1–2 words.

• Section headings should all be in title case. When a style uses all-caps for some headings, it is better to write them in title case and let the style code convert them to all-caps for display (LaTeX, Word, and CSS are all capable of this); that way, the PDF bookmarks, table of contents (when present), and similar navigational aids display them in title case.

• Figure and table captions should be consistent in terms of how they are written.

  • Are they written as short headings or as complete sentences with a period?
  • Do they use title case or sentence case? (complete-sentence captions should only use sentence case.)

  Be consistent within a type of caption. It’s fine to use heading-style captions for tables and full-sentence captions for figures (this is common practice); but you shouldn’t have some of the figure captions be heading-style and others be full sentences.

• Each bulleted or numbered list should be consistent within itself. All elements in the list should either be complete sentences or sentence fragments; don’t mix-and-match.

• Check for correct and consistent use of punctuation:

  • Use quotation marks properly and consistently (single vs. double, matched opening and closing quotes).

  • Be consistent about how quotation marks and other punctuation interact. I typically use the British style, where the punctuation goes outside the quotation marks; in computer science, where we often need to quote code that may include important punctuation, this method is more precise than the American style, as it ensures that only what is actually being quoted is inside the quotation marks. For example, write:

    According to Smith et al., “quotational accuracy is vital”.

    instead of:

    According to Smith et al., “quotational accuracy is vital.”

  • Use the serial (Oxford) comma in comma-separated inline lists. That is, write “one, two, and three” instead of “one, two and three”. In almost all cases, it is less ambiguous.

  • Use semi-colons to separate items in complex inline lists that have commas within the list items, to reduce ambiguity. It should be clear what is a list element and what is a subclause of a list element.

  • Use appropriate dashes in appropriate places: a hyphen (-, -) to separate hyphenated words; an en-dash (–, LaTeX --) to denote a numerical range (e.g. 7–10); and an em-dash (—, LaTeX ---) as a parenthetical or marker in text.

  • Use em-dashes consistently. It’s fine to have space around an em-dash (like — this) or not (like—this), but be consisten throughout the paper.

  • Make sure all adjectival phrases are properly hyphenated (e.g. “a log-based metric”, not “a log based metric”).

Figures

• All figures should look good (not pixellated) when zoomed way in. Figures should be at least 300 dpi when rendered to a raster format (e.g. PNG). This means a 7×5 image should be at least 2100×1500 pixels.

• Text should be legible at a reasonable PDF zoom resolution.

• Text should be a relatively consistent size between figures, especially subfigures within the same figure. This is easiest to do by rendering all images to the same width (relative to their width in the final paper) in Python or R; 5 inches is often a good width for an image that will appear in one column in a two-column format with \includegraphics[width=\textwidth].

• Figures should not be distorted vertically — their aspect ratio in the paper should match their source aspect ratio. In LaTeX, never use height= when including an image; instead, resize it based only on the width.

References

• Make capitalization of paper and conference publication titles consistent. ACM style is to use title case, but sometimes our BibTeX has sentence case, depending on where we got it. If you use title case in your BibTeX, then BibTeX will automatically display it in sentence case if that is what a style demands; words that should remain capitalized need to be enclosed in braces (e.g. {LensKit}). It cannot convert the other direction.

  If you use Zotero (which I recommend), it has a further limitation that it cannot convert from title case to sentence case (because the braces are a BibTeX thing, not Zotero). The solution for this is:

  1. Use the Better BibTeX plugin
  2. Store titles in Zotero in sentence case, with proper nouns etc. capitalized

  Better BibTeX will convert the sentence case to title case in the BibTeX and insert the protective braces, and your final bibliography should be correct.

• Be consistent about abbreviated vs. full conference proceeding names (e.g. “Proceedings of the 43rd ACM SIGIR International Conference on Advances in Information Retrieval” vs. “Proc. SIGIR ’20”). I typically use the full title when we don’t have a length limit on references, but the important thing is that we are consistent throughout the bibliography. Also applies to journal titles, but the problem is more common in conference proceedings.

• Be consistent about what fields are included - no one really cares that the ACM is in New York, and we don’t have that info for all proceedings, so it can be dropped.

• If we have a DOI, we don’t also need a URL. BibTeX doesn’t usually include both, but check.

• If we have an ACM / IEEE / Springer publication that doesn’t have a DOI for some reason, look it up and add it.

• If citing a preprint, check for a current formally-published version of the work and cite that instead, unless we are specifically citing the work for something that only appears in the preprint.

• Sometimes we can get duplicate citations. Check for these and only cite one.

When using BibTeX, I recommend making most of these changes in your reference manager, re-exporting. That way, the citations are consistent for the next paper you write. There are two exceptions: removing URLs (leave the URL in the reference manager, but remove it from the BibTeX after export) and abbreviating proceedings titles (I usually find it works better to keep the full title in the reference manager and edit the BibTeX to have the abbreviated one if we are using those).

Content

• Clarify writing on points that reviewers found confusing (either because they directly commented on the confusion, or because it is a likely cause of other confusion about the paper reflected in their comments).

• Make sure we have appropriate acknowledgements. Usually need to mention:

  • Funding source(s).
  • Special computing resources (e.g. the compute cluster, with a citation if appropriate).
  • People and organizations who provided resources for the paper (hardware donors, data donors, etc.). We don’t need to mention things we obtained publicly, such as a publicly-available data set; the citation is enough for those. But if someone gave us data privately, we need to acknowledge them.

• Ensure author names and affiliations are complete and consistent, and author names are listed as each author prefers (e.g. I publish as “Michael D. Ekstrand”).

• If we have promised code, make sure that has been uploaded and an appropriate link inserted into the paper.