Writing Clear Conference Submissions

Shai Halevi

Preface

This page offers some tips on how to write a clear confernce submission. These tips are just my own ideas about what I want to see in papers that I review. For an excellent resource on how to write papers, go read Oded Goldreich's essay at http://www.wisdom.weizmann.ac.il/~oded/writing.html.

My thesis is that to write clearly you must know what you want to say and you must think about your readers; the rest will follow. For the most part, this page contains many examples of these two principles. These examples are geared toward authors of papers in theoretical cryptography, but they are probably also relevant to other audiences.

Two disclaimers:  First, I do not pretend to be an authority on writing papers. You, the reader of this page, should only take from the tips below whatever makes sense to you. Second, there is no evidence that a clear submission has a better chance of being accepted to a conference than a cluttered one. The mandate of a program committee is to select for presentation the papers that describe the most interesting advances in the area, not necessarily the best written ones. But having clearly written submissions can make it easier for the committee to do its job.

1   Things to keep in mind

1.1   Distill what you want to say

The most important thing in writing a paper is to decide what is it that you want to say. The main point in writing a scientific paper is to teach the reader something new. You need to make it crystal-clear (to yourself, at least) exactly what this "something" is.

Try to summarize for yourself the main idea(s) in the paper as concisely as you can. Can you summarize it in one sentence? In one paragraph? Imagine that your colleague (who is as fluent as you are in your area of research) just came back from vacation, and you want to tell her about your result in five minutes. You don't need to fill her up on background, just the new idea. How would you describe it then? Notice that the new idea can be anywhere from very specific to very conceptual. A few examples of such bare-bone summaries are listed below (but don't take them too seriously).

1.2   Think of the audience

Try to think who would you want to read your paper. For example, what background does a reader need to have in order to understand and/or appreciate the new result? If you find that one needs to know the entire history of civilization just to understand your terminology, can the presentation be altered so that the main ideas are understood without so much prior knowledge?

When writing the paper, make a conscious effort to see it through your reader's eyes. You may have been thinking on the subject for weeks, know exactly what goes where and have full knowledge of all the details. But there is no reason to think that the reader has the same intimate knowledge of all the relevant aspects. One way of simulating a reader is to write the paper a long time in advance, put it out of sight for a month or two, and then go back and read it. Unfortunately, this is rarely applicable to a conference submission. If there are several authors, it sometimes helps to read each other's parts.

In the context of a conference submission, most readers only have a few hours to read, understand, and evaluate your paper. They will need all the help that you can give them. Make it a priority to give them as much help as you can.

2   The abstract and introduction

It is very helpful to the reader if you can put the one-sentence summary of you idea already in the abstract. This may be hard to do, especially if the new idea is very technical and specific, but when possible it is well worth the effort. Consider the first example from above, regarding Retician's Inactive-Pooch system. Although it is not possible to explain already in the abstract what is the problem in the proof and why simulating only the important threads helps, you may still be able to describe the main contribution of your work as follows:
Inactive-Pooch systems are very useful [...] However, they tend to be quite inefficient. In particular, the famous scheme of Retician needs to send O(k) bits for every tick. In this work we improve this to polylog(k) bits per tick, by carefully modifying the proof of the main reduction in Retician's work.
Although the reader cannot understand at this point exactly what you did, it is already clear that the contribution will not come by introducing a whole new scheme, but rather by giving a better analysis of the well known scheme of Retician. Moreover, a reader that makes it to the technical part would know where to look for the main technical contribution.

Next comes the introduction. Here you have another chance to explain what you do on a high level, and also why it is interesting. Keep in mind the new thing that you want to teach your readers. By the end of the introduction, the reader should know what is the new idea (even if not all the details).

It is sometimes possible to give all necessary ideas in the introduction. The rest of the paper then just goes through the motions of formalizing and proving everything, and most readers could (in principle) do it themselves after reading the introduction. Other times there are technical issues that are too involved to explain in the introduction. Even in this case, however, the introduction should give the reader some rough idea about what's coming next. Returning to our running example of Inactive-Pooch systems, you may give a high-level description of Retician's scheme, explaining that the scheme sends a new key for every tick, and these keys are the most communication-intensive components of the scheme. The reason that all these keys are needed is that the simulator in the main reduction must deal with each tick separately. However, you observe that there is no need to simulate everything. Give a forward pointer to the technical part, by saying that in the proof of Lemma 3 in Section 5 you show that if the simulator only simulates the "important" threads, then it is enough if the keys for the different ticks are t-wise independent (rather than completely independent) therefore getting polylog(k) bits per tick.

Here are a few other things to keep in mind while writing the introduction:

3   The technical parts

The thing to remember is to think of your readers while writing the technical parts. Below are a few specific considerations.

4   Summing up

I've already said all that I had to say, so let me just repeat it. To write clearly you must be clear about what you want to say, and you must keep thinking about your readers while writing your paper.


Last modified: Jan 3, 2006