Basic submission checklist.
09 May 2019When I review, lately it seems like I say the same things to authors. This checklist is compiled not in the interest of academic snobbery, but to help authors get their papers in good shape prior to submission. I’ll also mention why these components are important from the reviewers’ standpoint. When I review, I try to explain in detail why it is difficult to understand the paper as written. Whether this information gets across is hard to tell within the reviewing system. Interested in how to review? I have another post on that topic.
Back to Tips and Tricks Table of Contents
Back to the academic papers section
This is a basic submission checklist. Other guides on academic paper writing that cover in-depth topics abound online; I have collected some that are relevant to my scientific field at another article.
The reviewer – who is this person?
Reviewers are typically over-committed people who may, or may not, be enthusiastic about your work. Within my field, we’re given three weeks to review conference papers, and up to two months for journal papers. Sometimes, it is hard to schedule time to do the review with other unexpected events within my own research program or personal life.
With this in mind, clarity should be the goal of your paper. Do not aim for artfulness. The reviewers do not have time for it. They also do not have time for the very common errors I am going to list below. You will also lose time by submitting papers with these easy types of errors, because reviewers will not understand the science behind your paper.
The types of papers I typically review.
Over the last two years, I have been reviewing:
- robotics papers sent to conferences.
- computer vision papers that concern three-dimensional reconstruction.
- robotics system papers that concern agricultural applications.
- lots and lots of calibration papers.
The list.
These items are in no particular order.
- Mathematical notation: every variable must be described before you use it. Example: “the transformation from the world coordinate frame to the camera coordinate frame is represented by homogeneous transformation matrix A.” Yes, I lifted this from my own paper. If the reviewers can’t follow the notation, they will be confused as to what you are doing in the paper.
- Mathematical notation: ensure that you do not reuse letters from one section, in another section, but with a different meaning. Negative example: Matrix Ai does X, Y, Z, …. then Yi but here the i indices are not the same. This practice leads to reviewer confusion.
- Acronyms: Define acronyms on first use. I might give you a pass on global positioning systems (GPS), but throwing out acronyms is an easy way to confuse reviewers. Sure, they could use a search engine to look it up, but remember, these are people with not a lot of time, and they are putting aside their own commitments to review your paper. Make it easy. The way to do this is to write out the acronym meaning, and then write the letters within parentheses, like I did with GPS. After the first use, you can use the acronym as much as you want. GPS GPS GPS.
- References: Make sure that the references in the text refer to the correct references in the reference list. Ensure that the reference manager has not garbled the author names (double check that diacritical marks have rendered, and that the accents are going the correct way. There’s a difference between acute and grave accents!).
I find that sometimes in Zotero, I have to edit the bibtex file directly when there are diacritical marks.When you are using bibtex, you’ll always have to ensure the diacritical marks are rendering. For instance, when you download the bibtex for a name with a tilde, the character will beñ. In latex, to get that character you can type\~{n}. To ensure the same character in bibtex, you have to substitute{\~n}. More details – Stack Exchange. - References: Reference managers are great, but you still need to check that the reference list has been propagated correctly. I personally like to check if arxiv versions of papers have been published, and cite the published versions. However, this is only a personal preference. Google Scholar makes this easy to see all versions of a paper if you need to find the conference versus journal version. Niklas Elmqvist has a more in-depth post about references.
- References: When referring to a work with one author, you do not need et al. Example. “as in the work of X [1].” Two (and only two) auhors: “as in the work of X and Y [1].” At three or more authors, break out et al.: “as in the work of X et al. [1].” Check out page three of IEEE’s author guide, and technically et al. is italicized since it is an abbreviation of a non-English word (Latin). However, when I review, I don’t care about the italics or the period. If this information is new to you, get used to doing citations in text correctly. We don’t have professional editors at journals within engineering (that I know of), and this style is consistent among disciplines. I learned how to do this during my days at a liberal arts college, writing my first research papers on music (or was it during high school English? anyway, a long time ago). I create a command in latex to deal with the italicized et al., with a period.
- References: When referring to other authors, make sure to spell their names correctly. This includes the diacritical marks (accents, umlauts, etc.). Why? If they are your reviewer, they hate this kind of thing.
- Every claim should be backed by a reference or be known. In other words, don’t go off on tangents; make sure the article does not turn into an opinion piece. Reviewers will latch onto every controversial item, so do not give them ammunition. A typical example: “This is the most popular method at the moment.” Revised: “This method has gained in popularity over recent years, largely because of X, Y, Z (reference).”
- State the contributions of the paper clearly. If you, as an author, do not know what the paper’s contributions are, then you have more writing and thinking to do.
- All figures must have a caption that explains the figure well. Some readers will only skim your paper, and well-explained figures can go a long way towards explaining the text of your paper and saving space – particularly for conference papers, where you have space limits.
- If you have graphs, all axes should be labeled (units and item). The graph should be legible when printed out – not only when zoomed at 400% with a pdf viewer. A worst ten list from Karl Broman provides examples of bad graphs.
- Use the latex style file from that year, and check the submission guidelines carefully. These guidelines change from year to year, and your paper will get kicked out of the conferences for violations. If the conference is double-blind, absolutely double check to make sure that your paper does not reveal your author names or affiliation, and have a non-author check it for you if possible and you are new to double-blind submissions. I do not list author names in any draft of double-blind submissions because of paranoia about this.
- On every occurrence of “better”, “best”, “more than”, “less than”, etc. ensure that these statements are qualified. Negative example: “This method is the best at task X.” Revised: “Method A performed the best in 3 out of 4 trials using the B metric on task X.” Real evaluations are subtle, and reviewers appreciate when authors do not oversell their system.
- Equations: for all equations in display mode – meaning, they are not inline with some text – use numbering. How to do this in latex is to use
\begin{equation}and\end{equation}tags. More complex equations can be numbered using the{align}and{multline}environment with theamsmathpackage. Why? If a reviewer wants to refer to an equation, it is much easier to do so by equation number than its location in your paper, and you also can reference the equation easily in the text if it is numbered.
Bonus item.
Finally, design the color scheme for figures such that someone with color blindness can understand the figure. I have been suggesting that authors redesign figures in future publications to be more color-blind friendly for a while now, particularly for tough examples, such as those with the ‘stoplight’ overlay (red-green; sometimes this works, sometimes it does not). Color blindness is common. Coblis has a simulator where you can upload your figures to simulate various types of colorblindness, and there are many other guides and tools within the data visualization community on this topic.
I was told (gently) about the need to change my color schemes from the red-green color scheme after a talk I gave in the late 2000’s. I remembered!
Another checklist.
This checklist is not about the basics, but some may find it helpful:
- Association for Computing Machinery’s Special Interest Group on computer architecture’s (ACM SIGARCH) empirical evaluation checklist. article; checklist.
Changelog.
- Added the link about typesetting of diacritical marks, November 2019.
- Changed link from Cormac McCarthy’s thoughts on scientific writing to the list-article post, December 2019.
- Added the item about graphs, February 2020.
- Added the item about equation numbering, May 2020.