[Back to LISA Call for Papers]
Introduction
Welcome, potential LISA author! This page is provided to give you the
optimum chance to get your paper accepted to LISA. It delineates what
we expect of a 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.
But this potential impact comes with a price. 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. Historically, we accept about one in every three papers
submitted. As a result, we have 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, with no upper age limits. Author
credentials range from High School Diplomas to Ph.D's. LISA welcomes
contributions from outside the USA for authors authorized and able to
travel to the United States for the Conference. All these kinds of
authors share 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? Use this as a
starting point, but do not commit to a topic yet. Instead, look for a
way of explaining your topic in the context of other work.
LISA Attendees
LISA attendees are 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 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 in
awarding "best paper" awards, and 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 LISA's
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 not acceptable at this stage;
if you send a full paper, you must also include an extended abstract.
In the abstract, 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.
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 several revisions of the abstract, at least
one month in advance of the duedate (April 29, 2002). Great abstracts
are not simply written, but rewritten in reaction to feedback
from several readers. Make sure to have several other system
administrators (or managers, or theorists, or 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 duedate to give
them time to read your abstract and make comments.
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.
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). When appropriate, references are
required in the extended abstract that you are required to provide.
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 abstract. With references in hand, ask yourself several
questions:
- Is the work 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 an 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 via
email to lisa02chair@usenix.org.
Planning an Abstract
The best way to write a great abstract is to write the whole paper
that it describes beforehand. As many LISA authors are busy
practitioners, this is often impractical. A good substitute 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
abstract, write a draft of the corresponding paper section, and then try
to condense it.
Abstract Style
LISA attendees, readers, and Program Committee have the same need as
you to receive information as quickly and efficiently 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 contractions such as "don't", "can't", etc.
- Avoid split infinitives, dangling participles, and other grammar mistakes.
- Check spelling, punctuation, and URL's of web resources.
Writing an 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 abstract. Endeavor to leave out the least needed details.
Things you should not omit in the abstract include:
- Figures and tables showing performance data, if available.
- References to related work.
Neither references nor figures count toward the "word limit" for the
abstract. Please remember to explain figures and the relevance of
references in the 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 only completed work, not work in progress. Clearly
distinguish between completed work and ongoing development that might
result in changes to the final paper.
- Concentrate on "why" rather than "what". Explain the logic behind a
method, rather than just describing the method.
- Focus upon and support a few selected conclusions, excluding details
that do not support your central argument.
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. 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.
If you are fortunate enough to have already written a full paper
(which is the best way to prepare for writing an abstract),
please feel free to include the full text of the paper after
the abstract in the submission file.
Writing Notes to the Program Committee
Remember that you are not writing this abstract for public
consumption. The 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 abstract 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 Checklists
Here are some checklists to use in determining whether your abstract 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 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 performance of solution, including functionality,
limitations, robustness, efficiency, and ease of use, as
applicable. (How well does your solution work?)
- Critically analyze differences between options for solving the
problem. (How does your solution compare with others?)
- 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.
- Check spelling.
- Check URL's of internet resources for validity.
- For a "typical" case study:
- 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?)
- 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.
- Check spelling.
- Check URL's of internet resources for validity.
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 lisa02chair@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.
If your paper will include numerical results (and this will make us
very happy) then take a look at Margo Seltzer and Aaron Brown's recent
paper "Measuring
Computer Systems: How to Tell the Truth with Numbers".
Submitting an Abstract
All abstract submissions must be electronic, in ASCII, PDF, or
PostScript format. Please use this Web Form for submissions.
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. To aid this, 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.
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.
Papers found to be in violation of any of these rules will be removed
from the Conference Program and Proceedings, even if they have
already been accepted by the Program Committee.
The Review Process
After you submit your abstract, it will be given 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 (relatively obvious) 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 outlines, 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.
During the review process, each abstract may be read by a potentially
large number of readers. 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 Do Not Tend 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 General 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, especially if you have a paper idea but have
concerns about it not being right for the conference, please send
email to the Program Chair at lisa02chair@usenix.org.
Need help? Use our Contacts page.
