Please read these guidelines carefully. They are written to help you give your submission its best possible chance to be accepted. (As you know, the Program Committee can't accept every paper submitted to the conference.) If you have any questions about whether your paper is appropriate, please contact lisa01chair@usenix.org. Before submitting your paper, ask yourself:

• Relevance -- is the paper appropriate for the USENIX/LISA conference?
• Presentation -- is the paper readable?
• Quality -- does the work reflect good science/engineering?
• References -- are there sufficient and relevant references to place the paper in a larger context?
• Advancement -- does the paper advance the state of the field?

• A Retrospective on Twelve Years of LISA Proceedings

• System administration research I, II and III.

• Measuring Computer Systems: How to Tell the Truth with Numbers (PostScript)
  Margo Seltzer and Aaron Brown.

What Kinds Of Papers Does Usenix Publish?

LISA has traditionally seen many papers about home-grown scripts and solutions. Custom solution papers need to illustrate a particular principle which can be applied generally and the main focus of this kind of paper should be the principles not the implementation. Papers which can draw general conclusions contributing to 'the big picture' are most welcome.

In general, when deciding whether to submit a paper, ask yourself: what will the audience and readers learn from my paper? Will anyone want to read it again in five years' time?

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 not be acceptable, but a paper comparing and detailing the utility of tool X versus tool Y, say, would be more interesting. An impartial paper comparing all of the key tools which solve a similar problem would be more interesting still.

In short, the more generally applicable your paper is, the more it says about the field of system administration and the more interesting it is. You should think about how different your work is from previously published papers; it may be good work but it should also be an improvement over the previously published work. Negative results, i.e. papers which demonstrate common misconceptions or question previously published 'truths' are sometimes more important than positive results, especially in case studies where they can demolish conventional wisdom. Papers which are inconclusive are usually not accepted, since they do not usually advance the state of the field.

Think about whether a LISA conference is the right place to publish your paper. Perhaps it belongs in a more specialized conference, or a conference with a different kind of focus. We encourage theory papers with a system admin focus. Papers, theoretical or otherwise, that do not have a system administration focus should probably be submitted to the USENIX General Technical Conference. Try asking the systems administrators at your site -- or at other sites -- if they would find the paper interesting. If your paper is more of an opinion piece, it might be more appropriate for the USENIX newsletter ;login:. Also try asking if they would find the paper interesting, and try asking them to identify the most important aspects of your paper.

Papers should be focused on one or perhaps a few main points. Don't try to cram too many issues into the paper, and don't fill it up with irrelevant details. Every paper has an ideal length for the idea is conveys. If that is short, so be it. Clarity should be your primary goal.

Do include 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. Also, provide 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. The Program Committee will not accept a paper if the author doesn't appear to be familiar with the current literature. A complete list of papers previously published by USENIX is available at https://www.usenix.org/publications/library/. A searchable bibliography, which covers more than just LISA can be found at Oslo University College

Finally, if you have any other questions, at any time during the entire submissions process, especially if you have a paper idea but have concerns about it not being right for the conference, PLEASE send mail to the Program Chair (Mark) at lisa2001chair@usenix.org.

What Do We Mean By Extended Abstract?

An "extended abstract" might better be thought of as a "condensed paper." The Program Committee will be trying to evaluate your final paper, not merely whether the work you are reporting on is good. This means that we will view the extended abstract as a sample of your ability to write clearly about your topic, to organize your paper, and to convey sufficient information to the readers. This also means that outlines, copies of presentation slides, or 1-page abstracts are quite unlikely to be accepted. In addition, the Program Committee will also try to judge if the final paper will lead to a good 25 minute talk.

When you write an extended abstract, you are explicitly leaving things out of the paper. Each time you do that, ask yourself, "Will it make it hard for the Program Committee to judge my paper?" There are no easy rules to follow here: something that might be vital in judging the value of one paper would be irrelevant detail in another case. It's best to leave out things that take a lot of explanation but are not central to the main point of the paper. You might also leave out descriptions of variations on, or extensions to, the main concepts. Don't leave out references to related work, but you can probably reduce this part to an explanation pitched to the Program Committee, rather than an "introduction to the field" written for the benefit of a non-expert reader. Include graphs, figures, and tables that are central to understanding the paper! We don't count these against the 5-page limit, because they make an extended abstract easier to read. Try to design figures that can be understood without lots of explanatory text.

Also, it's perfectly okay to write notes to the Program Committee in your abstract! Tell them why you left something out, if a section may be fundamentally changed in the final paper, or similar comments that will help them better understand your abstract.