Check out the new USENIX Web site.


Contents

 LISA '07 Home
 Conference Overview
 Important Dates/Contact Information
 Conference Organizers
 Refereed Papers
 Training Program
 Invited Talks and Guru Sessions
 Workshops, Posters, WiPs, and BoFs
 Possible Topics for Authors and Speakers
 Sponsorship and Exhibit Opportunities

Call for Papers
in PDF Format

LISA '07 Call for Papers

GUIDELINES FOR AUTHORS

Table of Contents
Introduction
LISA Authors
LISA Attendees
Choose a Proposal Format
The Draft Paper
The Extended Abstract
Planning an Extended Abstract
Writing an Extended Abstract
Saving Writing Time
Writing Notes to the Program Committee
Submission Style
Submission Checklists
Author Resources
Submitting a Draft Paper or Extended Abstract
Requirements for Accepted Papers
The Review Process
Draft Papers and Extended Abstracts We Will Not Read
Draft Papers and Extended Abstracts We Tend Not 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 draft papers, extended abstracts, and final papers, as well as a suggested process for writing them and a list of resources for authors. The amount of information here is intended to be helpful to you; don't be daunted by its size. We've attempted to include as much assistance with the writing/submission process for first-time authors as we can. If you have any questions about these guidelines, please feel free to send email to the Program Chair at lisa07chair@usenix.org.

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 of your colleagues in the field, both at the conference and afterward when your paper becomes part of the LISA Proceedings as a permanent record of your work. Sharing the results of your work or research helps the field to grow 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. Papers have been accepted from authors as young as 18, and from authors at every educational level from high school students to university professors. LISA welcomes contributions from outside the United States 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 are looking for inspiration, the program committee has produced a list of some open questions and research areas. We'd love to see good papers written about any of these subjects or other new and interesting 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 occasional exceptions to this ideal; some advanced topics cannot reasonably be made approachable within the length limits. In these cases it is polite to refer less expert readers to appropriate resources they can use to understand the paper.

Choose a Proposal Format
This year we are allowing two submissions formats for paper proposals: draft paper and extended abstract. A draft paper is a near-to-final draft of a full paper submission. Though it may undergo some editing in response to the review process, it is substantially complete. An extended abstract is a condensed version of a paper with enough information and detail to allow a reviewer to determine the organization, writing style, and contents of a final paper.

The Program Committee prefers to receive draft papers instead of extended abstracts because they allow us to more accurately judge the end result of a proposal. That being said, we do recognize that many LISA authors are busy practitioners who don't have the opportunity to complete draft papers by the submission deadline or whose proposed work isn't complete yet, so we will also accept the shorter format.

The Draft Paper
A draft paper, like a final paper, is limited to 16 pages, including all illustrations, figures, tables, and references. It should be substantially complete and correct; while there may be sections waiting for final data to arrive and things you intend to perfect before publication, it needs to be a good representation of the final paper in both content and quality.

Though it may seem a bit counter-intuitive, writing and submitting a draft paper can often be easier and less time-consuming than writing and submitting an extended abstract. Both submission formats require you to plan the structure and content of a final paper and to present this information in a form that can be judged by the Program Committee. If you write a draft paper, your writing time will be spent expressing the information in a form close to that of the final product.

If you write an extended abstract, you'll spend that post-planning time instead doing the (non-trivial) work of condensing the description of your ideas. Should this extended abstract submission be accepted, you will at that point still need to go through the writing process to create a draft and then final paper. Submitting a draft paper can save authors the extra step of condensing—another reason for the Program Committee's preference for the draft paper format.

The Extended Abstract
Extended abstracts must be at least 500 words, not counting figures and references. Generally an extended abstract is around 1000–1500 words (about 5–6 pages), but the Program Committtee will accept one that is longer. The extended 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. Each extended abstract must contain an outline that shows the gist of the paper. The outline should show the structure of sections and subsections 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.

The extended abstract may seem short, but good extended abstracts are time-consuming to write, precisely because they need to fit a lot into not very much space. Start early enough to allow time for writing multiple revisions of the extended abstract; that means at least one month in advance of the due date (May 14, 2007). Great extended 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 extended abstract and remark upon any lack of clarity they find. Because you are familiar with your topic, it is extremely difficult for you to judge which parts will be difficult for other readers.

Planning an Extended Abstract
One way to write a good extended abstract is to outline the contents of the whole paper before writing the abstract. Show this outline to colleagues and solicit feedback on its appropriateness before beginning to write the abstract. If in doubt about how to transform a section of the outline into a section of the extended abstract, write a draft of the corresponding paper section, and then try to condense it.

Writing an Extended Abstract
The extended abstract should really be a "condensed paper." It should convey the full scope of the paper while leaving out some of the details for brevity. Leaving out details in the extended abstract is, alas, somewhat of an art. Obvious targets for omission include:

  • Details that can be omitted without destroying the overall flow of the document.
  • Detailed discussions of relatively unimportant facets of the work.
  • Details covered by online resources that you can reference (such as user manuals).
Each time you leave something out, ask yourself whether its omission will make it more difficult for the Program Committee to understand your extended abstract. Try to leave out the least needed details.

Things you should not omit in the extended abstract include:

  • Figures and tables showing relevant data, if available.
  • References to related work.
  • Complete outline of the finished paper.
Please remember to explain figures and (if not obvious) the relevance of references in the extended abstract text. In the absence of figures or tables, please describe any performance data in the text of the abstract. If you're running short of words, it's time for a table!

In writing an extended abstract:

  • Describe completed work, not work in progress. If you have ongoing development that might result in changes to the final paper, feel free to mention it in a note to the Program Committee (as described below), but the focus of your extended abstract should be on completed work.
  • Concentrate on "why" rather than "what." Explain the logic behind a method, rather than just describing the method.
  • Focus on and support a few selected conclusions, excluding details that do not support your central argument.
Extended abstracts and their corresponding papers should be focused on one or perhaps a few main points. Do not try to cram too many issues into the paper, and do not fill it up with irrelevant details. If there is a second paper's worth of issues you could mention, consider submitting two proposals. Every paper has an ideal length for the idea it conveys. If that is short, so be it. Clarity should be your primary goal.

Do make sure to include just 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 or practice. Provide just 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.

Saving Writing Time
Two steps can save you much time and effort if you do them 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.
These steps are related; similar papers in LISA Proceedings may demonstrate relevance (though you may consult the Program Chair in the case of completely novel work). You must provide references to related work if it exists; these scholarly references are in addition to the standard references to work you used in writing your paper. For more information on how to find appropriate references, see the Author Resources below.

Looking up references first can save you much time because you will be able to judge the likelihood of acceptance of the paper before writing the proposal. With references in hand, ask yourself several questions:

  • Is the work new or novel? Has it not adequately been explored before in the way you intend?
  • Is the work timely? Will it be of interest to LISA attendees?
  • Does the work represent a substantial improvement to the practice of system administration?
If the answer to these questions is "yes," you have a potential paper! If not, consider how to change your topic until the questions can be answered in the affirmative. If you have any questions about whether your paper topic is appropriate, please contact the Program Chair by sending email to lisa07chair@usenix.org.

Writing Notes to the Program Committee
Remember that you are not writing this submission for public consumption. The draft paper or extended abstract is for the Program Committee and their appointed readers only. It helps the Program Committee and readers greatly if you give us a brief overview of what you left out, other details you intend to include in the final paper, and potential differences between the submission and final paper, if any. Many authors prefer to typeset notes to the Program Committee in italics or square brackets, to distinguish them from the main flow of the text.

Submission Style
LISA attendees, readers, and the Program Committee need to understand your content as quickly and completely as possible. You should respect their time as readers when writing.

  • Use simple and direct statements in present tense where feasible.
  • Avoid long, multiple-clause sentences that are difficult to parse.
  • Avoid split infinitives, dangling participles, and other grammar mistakes.
  • Check spelling, punctuation, and URLs of Web resources.
  • Test URLs, and make sure they will exist at the time of LISA. Maybe set up a reflector site where you can maintain the links, if they change.
There are many resources for information on how to write well. Classics in the field like The Elements of Style by Strunk, White, and Angel, and On Writing Well by William Zinsser can help you improve the quality of your extended abstract, final paper, and general writing.

Submission Checklists
Here are some checklists to use in determining whether your submission is ready to send to the LISA Program Committee. The checklist you use will differ slightly depending upon the kind of paper you are writing:

For a "typical" problem-oriented paper:

  • Describe the problem to be solved and its importance. (Why should people 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 people learn more about other approaches?)
  • 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 affect things.
  • Include relevant figures and tables with captions. (What data do you have on the problem or its solution?)
  • Explain figures and tables. (What conclusions do figures and tables support or suggest?)
  • Describe your conclusions. (What did you learn?)
  • Describe the availability of tools, if applicable. (How can people repeat your results?)
  • Check for appropriate grammar and writing style.
  • Look at the Call for Papers and make sure you meet any additional criteria listed there.
  • Check spelling.
  • Check URLs of Internet resources for validity.
  • If you are submitting an extended abstract, include a full outline at the end.
For a "typical" case study:
  • Describe the 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?)
  • 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. (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 Papers and make sure you meet any additional criteria listed there.
  • Check spelling.
  • Check URLs of Internet resources for validity.
  • If you are submitting an extended abstract, 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 may find Mark Burgess' series in ;login: on research in system administration helpful: "System Administration Research I, II, and III." 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 sending email to lisa07chair@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.

Simon Peyton-Jones has an excellent set of slides on writing a technical paper, which many people (both new and experienced) should find helpful (view PDF).

If your paper will include numerical results (a very good idea) you may find Margo Seltzer and Aaron Brown's 1997 invited talk "Measuring Computer Systems: How to Tell the Truth with Numbers" (view PostScript) helpful.

Submitting a Draft Paper or Extended Abstract
All submissions must be electronic and in ASCII or PDF format. Proposals submitted in other formats will not be reviewed or accepted.

Every submission must include:

  • Paper title, and names, affiliations, and email addresses of all authors. Indicate each author who is a full-time student.
  • The author who will be the contact for the Program Committee. Include his/her name, affiliation, paper mail address, daytime and evening phone numbers, email address, and fax number (as applicable).
Please use the online submission form.

Requirements for Accepted Papers
There are several requirements for papers accepted to the conference. Extended abstracts or draft papers 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 draft paper or extended 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 per paper will receive a registration discount of $200. USENIX will offer a complimentary registration to the technical program upon request. Authors who are full-time students may apply for financial support to attend the conference via the USENIX Student Grant Program.

The paper (or the extended abstract describing the paper) must not be submitted simultaneously to any other conference or publication without prior permission of the Program Chair. 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 nondisclosure agreements, are not suitable for publication.

The Review Process
After you submit your draft paper or extended 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 submission carefully and rate it 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 case of extended abstracts, it is important to remember that although the Program Committee will have received 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 an 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.

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

Draft Papers and Extended Abstracts We Will Not Read
There are cases in which the Program Committee may refuse to read a submission.

The Program Committee only accepts submissions submitted by the original authors. Proposals submitted by third parties, authorized or not, will be returned unread. Proposals submitted anonymously will be returned unread. Proposals accompanied by nondisclosure agreements will be presumed to contain unacceptable conference content and will be returned unread.

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

Draft Papers and Extended 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. 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 those authors who are not system administrators, 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 lisa07chair@usenix.org.

Next page

?Need help?


Last changed: 14 May 2007 ch

LISA '07 Index
USENIX Index