Writing a paper for LISA is easy. There are four steps:
At every step, draw on the experience of people who have already done it. Talk to your friends and co-workers who have written papers, write me e-mail, and read the existing LISA proceedings to see what kinds of papers you like and don't like.
Step one is the easiest. We are all working in environments where we either come up with innovative ways to do our jobs, or we are overwhelmed by the sheer complexity of the systems we work on. Think of part of your job that was hard until you approached it in a new way, perhaps by working with others to change how you work together, or by writing a program (or getting someone to write one for you). Team up with the people that you work with, and present your ideas together.
If you need help convincing yourself that the kind of work you do really needs to be written about, read the list of conference topics (in the Call for Papers). The list there is very detailed, and might give you help thinking about what it is you do that others might want to learn about.
Managers, you are not exempt! Effective system administration requires good management in and outside of the sysadmin group. Papers related to management techniques that work in our challenging industry belong at LISA, just as the hardcore technical papers do.
Before you can submit your idea for a paper, you need to develop it a bit, so that it can stand on its own when you submit the proposal for the paper.
In my experience, writing an outline for the eventual paper is a good way to develop your idea. Your paper may not stick to the outline in the end, but it's the outline, and the abstract you write from the outline, that will give you (and the reviewers) the confidence in the idea you need to go forward. For an example of the outline I used for my paper on Cricket, click here.
Now, write an abstract that explains why you were forced to have the idea (necessity is almost always the mother of invention in LISA papers), and why other people should want to know about your idea. Here is the abstract I submitted when I wanted to share Cricket (then named Super MRTG) with the folks attending the First Conference on Network Administration:
WebTV's Operations group has become addicted to a data gathering, rollup, and graphing package known at MRTG (Multi-Router Traffic Grapher). There's only one problem: we became so addicted, we needed it to scale in ways it wasn't designed to scale. To solve our problem, we wrote a new tool we call Super MRTG (SMRTG). It borrows ideas and code heavily from MRTG (and a follow-on to MRTG, RRD), but adds a hierarchical configuration system that makes it quick and easy to monitor new components. In addition, SMRTG uses a lazy rendering system to minimize disk and processor overhead from stored reports. The result is a fast, flexible system for monitoring an order of magnitude more systems, with greater flexibility, than MRTG is reasonably capable of monitoring, and a flexible framework for future tools which can leverage the same configuration information.
Hint: Be careful what you write in the abstract, since it will be published in the conference schedules and invitations long before you start writing the paper. If you are not willing to commit to talking about something, don't put it into the abstract. In my case, I wanted to change the name of my idea from SMRTG to Cricket, but I forgot to do it before submitting the proposal. You can change the abstract that goes along with the paper later, if you want, but you can't really change the abstract that goes in with your proposal. There's simply no time between when the papers are picked, and when the conference materials must go to the printer.
One last word of advice: put some effort into this step, but don't go all the way and write the paper at this step. After all, your paper has not yet been accepted. I don't know anyone who has proposed a paper and had it rejected, but it can happen. The biggest reason it happens, I'm told, is that the idea is not sufficiently developed by the time it's submitted. Clearly you need to strike a balance between under- and over-developing your paper at this point. It's not a particularly hard balancing act, but you should be aware of it.
When you have been notified that your paper has been accepted, write it!
Your outline should be in pretty good shape at this point, but now is the time to really work on it. The one I included above already has had this step applied to it, so it's a bit more honed than yours might be coming into step 3. Look at the flow of ideas, and how you will make the paper work as a whole, as opposed to just a set of facts. You want a paper that pulls the reader through it.
Be choosy about what goes into the paper. It's often as important to leave details out, as to put them in. Consider using more space to explain the concepts, and less to explain the details, especially if you are describing a system that has its own documentation, separate from the paper, where the details can be covered.
Communicate with the conference organizers, so that they know you are working on the paper. If you need opinions on what things to cover, they can be helpful.
When your outline is in peak form, make a copy of it, and write the actual words of the paper right into the midst of copy of the outline. Your outline should be detailed enough at this point that you find yourself simply editing the outline's words into complete sentences, and adding paragraph structure and connecting words here and there. If the going is not this easy, perhaps it's time to take a break from paper writing, and go back to editing the outline. Writing the words of the paper should be easy -- the ideas should already be organized by that point. I suggest you do it this way because it abstracts the idea-forming part of writing from the word-forming part. Don't try to line up your ideas while you are trying to make words flow. They are two separate processes that happen best separately.
Leave more time than you think it will take to write, edit, and finalize your paper. Get help from other people to edit it, both for technical accuracy, grammar, spelling, and punctuation. You cannot see 20% of your own errors. They will be in the final product unless someone else catches them. You have to give them a chance to help you.
Leave even more time than you think it will take to format it and print it. You usually submit the paper in "copy-ready" form, which means that the same pixels that come out of your printer will be the ones that end up on the printing press churning out the proceedings. It's worth it to work at getting a good final print.
This is the fun part, unless public speaking terrifies you, like it does most of us.
The best advice I ever heard on public speaking came from an article I read about the IPO road shows CEO's do. The speaking coach told the CEO to make the best of the nervousness we all feel. When you get out there, you are going to feel a rush of adrenaline. You can't control it, it will control you for a bit. Don't fight it, just go with it. Use that energy to do the introductions, to look around the audience, whatever. If you take a deep breath or two before launching into the real content, you can come down off the adrenaline high and prevent it from rearing it's head and taking out your concentration again. The goal is to let the nervousness subside and hit your pace, then finish your talk in style.
I've found that an unfortunate side-effect of this technique is that it suppresses the bulk of the nervous energy until after the talk. I'm always more nervous after than before, but by then it's done and you can go enjoy a pint of beer!
Of course, fear of the unknown is the worst, so practice enough that you are confident. As with all things, practice makes perfect. Your first presentation to 200 people won't go as well as your 10th. We don't mind. Everyone in the audience in a situation like that is thinking "I'm glad I'm not up there!". They don't mind a bit of nervousness here and there, as long as you are making an effort to get the information across.
Aim to make your talk short, since giving it in a nervous state can expand it some, and it's really much more interesting to answer questions than to just drone on. Remember that the audience can always read your paper later... your talk is meant to let you communicate, in person, the essence of your idea, and to let the people who will be using it put a face with the name.
I've written and presented two papers, one at LISA and one at the First Conference on Network Administration. Together with David Williamson, I gave an invited talk at LISA '99.
I work for WebTV Networks, Inc. as a programmer for sysadmins, among other things. At WebTV, I implemented some of the tools we use to monitor and operate the WebTV Service. I wrote a tool named Cricket, which can be used to monitor trends in data from hosts and network devices. WebTV was nice enough to let me release Cricket under the GPL. More information is available on Cricket at http://cricket.sourceforge.net.
You can contact me at jeff.allen@acm.org.