Writing Technical Paper
The title describes in a logical, rigorous, brief and grammatically sound way the essence of the paper. Sometimes it is made up of two parts, the title and a sub-title, separated by a colon.
Author and affiliation
The name of the author (or authors) is given below the title, followed by the indication of the institution to which the author belongs. The email address of the author is often also required.
State the problem, your approach and solution, and the main contributions of the paper. Include little if any background and motivation. Be factual but comprehensive. The material in the abstract should not be repeated later word for word in the paper.
To facilitate searching online for papers on a topic or set of topics, it is helpful if each paper includes a short list of the keywords, or index terms, that better describe these topics. If you chose a good selection of keywords, your paper will be more easily found on digital libraries and on the Web.
The Introduction is crucially important. By the time a referee has finished the Introduction, he's probably made an initial decision about whether to accept or reject the paper -- he'll read the rest of the paper looking for evidence to support his decision. A casual reader will continue on if the Introduction captivated him, and will set the paper aside otherwise. Again, the Introduction is crucially important.
The Introduction should consist of five paragraphs answering the following five questions:
- What is the problem?
- Why is it interesting and important?
- Why is it hard? (E.g., why do naive approaches fail?)
- Why hasn't it been solved before? (Or, what's wrong with previous proposed solutions? How does mine differ?)
- What are the key components of my approach and results? Also include any specific limitations.
The perennial question: Should related work be covered near the beginning of the paper or near the end?
- Beginning, if it can be short yet detailed enough, or if it's critical to take a strong defensive stance about previous work right away. In this case Related Work can be either a subsection at the end of the Introduction, or its own Section 2.
- End, if it can be summarized quickly early on (in the Introduction or Preliminaries), or if sufficient comparisons require the technical content of the paper. In this case Related Work should appear just before the Conclusions, possibly in a more general section "Discussion and Related Work".
Guideline #1: A clear new important technical contribution should have been articulated by the time the reader finishes page 3 (i.e., a quarter of the way through the paper).
Guideline #2: Every section of the paper should tell a story. (Don't, however, fall into the common trap of telling the entire story of how you arrived at your results. Just tell the story of the results themselves.) The story should be linear, keeping the reader engaged at every step and looking forward to the next step. There should be no significant interruptions -- those can go in the Appendix; see below.
Aside from these guidelines, which apply to every paper, the structure of the body varies a lot depending on content. Important components are:
- Running Example: When possible, use a running example throughout the paper. It can be introduced either as a subsection at the end of the Introduction, or its own Section 2 or 3 (depending on Related Work).
- Preliminaries: This section, which follows the Introduction and possibly Related Work and/or Running Example, sets up notation and terminology that is not part of the technical contribution. One important function of this section is to delineate material that's not original but is needed for the paper. Be concise -- remember the critical rule of thumb.
- Content: The meat of the paper includes algorithms, system descriptions, new language constructs, analyses, etc. Whenever possible use a "top-down" description: readers should be able to see where the material is going, and they should be able to skip ahead and still get the idea.
We could have an entire treatise on this topic alone and I am surely not the expert. Here are some random thoughts:
- What should performance experiments measure? Possiblities:
- Pure running time
- Sensitivity to important parameters
- Scalability in various aspects: data size, problem complexity, ...
- What should performance experiments show? Possibilities:
- Absolute performance (i.e., it's acceptable/usable)
- Relative performance to naive approaches
- Relative performance to previous approaches
- Relative performance among different proposed approaches
In general a short summarizing paragraph will do, and under no circumstances should the paragraph simply repeat material from the Abstract or Introduction. In some cases it's possible to now make the original claims more concrete, e.g., by referring to quantitative performance results.
Don't forget them or you'll have people with hurt feelings. Acknowledge anyone who contributed in any way: through discussions, feedback on drafts, implementation, etc. If in doubt about whether to include someone, include them.
The references correspond to the list of papers, book chapters, books, and other bibliographic elements that have been referenced throughout the paper. Various referencing guidelines exist, but you must use the guidelines of the journal or conference where you intend to publish.
When you write a research paper, you will have to borrow information from other people in order to prove your points. Any time you borrow information from another source, you must show in your paper where you found the information. This is called "citing" or "referencing." If you do not cite your source, it is called "plagiarism." It is illegal to plagiarize someone else's work or ideas.