Sponsored by the USENIX Association
Co-sponsored by SAGE, the System Administrators Guild

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.) Generally speaking, we are looking for papers that span a broad range of practical issues in the administration of Open Systems. However, please don't choose not to submit your paper because you think that it will not "fit" the LISA conference format. Some of the best papers of the past conferences have been papers that were 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. CONFERENCE DATES: The LISA conference will be held in Boston, MA, December 6-11, 1998. The technical sessions will be held Wednesday through Friday, December 9-11. Dates for paper submissions: Extended Abstracts Due: June 23, 1998 Invited Talks Proposals Due: June 23, 1998 Notification to authors: July 21, 1998 Camera-ready papers due: October 16, 1998 Registration materials available August, 1998 THE CALL FOR PAPERS: For your convenience, here is a summary of the important information in the Call For Papers: Authors must submit an extended abstract which should consist of a traditional abstract which summarizes the content/ideas of the entire paper, followed by a skeletal outline of the full paper. THE NEXT STEP IS VERY IMPORTANT. PLEASE READ CAREFULLY. All submissions must include an additional, detached page (if the manuscript is printed) or a separate E-mail message (if the manuscript is submitted electronically) listing: The title and authors of the manuscript. The name of one author who will serve as a contact, with regular and electronic mail addresses, daytime and evening telephone numbers, and a fax number. An indication of which, if any, of the authors are full-time students. One copy of the manuscript must be submitted by at least TWO of the following methods. Email to lisa98papers@usenix.org. Surface mail to: LISA '98 Conference USENIX Association 2560 Ninth Street, Suite 215 Berkeley, CA 94710 U.S.A. Fax to: 510-548-5738 The final paper should be at least 8 but no more than 20 pages in length. Cash prizes will be awarded for Best Paper and Best Student Paper. 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 papers; 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. Trying to decide if something is non-obvious isn't easy (patent lawyers make lots of money arguing about this), and sometimes the best ideas seem obvious in hindsight; but if lots of people have done the same thing, and you are simply the first person to have considered writing a paper about it, perhaps it's too obvious. 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. Or perhaps it doesn't belong in a conference at all; it might be more appropriate for the USENIX newsletter ;login:. 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. Again, 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. But 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 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. 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. 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. Finally, if a sample abstract would help, you can get a copy of the abstract and postscript copy of the final paper that Matt Blaze did for the Winter 1992 USENIX Conference (pp. 333-343). You can also get a copy of the paper by sending email to info@usenix.org, with the line send paper papers in the body of your email. HOW SHOULD I GET MY MANUSCRIPT TO YOU? The Program Committee would prefer to receive submissions via electronic mail, but there are occasionally problems in printing them. That is the main reason why we also insist on either a printed or faxed copy of your submission. (Normally, faxes are much harder to read, and lead to grumpy reviewers.) First, we can use the printed copy to make sure we printed your on-line version properly. Second, and more important, if we cannot print the on-line version, we have the other copy as a backup. If you have any reason to suspect that your submission might not be easy for us to print, please submit an already printed hardcopy by surface mail, in addition to your email. Submissions that arrive via fax are often very hard to read. We accept fax only to avoid accidentally losing a paper. Submissions via email can be made in several formats. Flat text files are always easy to print, but if you have any figures or graphics this probably won't work. If you do use flat text, please remember to format it neatly and keep lines under 80 columns in width. We can accept troff, Tex, or Latex input files but ONLY, ONLY, ONLY if they use standard macro packages, or, you've included a copy of the macro package in the document. Always include specific instructions for converting your input file to a printed version. For example, if the program must first be run through any of the standard preprocessors, tell us! Also, if you send TeX dvi format, remember to uuencode it before putting it into your email message! PostScript files are usually the best format, BUT some PostScript generators are quite buggy and we may not be able to print their output. For example, lots of software generates PostScript that can only be printed on Apple Laserwriters. If you send PostScript, remember the following: Use only the most basic of fonts (TimesRoman, Helvetica, Courier). Other fonts are often not available with every printer or previewer. PostScript that requires some special prolog to be loaded into the printer won't work for us. Don't send it. If you used a PC or Macintosh-based word processor to generate your PostScript, print it on a more generic PostScript printer before sending it, to make absolutely sure that the PostScript is portable. DON'T send files meant for various word-processing packages (Word, WordPerfect, MacWrite, etc.). We don't have the resources to deal with them. Since electronic mail systems have been known to mangle mail, it is always a good idea to wrap up your submission using shar(1), cpio(1), or tar(1). Note, if you use cpio or tar, or, if your email contains any non-printing characters, use uuencode(1) to convert your email to pure ASCII characters. If the paper you submit via email is missing illustrations that are present in your hardcopy or fax submission, please indicate this with a prominent note. Overseas authors should make sure that their abstract prints properly on US-style 8.5x11 inch paper. Please make sure that you leave enough room for top and bottom margins. 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 extended 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 info@usenix.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 Chair at lisa98chairs@usenix.org. Good Luck, The Program Committee

Need help? Use our Contacts page. First posted: Apr 20, 1998 jackson Last changed: Apr 20, 1998 jackson

USENIX home