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.)
The key element of a good paper is that it either teaches the readers something that they can use when doing system administration or developing tools to do system administration, or it advances the science of system administration, or both. If you have any questions about whether your paper is appropriate, please contact firstname.lastname@example.org.
The LISA conference will be held in Seattle, WA, November 7-12, 1999. The technical sessions will be held Wednesday through Friday, November 10-12.Dates for paper submissions:
THE CALL FOR PAPERS:For your convenience, here is a summary of the important information in the Call For Papers:
WHAT KINDS OF PAPERS DOES USENIX PUBLISH?
The most important thought to keep in mind when deciding whether to submit a paper is "what will the audience or readers learn from my paper?" We don't expect every tool-related paper to report on a major breakthrough, but we do look for something new, potentially useful, and not entirely obvious. 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. Think about how other people might find your work useful; can they apply what you are teaching them to their own systems or environments? Or does it show how other people have been confused? "Negative results" that contradict the conventional wisdom are often more important than positive results, especially in case studies.
Also think about whether a LISA conference is the right place to publish your paper. Perhaps it belongs in a more theoretical conference, or a conference with a different kind of focus. We encourage theory papers with a SA focus. Papers, theoretical or otherwise, that do not have a SA focus should 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 would be very short or 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.
When you are writing your paper, keep in mind "what do I intend to teach the reader?" That means keeping the paper focused on one or a few main points. Don't try to cram too many big issues into the paper, and don't fill it up with irrelevant details. 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 look kindly on 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/. If you have questions, feel free to ask the Program Committee.
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.
MORE INFORMATION ON HOW TO WRITE A GOOD PAPER:
We recommend that you read the proceedings of some recent LISA conferences to get an idea of what kinds of papers are published. Not every one of these papers is perfect, but most of them are better than most of the papers that did not get accepted. A few papers to consider are:
You can also refer to the "USENIX Online Library and Index" (at https://www.usenix.org/publications/library/index.html) for additional papers that may be of use.
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 at email@example.com.
Need help? Use our Contacts page.
First posted: 16 Feb 1999 jr
Last changed: 19 Feb 1999 jr