Advice for Authors

I've spent much of the last few days reading various ICML papers and I find there's a few pieces of feedback that I give consistently across several papers. I've collated some of these below. As a general note, many of these are about local style rather than global structure; I think that good local style probably contributes substantially more to readability than global structure and is in general under-rated. I'm in general pretty willing to break rules about global structure (such as even having a conclusion section in the first place! though this might cause reviewers to look at your paper funny), but not to break local stylistic rules without strong reasons.

General Writing Advice

• Be precise. This isn't about being pedantic, but about maximizing information content. Choose your words carefully so that you say what you mean to say. For instance, replace "performance" with "accuracy" or "speed" depending on what you mean.
• Be concise. Most of us write in an overly wordy style, because it's easy to and no one drilled it out of us. Not only does wordiness decrease readability, it wastes precious space if you have a page limit.
• Avoid complex sentence structure. Most research is already difficult to understand and digest; there's no reason to make it harder by having complex run-on sentences.
• Use consistent phrasing. In general prose, we're often told to refer to the same thing in different ways to avoid boring the reader, but in technical writing this will lead to confusion. Hopefully your actual results are interesting enough that the reader doesn't need to be entertained by your large vocabulary.

Abstract

• There's more than one approach to writing a good abstract, and which one you take will depend on the sort of paper you're writing. I'll give one approach that is good for papers presenting an unusual or unfamiliar idea to readers.
• The first sentence / phrase should be something that all readers will agree with. The second should be something that many readers would find surprising, or wouldn't have thought about before; but it should follow from (or at least be supported by) the first sentence. The general idea is that you need to start by warming the reader up and putting them in the right context, before they can appreciate your brilliant insight.
• Here's an example from my Reified Context Models paper: "A classic tension exists between exact inference in a simple model and approximate inference in a complex model. The latter offers expressivity and thus accuracy, but the former provides coverage of the space, an important property for confidence estimation and learning with indirect supervision." Note how the second sentence conveys a non-obvious claim --- that coverage is important for confidence estimation as well as for indirect supervision. It's tempting to lead with this in order to make the first sentence more punchy, but this will tend to go over reader's heads. Imagine if the abstract had started, "In the context of inference algorithms, coverage of the space is important for confidence estimation and indirect supervision." No one is going to understand what that means.

Introduction

• The advice in this section is most applicable to the introduction section (and maybe related work and discussion), but applies on some level to other parts of the paper as well.
• Many authors (myself included) end up using phrases like "much recent interest" and "increasingly important" because these phrases show up frequently in academic papers, and they are vague enough to be defensible. Even though these phrases are common, they are bad writing! They are imprecise and rely on hedge words to avoid having to explain why something is interesting or important.
• Make sure to provide context before introducing a new concept; if you suddenly start talking about "NP-hardness" or "local transformations", you need to first explain to the reader why this is something that should be considered in the present situation.
• Don't beat around the bush; if the point is "A, therefore B" (where B is some good fact about your work), then say that, rather than being humble and just pointing out A.
• Don't make the reader wait for the payoff; spell it out in the introduction. I frequently find that I have to wait until Section 4 to find out why I should care about a paper; while I might read that far, most reviewers are going to give up about halfway through Section 1. (Okay, that was a bit of an exaggeration; they'll probably wait until the end of Section 1 before giving up.)

Conclusion / Discussion

• I generally put in the conclusion everything that I wanted to put in the introduction, but couldn't because readers wouldn't be able to appreciate the context without reading the rest of the paper first. This is a relatively straightforward way to write a conclusion that isn't just a re-hash of the introduction.
• The conclusion can also be a good place to discuss open questions that you'd like other researchers to think about.
• My model is that only the ~5 people most interested in your paper are going to actually read this section, so it's worth somewhat tailoring to that audience. Unfortunately, the paper reviewers might also read this section, so you can't tailor it too much or the reviewers might get upset if they end up not being in the target audience.
• For theory papers, having a conclusion is completely optional (I usually skip it). In this case, open problems can go in the introduction. If you're submitting a theory paper to NIPS or ICML, you unfortunately need a conclusion or  reviewers will get upset. In my opinion, this is an instance where peer review makes the paper worse rather than better.

LaTeX

• Proper citation style: one should write "Widgets are awesome (Smith, 2001)." or "Smith (2001) shows that widgets are awesome." but never "(Smith, 2001) shows that widgets are awesome." You can control this in LaTeX using \citep{} and \citet{} if you use natbib.
• Display equations can take up a lot of space if over-used, but at the same time, too many in-line equations can make your document hard to read. Think carefully about which equations are worth displaying, and whether your in-line equations are becoming too dense.
• If leave a blank line after \end{equation} or \$\$, you will create an extra line break in the document. This is sort of annoying because white-space isn't supposed to matter in that way, but you can save a lot of space by remembering this.
• DON'T use the fullpage package. I'm used to using \usepackage{fullpage} in documents to get the margins that I want, but this will override options in many style files (including jmlr.sty which is used in machine learning).
• \left( and \right) can be convenient for auto-sizing parentheses, but are often overly conservative (e.g. making parentheses too big due to serifs or subscripts). It's fine to use \left( and \right) initially, but you might want to specify explicit sizes with \big(, \Big(, \bigg(, etc. in the final pass.
• When displaying a sequence of equations (e.g. with the align environment), use \stackrel{} on any non-trivial equality or inequality statements and justify these steps immediately after the equation. See the bottom of page 6 of this paper for an example.
• Make sure that \label{} commands come after the \caption{} command in a figure (rather than before), otherwise your numbering will be wrong.

Math

• When using a variable that hasn't appeared in a while, remind the reader what it is (i.e., "the sample space $\mathcal{X}$" rather than "$\mathcal{X}$".
• If it's one of the main points of your work, call it a Theorem. If it's a non-trivial conclusion that requires a somewhat involved argument (but it's not a main point of the work), call it a Proposition. If the proof is short or routine, call it a Lemma, unless it follows directly from a Theorem you just stated, in which case call it a Corollary.
• As a general rule there shouldn't be more than 3 theorems in your paper (probably not more than 1). If you think this is unreasonable, consider that my COLT 2015 paper has 3 theorems across 24 pages, and my STOC 2017 paper has 2 theorems across 47 pages (not counting stating the same theorem in multiple locations).
• If you just made a mathematical argument in the text that ended up with a non-trivial conclusion, you probably want to encapsulate it in a Proposition or Theorem. (Better yet, state the theorem before the argument so that the reader knows what you're arguing for; although this isn't always the best ordering.)