Things you should not omit in the extended abstract include:

• Figures and tables showing relevant data, if available.
• References to related work.
• Complete outline of the finished paper.

In writing an extended abstract:

• Describe completed work, not work in progress. If you have ongoing development that might result in changes to the final paper, feel free to mention it in a note to the Program Committee (as described below), but the focus of your extended abstract should be on completed work.
• Concentrate on "why" rather than "what." Explain the logic behind a method, rather than just describing the method.
• Focus on and support a few selected conclusions, excluding details that do not support your central argument.

Do make sure to include just enough background for the reader to understand why your problem is important, how your work relates to previous work in the field, and how it might fit into a practical system or practice. Provide just enough detail for the reader to put your performance measurements or other technical evaluation in context. It is vitally important to provide a good bibliography, both so that you give proper credit to previous work, and so that a reader can know where to turn to find additional background information.

Saving Writing Time
Two steps can save you much time and effort if you do them before you begin writing:

• Survey the literature to determine whether there are similar approaches, perhaps beginning by asking someone who is familiar with the general system administration body of literature for good starting points.
• Ask yourself whether this work is relevant to a LISA conference.

Looking up references first can save you much time because you will be able to judge the likelihood of acceptance of the paper before writing the proposal. With references in hand, ask yourself several questions:

• Is the work new or novel? Has it not adequately been explored before in the way you intend?
• Is the work timely? Will it be of interest to LISA attendees?
• Does the work represent a substantial improvement to the practice of system administration?

Writing Notes to the Program Committee
Remember that you are not writing this submission for public consumption. The draft paper or extended abstract is for the Program Committee and their appointed readers only. It helps the Program Committee and readers greatly if you give us a brief overview of what you left out, other details you intend to include in the final paper, and potential differences between the submission and final paper, if any. Many authors prefer to typeset notes to the Program Committee in italics or square brackets, to distinguish them from the main flow of the text.

Submission Style
LISA attendees, readers, and the Program Committee need to understand your content as quickly and completely as possible. You should respect their time as readers when writing.

• Use simple and direct statements in present tense where feasible.
• Avoid long, multiple-clause sentences that are difficult to parse.
• Avoid split infinitives, dangling participles, and other grammar mistakes.
• Check spelling, punctuation, and URLs of Web resources.
• Test URLs, and make sure they will exist at the time of LISA. Maybe set up a reflector site where you can maintain the links, if they change.

Submission Checklists
Here are some checklists to use in determining whether your submission is ready to send to the LISA Program Committee. The checklist you use will differ slightly depending upon the kind of paper you are writing:

For a "typical" problem-oriented paper:

• Describe the problem to be solved and its importance. (Why should people be excited about reading your paper?)
• Sketch constraints of environment or operating policies. (What attributes of your problem are beyond your control?)
• Sketch options for solving the problem. (What other approaches have been tried?)
• Include relevant references to related work and resources. (Where can people learn more about other approaches?)
• Sketch your proposed solution, if applicable. (How do you solve the problem?)
• Describe the performance of solution, including functionality, limitations, robustness, efficiency, and ease of use, as applicable. (How well does your solution work? How do you know? What metrics did you use? What makes it robust?)
• Critically analyze differences between options for solving the problem. (How does your solution compare with others?)
• Explore the flaws and how they affect things.
• Include relevant figures and tables with captions. (What data do you have on the problem or its solution?)
• Explain figures and tables. (What conclusions do figures and tables support or suggest?)
• Describe your conclusions. (What did you learn?)
• Describe the availability of tools, if applicable. (How can people repeat your results?)
• Check for appropriate grammar and writing style.
• Look at the Call for Participation and make sure you meet any additional criteria listed there.
• Check spelling.
• Check URLs of Internet resources for validity.
• If you are submitting an extended abstract, include a full outline at the end.

• Describe the intent and importance of study. (Why should we be excited about reading your paper?)
• Sketch constraints of environment or operating policies. (What attributes of your site are beyond your control?)
• Sketch practices to be studied. (About what were you initially interested in learning?)
• Include relevant references to related work and other resources. (Where can one learn more about other studies or specifics of practices?)
• Sketch results of study. (What data do you have: either descriptions or numbers? Explain your metrics.)
• Include relevant figures and tables with captions. (What are the trends in your data?)
• Explain figures and tables. (What conclusions do figures and tables support or suggest?)
• Explain differences from accepted practice, if any. (What worked differently than expected?)
• Describe lessons learned. (What did you learn from the experience?)
• Check for appropriate grammar and writing style.
• Look at the Call for Participation and make sure you meet any additional criteria listed there.
• Check spelling.
• Check URLs of Internet resources for validity.
• If you are submitting an extended abstract, include a full outline at the end.

Author Resources
Several online resources exist to help you create a truly outstanding paper.

Appropriate references are very important to the Program Committee. To start determining where your work fits into the "big picture," browse Eric Anderson's 1999 LISA paper, "A Retrospective on Twelve Years of LISA Proceedings." Browse the "USENIX Compendium of Best Papers" (of which Anderson's paper is an example) for other LISA papers that have been given that award. Also browse the LISA Proceedings for the last three years to review the kinds of papers that have been accepted, as well as the current papers in your chosen topic. Researchers may find Mark Burgess' series in ;login: on research in system administration helpful: "System Administration Research I, II, and III." Mark also maintains a searchable System Administration bibliography which covers more than just LISA. It is a good idea to also search the Web for any related work. You may also ask the Program Chair for help with references by sending email to lisa08chair@usenix.org. Please note that the Program Committee and readers will be using these resources to evaluate your paper and will note any omissions in its reviews of your work.

References must be appropriate to the paper or issue. Do not refer to a complete book; point to the appropriate chapter or pages.

Simon Peyton-Jones has an excellent set of slides on writing a technical paper, which many people (both new and experienced) should find helpful (view PDF).

If your paper will include numerical results (a very good idea) you may find Margo Seltzer and Aaron Brown's 1997 invited talk "Measuring Computer Systems: How to Tell the Truth with Numbers" (view PostScript) helpful.

Submitting a Draft Paper or Extended Abstract
All submissions must be electronic and in ASCII or PDF format. Proposals submitted in other formats will not be reviewed or accepted.

Every submission must include:

• Paper title, and names, affiliations, and email addresses of all authors. Indicate each author who is a full-time student.
• The author who will be the contact for the Program Committee. Include his/her name, affiliation, paper mail address, daytime and evening phone numbers, email address, and fax number (as applicable).

Requirements for Accepted Papers
There are several requirements for papers accepted to the conference. Extended abstracts or draft papers determined to be in violation of these rules will not be accepted as papers. If the Program Committee or USENIX determines that your paper does not meet these requirements, it will be removed from the conference and Proceedings even if your draft paper or extended abstract has already been accepted by the Program Committee.

At least one author must attend the conference to present and defend each technical paper. One author per paper will receive a registration discount of $200. USENIX will offer a complimentary registration to the technical program upon request. Authors who are full-time students may apply for financial support to attend the conference via the USENIX Student Grant Program.

The paper (or the extended abstract describing the paper) must not be submitted simultaneously to any other conference or publication without prior permission of the Program Chair. The paper must not have been published previously. It must not be published elsewhere for a year from the date of acceptance by USENIX.

The authors of each final paper (and copyright holder, if different) must assign limited publication rights to USENIX before publication and must certify that they are allowed legally to assign these rights. This includes assigning USENIX the sole right to publish the paper for one year from date of acceptance. The paper can be posted on a personal Web site after the conclusion of the conference.

Authors of a paper are responsible for ensuring that the paper is appropriate for public dissemination and that it is legal to publish the paper as a public document. Papers containing proprietary intellectual property, including information protected by employment contracts or nondisclosure agreements, are not suitable for publication.

The Review Process
After you submit your draft paper or extended abstract, it will be assigned to several readers for review. Readers are volunteer reviewers, both on and outside the Program Committee. Each reader will read your submission carefully and rate it on several criteria:

• Relevance: Is the paper appropriate for the USENIX/LISA conference?
• Interest level: Is the presentation likely to interest enough attendees to merit inclusion?
• Originality: Does the paper provide new insights not available elsewhere in the literature?
• Presentation: Is the paper readable? Is the final paper likely to be well written? Is the conference presentation likely to be understandable?
• Technical Quality: Is the work technically correct? Does the work reflect good science, engineering, or other quality factors?
• References: Are there sufficient and relevant references to related resources to aid the reader in placing the paper in a larger context?

In the case of extended abstracts, it is important to remember that although the Program Committee will have received an extended abstract from you, the Program Committee members and readers will actually be trying to determine:

• Whether the final paper will have enduring value in the Conference Proceedings.
• Whether the final paper will result in an interesting talk at the conference.

In the next step, all submissions will be reviewed by the Program Committee, using the readers' ratings and comments as guidance. The Program Committee will append its own comments and return the reviews to you, together with a notice of either acceptance or rejection. In the case of an acceptance, you will be given further detailed instructions on how to prepare your final paper for inclusion in the proceedings.

Draft Papers and Extended Abstracts We Will Not Read
There are cases in which the Program Committee may refuse to read a submission.

The Program Committee only accepts submissions submitted by the original authors. Proposals submitted by third parties, authorized or not, will be returned unread. Proposals submitted anonymously will be returned unread. Proposals accompanied by nondisclosure agreements will be presumed to contain unacceptable conference content and will be returned unread.

Each proposal may be read by a potentially large number of readers during the review process. Thus, a submitted proposal must be suitable for public dissemination. By submitting a proposal, authors assert that they have permission to disseminate the contents publicly. Proposals that are determined (by any method) to contain proprietary information unsuitable for public dissemination will be returned unreviewed (and if possible, unread).

Draft Papers and Extended Abstracts We Tend Not to Accept
After describing what makes a great paper, it is time to describe what kinds of papers (in general) do not make a good LISA papers. Over the years, some kinds of papers have proven less useful than others to our audience. We are unlikely to accept more of these, but in each case there is a straightforward way to write an acceptable paper instead.

We do not tend to accept papers that are simply "user manuals" for new tools. We are interested in the situations, assumptions, policies, and principles that affect the architecture of the tool or product, as well as the tool or product's performance in comparison with other solutions. These facets of the paper have enduring value as a "reproducible experiment," while the user manual (or product literature) is likely to be outdated in the immediate future. Papers which can draw general conclusions contributing to "the big picture" are most welcome.

Papers describing experiences gained using different software systems are valuable, provided they make fair comparisons. For instance, a paper describing the wondrous features of tool X would probably not be as interesting as a paper comparing and detailing the utility of tool X versus tool Y. An impartial paper comparing all of the key tools that solve a similar problem would be more interesting still.

We do not tend to accept papers with no discernible conclusions or lessons. An acceptable paper must have some kind of "lessons learned," but this conclusion can detail what does not work, especially when this claim contrasts with conventional wisdom.

For those authors who are not system administrators, think about whether a LISA conference is the proper place to publish your paper. Perhaps it belongs in a more specialized conference or a conference with a different kind of focus. For example, we encourage theory papers with a system administration focus. Papers—theoretical or not—that do not have a system administration focus should be submitted to another conference, such as the USENIX Annual Technical Conference. Try asking the systems administrators at your site—or at other sites—if they would find the paper interesting.

For More Information
If you have any other questions at any time during the entire submissions process, please send email to the Program Chair at lisa08chair@usenix.org.

Next page