Ulle Endriss — created: 30 November 2010 — last updated: 29 February 2024
On this page I'm collecting suggestions for how to approach the difficult task of writing a paper. What I have in mind in particular are papers of the sort I have most experience with myself, namely those published in the proceedings of AI conferences. These are relatively short papers (typically between 5,000 and 10,000 words), presenting a small number of ideas and results. They typically combine contributions of a conceptual and of a mathematical nature. They need to be relevant and interesting for experts in my own subfield of AI, while also being accessible to the broader research community. I expect that some—but certainly not all—of my suggestions will also be relevant to other disciplines and other formats.
These notes have grown out of a list of suggestions written for the students in my course on computational social choice in 2010. They have also been influenced by a short course on academic writing I co-taught for the PhD Programme of the ILLC in 2016.
You should put considerable effort into polishing your paper. Pay attention to grammar. Use the right kind of language. Be as formal as is appropriate, but not boring. Always use a spell-checker. Typos are unacceptabel. Pay attention to formatting issues: be proud of your work and make it look nice.
I strongly recommend using LaTeX. It is very helpful, both for typesetting complex mathematical statements and for properly structuring your document. Certainly in my own area of research, you risk not being taken seriously if you use anything else.
Choose a good title for your paper. It should give a clear indication of what the paper is about. It should not be too general (and thus implicitly claim to cover much more ground than it actually does). It should be short. Avoid the use of acronyms. Resist temptation to pick something overly catchy. Maybe nobody else will get the joke.
Your paper should start with a short abstract (of around 150-250 words). The abstract should summarise what the paper is about. It should be easy to understand and it should be self-contained. Keep in mind that some potential readers will first see your abstract in isolation rather than in the context of your full paper (e.g., on the website of a conference or journal).
The abstract should not include any citations (as that would stop it from being self-contained). If you absolutely must refer to another paper, then provide enough bibliographic information within the abstract itself to allow people to actually identify the paper you are talking about.
You'll probably want to start with an introductory section, followed by a second section that sets up the framework you are working in. And you'll probably want to end with a concluding section, followed by the bibliography, and possibly an appendix. I comment on each of these components below. Between these two ends, the central part of your paper will consist of a small number of additional sections, about which it is more difficult to give general advice. Where to cover related work is an interesting question in its own right, which I discuss below.
Avoid having too many sections. All else being equal, aim for sections of roughly equal length. Consider structuring your sections using subsections. In doing so, keep these two rules in mind:
Motivation. Start by introducing and motivating your topic. Maybe you can start by describing an application that is obviously useful and then show how your research question is relevant to that application. Or maybe you want to start with a broad statement about an established area of research and then zoom in to explain where your own topic is located with respect to widely known and widely accepted issues.
Try to actually get to your topic by the end of the first paragraph. In any case, definitely don't spend a full page on background material before getting to the actual topic of your paper.
Contribution. Use the rest of the introduction to set the stage for the body of the paper and to offer a preview of your contributions, without getting too technical. Often it will be appropriate to already briefly discuss some related work at this point.
Final paragraph. The introduction should end with a short "paper-overview paragraph". For each section, say (usually in one short sentence) what it is about. This paragraph may very well duplicate information from the body of the introduction. This is fine: it serves as a kind of table of contents for the paper, in a place where people will look for it.
In fields where there are very strict norms on how to organise a paper this kind of paragraph may of course be redundant. For instance, the body of a paper in the experimental sciences often consists of sections on results, discussion, and methods.
Section 2 is typically used to introduce basic terminology, notation, and definitions. This might include both basic standard definitions and the central definitions of the specific framework you are working with or which you are proposing in your paper. Remember that most readers will not read your paper from start to end, but may well start with the abstract, then jump to a specific result in the middle of the paper that looks interesting to them, and finally scramble back to figure out what the relevant definitions are. You need to help these people. So sometimes you need to sacrifice a bit of the flow of your narrative in favour of making your paper easy to navigate. Putting all the important definitions into Section 2, rather than introducing them one by one as the story develops, is an example for such a sacrifice.
Section 2 is often called "Preliminaries" or similar. I think this is a good name if it is mostly about collecting (and maybe adapting) existing definitions that are relevant to your paper. But if the definitions themselves already constitute an interesting contribution, then I suggest to choose a more ambitious name for this section.
The importance of this section is not to be underestimated. I often find that figuring out the perfect notation and terminology to tell your story is extremely helpful, not only to make that story more accessible to your readers, but also to help you clarify the concepts you are working with to yourself. It ultimately leads to better research.
So this section introducing notation and terminology needs to be crafted very carefully. Forgetting a crucial definition (or including definitions that in fact are not required) is unforgivable. Never copy-paste some standard paragraphs into your new paper. If your new paper is worth your and your readers' time, then it deserves a background section written specifically for that paper.
Conclude your paper with a (usually) short section that (i) summarises what you have done, (ii) evaluates the results, and (iii) outlines some ideas for future work.
Summary. This will repeat information already stated earlier in the paper, but it is an opportunity to highlight the most important findings. In case it is not obvious, here you might also say (again) how to interpret your findings: are they positive or are they negative results?
Evaluation. In this context, evaluating your work means to critically assess to what extent the goals set out in the beginning of the paper have been achieved. In most cases you will be able to report partial success, and it is important to point out both what went well and where there is room for improvement.
A typical mistake made by beginners is to mention that you were running out of time as a reason for why a particular goal has not been achieved. Of course, this can happen (it always does), but it is of no interest for the paper. Instead, what matters here are things such as difficulties inherent to the problem and general limitations of the approach.
Future work. This might include things you plan to do yourself as well as things that you generally consider interesting (and, at least in principle, feasible). As someone who has just immersed themselves into the topic and therefore probably has a better understanding of the very specific problem studied than almost anybody else, your opinion on what is important and what is feasible in this area will be useful for others contemplating whether or not to get involved.
A specialist should be able to derive some value from the final section without having to read the rest of the paper.
The final section of your paper should be followed by a list of bibliographic references. List everything you cite and cite everything you list. Cite all your sources. Make sure you have actually consulted everything you list (this need not mean that you have read all those papers from start to end). Include all the standard bibliographic information with each reference (e.g., for a journal paper this means: authors, title, journal name, volume, issue number, page numbers, year).
BibTeX is a great tool for organising your bibliography. But keep in mind that, at the time of writing these words, most of the automatically generated BibTeX entries you can find online will have some mistakes in them and require manual polishing. Always look at what the bibliography generated actually looks like and make sure you are listing items of the same type consistently across your bibliography.
There are different ways in which to refer to an entry in the bibliography from within the body of the paper. I recommend that you use a citation style in which the surnames of authors are spelt out inside citations. This makes for a much more pleasant reading experience. Of course, some publishers prescribe a different style, and then you just follow their guidelines.
Make sure your sentences involving citations actually make sense. For example, "Arrow (1950) proved a nice theorem" is perfect. "Arrow [17] proved a nice theorem" (assuming you are using a numerical citation style and [17] is Arrow's paper) is also fine. "(Arrow, 1950) proved a nice theorem" is not ok, and anybody writing "[17] proved a nice theorem" will burn in hell. Note that phrases such as "the theorem proved in (Arrow, 1950)" don't make much sense. Rewrite this as "the theorem proved by Arrow (1950)" or "the theorem proved in the work of Arrow (1950)". Use the parenthetical form of citation, as in "(Arrow, 1950)", only at the end of a sentence (or a part of a sentence). Here's a simple rule of thumb: if you read out your sentence aloud, omitting all the stuff in parentheses, then what is left should still be grammatical. If you are using BibTeX, some styles (such as natbib) come with two separate commands for textual and parenthetical citations (\citet{...} and \citep{...}, respectively). Use them.
Remember that it's people you are citing. So make sure you pick the right pronoun (he, she, they) and the right verb form (singular or plural).
You may decide to put some of the less exciting material in an appendix, e.g., a particularly technical proof.
You should compare what you have done to some of the related work in the literature. Sometimes it makes sense to include a section specifically devoted to related work. Personally, I often don't like these sections very much: if people just write down a series of sentences of the form "X and Y have done Z, which is different from what we have done", then that's not very interesting. Often you can do a better job by describing a specific piece of related work exactly at the point in your own paper where you are actually doing something similar to that piece of related work. This allows for a much deeper analysis.
Having said this, of course, there are some papers with very good "related-work sections", that give a nice and helpful overview of a particular strand of the literature. If you do want to include such a section, there are two options: either place it near the beginning of the paper or near the end. The former makes sense if you mostly want to give credit to other people for having inspired your own work. The latter makes more sense if you mostly want to compare some of your own techniques to the techniques used by others. Indeed, for a serious discussion at a technical level, you probably need to present your own work first, before it becomes feasible to make comparisons.
In particular if you opt for a technical "related-work section" near the end of the paper, or if you spread the discussion of specific pieces of related work around the paper, you probably want to briefly acknowledge some prior work in the introductory section.
When writing, I often find it useful to keep in mind the criteria that reviewers typically are asked to consider when evaluating whether a paper can be accepted for publication (see also my notes on how to write a review):
What follows is an unstructured collection of pieces of advice that did not fit neatly under any of the headings above.