[Back to LISA Call for Papers]

Table of Contents
Introduction LISA Authors LISA Attendees Short and Long Talks The Extended Abstract Outline Required Saving Writing Time Planning an Abstract Abstract Style Writing an Abstract		Writing Notes to the Program Committee Submission Checklists Author Resources Submitting an Abstract Requirements for Accepted Papers The Review Process Abstracts We Will Not Read Abstracts We Do Not Tend to Accept For More Information

Introduction
Welcome, potential LISA author! This page is provided to give you the optimum chance to get your paper accepted to LISA. It lays out what we expect of an abstract and paper, as well as a suggested process for writing the paper and a list of resources for authors.

Writing a refereed paper for LISA is a rewarding challenge. By writing a LISA paper you have the ability to affect the thinking and practice of thousands of your colleagues, both at the conference and afterward when your paper becomes part of the LISA Proceedings as a permanent record of your work.

You'll not only be standing on the shoulders of giants but potentially becoming a giant yourself. Sharing our results grows the field and accelerates the evolution of system administration.

Regrettably, there are not enough presentation slots at the conference for the Program Committee to accept every paper submitted. We expect to accept between 25 and 35 papers which historically is about one in three papers submitted. The process is somewhat competitive and over time we have developed relatively high standards for the papers we accept.

LISA Authors
LISA authors are a very diverse population. Authors include students without work experience, practitioners learning the discipline, practitioners with years of experience, and academic researchers expanding the theoretical foundations of the discipline. Authors have been as young as 18 years old. Author credentials range from High School students to Ph.D's. LISA welcomes contributions from outside the USA by authors authorized and able to travel to the United States for the Conference. All these kinds of authors have one common attribute: a "good idea" that improves the art, science, and/or profession of system administration.

Writing a great LISA paper is somewhat like writing any literature: you should "write about what you know". What makes your work easier? What surprising conclusions can you support from your work? What neat tool or trick have you developed to save yourself time? What recent work experience (case study) changed the way you work? What do you wish to share with others in your profession? If you have a clear vision of your topic at this time, that's fine. If not, don't sweat it — look for a way of explaining your topic in the context of other work.

LISA Attendees
Your audience — LISA attendees — is as diverse as the authors; some of the best authors are prior attendees. Perhaps the greatest challenge in writing a LISA paper is to make it interesting to experts in the field while also being approachable and understandable by as much of the audience as is reasonable. These seemingly conflicting goals can often be achieved by focusing your paper on how your work fits into the "big picture" with details to support where it fits. There are of course exceptions to this ideal; some advanced topics cannot reasonably be made approachable within the length limits. In any case it is polite to refer less expert readers to appropriate resources they can use to understand the paper.

Short and Long Talks
Although there is only one kind of refereed paper, there are two lengths of presentations of refereed papers at this year's conference. Authors presenting a long talk are allotted 30 minutes total time, typically divided into 25 minutes for presentation and 5 minutes for questions. Authors presenting a short talk are allotted 20 minutes total, typically divided into 15 minutes for presentation and 5 minutes for questions. Authors will be informed about which kind of talk to prepare when their papers are accepted. The designation of "short talk" or "long talk" does not affect the length limit of the printed paper, which is 16 pages for either kind of paper.

Papers presented in short and long talks are considered equally for the "best paper" awards. The presentation time your paper receives does not imply any difference in the quality of the described work. The Program Committee assigns "short talk" slots to great ideas that they judge to be relatively straightforward to describe to our audience. Likewise, "long talk" slots will be assigned to papers that the Program Committee thinks might be more complex to describe and discuss, thus requiring more presentation time at the conference. Some of the best ideas to come out of prior LISAs are novel approaches whose application is simple and straightforward. We utilize "short talks" in an attempt to include more of the excellent ideas that our conference has become known for highlighting over the years.

The Extended Abstract
Potential Technical Program authors must submit an extended abstract of 500-1500 words (not counting figures and references) to the Program Committee for review. Full papers are unnecessary at this stage — if you send a full paper you must also include an extended abstract. The abstract should include appropriate references to establish the relationship between your work and that of others and, where possible, provide detailed data to establish that you have a working implementation or measurement tool.

We choose to review extended abstracts because we try to maximize the number of people who read each submission. Abstracts tend to be considerably more condensed than the final paper and this enables us to do a far more equitable comparison.

The length of an abstract may seem short, but its information density may make it time-consuming to write. Start early enough to allow enough time for writing multiple revisions of the abstract, at least one month in advance of the due date (20 April, 2004). Great abstracts are not simply written, but rewritten in reaction to feedback from several readers. Make sure to have several other system administrators as well as managers, theorists, and others in your target audience read the abstract and remark upon any lack of clarity they find. This means starting enough in advance of the due date to give them time to read your abstract and make comments.

Contact the Program Chair at lisa04chair@usenix.org if you would like to have your abstract reviewed by volunteer (non-binding) reviewers before you submit it.

Outline Required
In past years we have asked for, but not required, an outline of the finished paper. This year the outline is a requirement. It should show the gist of the paper outlining chapter/section and relevant structure that you will use in your finished paper. Keep it broad and general. It should probably be no more than 40-50 lines, though 20-30 is usual.

Saving Writing Time
Two steps can save you much time and effort if done 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.

• For a "typical" problem-oriented paper:
  • Describe problem to be solved and its importance. (Why should one 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 one learn more about other approaches?)
  • Refer to references where appropriate in abstract. (Where can one learn more about a specific approach?)
  • 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 effect things.
  • Include relevant figures and tables with captions. (What data do you have on the problem or its solution?)
  • Explain figures and tables in abstract. (What conclusions do figures and tables support or suggest?)
  • Describe conclusions of study. (What did you learn?)
  • Describe availability of tools, if applicable. (How can one repeat your results?)
  • Check for appropriate grammar and writing style.
  • Look at the Call For Proposals and make sure you meet any additional criteria listed there.
  • Check spelling.
  • Check URLs of Internet resources for validity.
  • Include a full outline at the end.

• For a "typical" problem-oriented paper:
  • Describe 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?)
  • Refer to references where appropriate in abstract. (Where can one learn more about a specific study or practice?)
  • 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 in abstract. (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 Proposals and make sure you meet any additional criteria listed there.
  • Check spelling.
  • Check URLs of Internet resources for validity.
  • Include a full outline at the end.

  These are only two examples. Every paper is different, and your own checklist may differ slightly from these examples.

  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 should read Mark Burgess' series in ;login: on research in system administration: "System administration research I (https://www.iu.hio.no/SystemAdmin/res1.html), II (https://www.iu.hio.no/SystemAdmin/res2.html), and III (https://www.iu.hio.no/SystemAdmin/res3.html)." 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 email to lisa04chair@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.

  If your paper will include numerical results (a very good idea) then take a look at Margo Seltzer and Aaron Brown's recent paper "Measuring Computer Systems: How to Tell the Truth with Numbers" (view PostScript).

  Submitting an Abstract
  All abstract submissions must be electronic, in ASCII, PDF, or PostScript format. Papers submitted in other formats will not be reviewed or accepted.

  Please use the online submission form to submit an abstract to LISA '04.

  • Paper title and authors (indicating any authors who are full time students).
  • Planned presenter of the paper at the conference.
  • Whether the paper should be considered as a "student paper" or "regular paper" when deliberating upon awards. The primary (first) author and the planned presenter of the paper at the Conference must be students in order to qualify for a "best student paper" award.
  • For the author who will act as the contact to the program committee, his or her name, paper mail address, daytime and evening phone numbers, e-mail address, and fax number, if available. This person is usually the same person as the presenter.

  Requirements for Accepted Papers
  There are several requirements for papers accepted to the conference. Abstracts 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 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 will receive free admission to the Technical Program of the Conference. Authors who are full-time students may apply for financial support to attend the conference via the USENIX Student Stipend Program.

  The paper (as well as the abstract describing the paper) must not be submitted simultaneously to any other conference or publication. 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 non-disclosure agreements, are not suitable for publication.

  The Review Process
  After you submit your 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 abstract carefully and rate the abstract 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?

  Readers are expected to provide detailed comments to explain their ratings.

  In the next step, all abstracts 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.

  It is important to remember that although the Program Committee will be receiving 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.

  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 information to readers. This also means that solo outlines (without an abstract), copies of presentation slides, or very short abstracts are quite unlikely to be accepted.

  Abstracts We Will Not Read
  There are cases in which the Program Committee may refuse to read an abstract.

  The Program Committee only accepts abstracts submitted by the original authors. Abstracts submitted by third parties, authorized or not, will be returned unread. Abstracts submitted anonymously will be returned unread. Abstracts accompanied by non-disclosure agreements will be presumed to contain unacceptable conference content and will be returned unread. Abstracts that are copyrighted will also be returned unread, unless the authors grant explicit permission to the Program Committee, SAGE, and USENIX to copy them for the purposes of review, because we have no idea how to honor restrictions imposed by a copyright both properly and efficiently during the review process.

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

  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. For the same reason, we do not tend to accept abstracts that contain only promotional materials for products. 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 non-sysadmin authors, 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 lisa04chair@usenix.org.