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 cannot accept every paper submitted to the conference.
Generally speaking, we are looking for papers that span a broad range of practical issues in the administration and integration of Windows NT in large heterogeneous environments. However, please don't choose not to submit your paper because you think that it will not "fit" the LISA NT conference format. Some of the best papers are papers that are unusual and definitely not "traditional".
The key element of a good paper is that it teaches the readers something that they can use when doing system administration or developing tools to do system administration.
The LISA conference will be held in Seattle, August 5-7, 1998. The technical sessions will be held Thursday and Friday, August 6th and 7th.
Dates for paper submissions:
THE CALL FOR PARTICIPATION
For your convenience, here is a summary of the important information in the Call For Participation:
We seek papers relating work of general interest to system administrators of Windows NT, particularly technical papers that reflect hands-on experience or describe implementable solutions.
Submissions will be judged on the quality of the written submission and whether or not the work advances the art and science of NT system administration.
A paper submission should:
If you have a completed paper, you may submit it instead of the abstract and outline.
Please see the detailed author instructions and a sample abstract.
Authors of an accepted paper must provide a final paper for publication in the conference proceedings. At least one author of each accepted paper will present the paper during the technical track of the conference. We also ask that, if possible, copies of presentation slides be made available for publication.
Conference proceedings containing all refereed papers will be distributed to attendees and will also be available from USENIX once the conference ends.
Note that the USENIX organisation, as well as most conferences and journals, requires that papers be "unique", i.e., not be submitted to more than one conference or publication. All submissions are held in the strictest confidence prior to publication in the conference proceedings, both as a matter of policy and as protected by the U.S. Copyright Act of 1976.
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 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 works; it may be good work but if there is nothing new to learn, it isn't worth reading (or writing) a paper about it. Think about how other people might find your work useful; can they apply what you are teaching them to their own systems? And, does your work really improve upon the previous state of the art? Or does it show how other people have been confused? "Negative results" that contradict the conventional wisdom are often more important than positive results.
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 favour papers where the author appears to be familiar with the current literature.
The Program Committee will also be trying to decide if papers will lead to a good 25-minute presentation. Some papers are just too complex to be presented this way (perhaps you should focus on just one aspect); other papers just don't have enough to talk about for that long. On the other hand, a few rare papers are accepted mostly because the committee expects them to produce an interesting talk, but that might not otherwise merit publication.
WHAT DO WE MEAN BY ABSTRACT?
An "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 abstract as a sample of your ability to write clearly about your topic, to organise your paper, and to convey sufficient information to the readers.
When you write an abstract, you are explicitly leaving things out of the paper without making it hard for the program committee to judge the paper. 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!
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.Finally, if a sample abstract would help, you can get a copy of the (extended) abstract and postscript copy of the final paper that Matt Blaze did for the Winter 1992 USENIX conference (pp. 333-343). The abstract is probably most useful when compared with the final paper. Please note that the sample abstract is an "extended abstract" and is somewhat more substantial than the one or two page abstract submissions required for LISA NT '98.
HOW AND WHERE TO SEND SUBMISSIONS
Please e-mail your submission to email@example.com in any one of the following formats:
A cover letter with the following required information in the format below must be included with all submissions:
Authors: Names and affiliation of all authors Contact: Primary contact for the submission Address: Contact's full postal address Phone: Contact's telephone number Fax: Contact's fax number E-mail: Contact's e-mail address URL: For all speaker/authors (if available) Category: Category of the submission (paper, invited talk, panel, WIP) Title: Title of the submission Needs: Audio-visual requirements for presentation
If you enclose files as an attachment to your submission, please use MIME encoding.
We will acknowledge receipt of a submission by e-mail within one week.
MORE INFORMATION IS AVAILABLE
Lots of papers and books have been written about how to write a good paper. We'd like to suggest that you read a paper called An Evaluation of the Ninth SOSP Submissions; or, How (and How Not) to Write a Good Systems Paper. This was written by Roy Levin and David D. Redell, the program committee co-chairs for SOSP-9, and first appeared in ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July, 1983), pages 35-40.
Although SOSP and USENIX papers do differ somewhat (SOSP submissions are often more theoretical, and are reviewed based on full papers rather than abstracts), they give good advice for authors of any kind of systems paper.
The authors have graciously agreed to make this paper available online. You can also retrieve a separate copy by sending email to firstname.lastname@example.org, including the line: send advice papers in the body of your email.
Another helpful paper is "The Science of Scientific Writing," George D. Gopen and Judith A. Swan, American Scientist, Vol. 78, No. 6 (Nov-Dec, 1990), pp. 550-558.
This article describes not how to write an entire paper, but how to write sentences and paragraphs that readers can understand. Unfortunately, due to copyright restrictions we cannot make this available online or send you photocopies, but almost any library should have copies of this magazine.
We also recommend that you read the proceedings of some recent USENIX conferences to get an idea of what kinds of papers are published. Not every one of these papers is perfect (or even great), but most of them are better than most of the ones that got rejected.
Finally, if you have any other questions, feel free to send mail to the Program Chairs at email@example.com.
The LISA NT '98 Program Committee
Need help? Use our Contacts page.
Last changed: Oct 10, 1997 jackson