All graduate students in CSAG should in the course of their studies write a number of technical research papers describing work they have done in the group. Succeeding in this process is an integral part of succeeding in getting the word out about your excellent research. Further, most researchers find that the writing process forces on them a clarity of thought and methodology which in turn improves the research. While there are many ways to do this, these notes summarize a process which is derived from experiences in writing over fifty such papers with a large number of different individuals involved. With only slight variations, the major features are all the same. Major steps of the process:
Step 1: Identify a Technical Paper Unit and Conference Target (2 to 9 months in advance)
Identifying a research element appropriate for a conference paper can happen early in the process (explicitly by design), or in the midst of other efforts, as an interesting phenomenon occurs. Its important to keep an eye out for this and identify likely opportunities as they come along. Identifying a conference target should be done proactively by identifying good meetings in your area, and keeping track of their submission, review, and meeting cycles. The further in advance both of these things can be done the better.
Step 2: High Level Design of the Study and Paper (2 months in advance)
At this point, the major results are beginning to shape up, and we are beginning to have confidence that there will be "enough there" to justify a good conference paper. At this point, it should be possible to talk about the following key issues for the paper:
In the cases of papers that involve quantitative studies, it will often be possible to flesh out all of the experiments and graphs, but not have the data to completely write the paper at this point. At this point, its good be make sure you understand all of the submission procedures (and attendant delays), as well as deadlines and extensions.
Step 3: Detailed Outline (partial to complete data in hand, 1 month in advance)
At this point, we are in the final push for completing the paper. Most researchers involved in this for the first time are astounded at how much work it takes to put together a good conference paper, but this is uniformly the case. The paper must be well written, polished, with clear and solid technical results if it is to be competitive at a good conference (where acceptance rates around 20% are now commonplace). At this point, we should be able to plan sections and section sizes for the paper. At this point, we construct a detailed outline, and detail the length of each section and subsection, as well as what will be described in each section. A typical conference paper organization and page budget are something like this:
I. Abstract (250 words)
- summarize key results tersely
II. Introduction (1 page)
- context, brief novelty, summarize results, overall paper structure
III. Background (1 page)
- any background needed to understand the work
IV. The Idea and Technical Description (2-4 pages)
- whats the key problem, approach, and the contributions
- important to give a top down description so the readers can understand quickly
V. Experimental Results (2-4 pages)
- metholodology and the studies we're going to present
- studies which support the key results
VI. Discussion and Related Work (1 page)
- discuss ramifications of results, and any particular strengths or weaknesses, narrownesses or breadth
- compare and contrast to other related results, focus on justifying the novelty or our work
VII. Summary and Future Work (0.5 page)
To see good models of this type of structure, see the numerous group publications on the web. The ones that fit this stylized form best are often the architecture papers published in ISCA or ASPLOS, and the programming system papers published in various places. Any of the top experimental conferences have numerous good examples.
The papers are usually written from the "inside out", that is sections III, IV, and V are usually written first. Thats because they follow most closely the precise technical work and results. After writing these well, the authors will have a better perspective on how to frame the work. The surrounding sections primary purpose is to put the work in context, summarize and reiterate the results beautifully. These are best written at the very end of the process.
Step 4: Improving the Writing and Results (1 week to 1 month)
After we have a first draft of the paper, each of the authors will go off and read copies carefully, and critique the paper. Then, we will meet to talk about the revisions needed and who should go at what. The main thing here is to not be personally attached to the writing, no matter how much work might have gone into it. If we are to succeed in writing the paper well under a deadline, the focus must be on continually pushing forward to understand what is wrong with the paper, and how it must be improved. Then executing on those attempts to improve it. This stage often requires three or four rounds of iteration and major rewrites, often involving numerous sleepless nights, so be sure to allow enough time for this process to converge. If the paper does not make it to a state where we can be proud to attach our names to it, we won't submit it.
Step 5: Update Group web pages and Bibliography File
As part of this activity, papers submitted will be acknowledged on the web pages in title, authorship, and indicated “submitted for publication”. This information will naturally be updated as the status of the paper changes.
In addition, as part of the paper writing process, you will doubtless create some additional bibliographic entries in our group database. The canonical form for this database is now EndNotes. You should check out a copy of the database from Perforce and update it with your additional entries, including one for this submitted paper. This will help you (and the group) in the future. Note that if you are a bibtex user, it is your responsibility to convert your entries to EndNotes and merge them into the shared group EndNotes library (conversion is easy with Tony’s tool, and merging and duplicate elimination is easy in EndNotes).