Update: Someone else said it very well here
When I last mentioned LISA, I forgot to mention the big news! This year submitting papers is a lot easier! Less work for the authors!
Rather than having to submit the entire, nearly finished, draft in advance, you can submit a briefer summary. If it gets accepted, then you have to write the entire thing. This saves a lot of time in case your submission is not accepted (how would that happen?). It also lowers the bar to submitting, which is important. I think more submissions is better. If this is your first time submitting a paper, this is a good opportunity to go for it.
There are three things you might consider proposing:
- Refereed papers: Did you invent something? Prove a new theory? Create a new tool or software system? Submit a paper. Submissions are simply extended abstracts, 500-1500 words plus an outline of what the final paper will look like. (Details here.)
- Practice and Experiences Reports: NEW! This is a new category. It's a bit different. This is a story telling category. Have you completed a major project and would like to share what experience they gained? I think of it as "Here's what we wish we had known before we started." Very useful. (Details here.)
- Invited Talks: A lot of people don't realize this, but some (not all) invited talks are proposed by the people that give them. Hey, the Invited Talk chairs don't have ESP nor are the omnipotent. So if you have a hot topic that you are an expert at, or would like to put together a panel of debating debutants, propose it as an I.T. or a "Guru Session". (Details here.)
- (Other things you can submit)
The deadline is May 17, 2010 (The 2011 deadline is June 9, 2011.). Less than 2 months away!
This year I'm on the committee that will be judging the papers. I thought it would be useful to tell people my personal process for evaluating papers.
I've been on the Usenix LISA program committee a few times. People ask me for advice about submitting papers a lot. Usually I tell them to read the CfP, pay attention to the deadlines, etc. But the real important advice is what I'm about reveal below.
Don't give me a "surprise ending". Please don't force me to read 4 pages before you tell me what your point is. I want to know right away. It saves me time.
A "surprise ending" paper is where the abstract says, "We've developed a new way to do X", the next 10 pages explains the history of X, then their experience with X and what problems they've seen with other systems that do X, and then at the end they finally present their surprise ending: they do X differently.
Or worse, the last paragraph says that they do it with a secret that they'll reveal in the final version of the paper, only to be revealed if the paper is accepted to the conference. I kid you not. People have done that.
The problem with the "surprise ending" is that now I have to go back and re-read the paper because now I finally know what I needed to know to understand the paper.
A surprise ending is great if you are writing a film, not if you are writing a paper.
When submitting papers to conferences, give away the surprise ending in the first sentence:
We present a backup system that is more appropriate for backing up thousands of laptops because it uses file hashes to avoid backing up files that are common to multiple laptops. Our architecture scales to 1,000 laptops.
If this is truly a "first", then I know right away you will have gotten me exceited about reading the rest of the paper. Otherwise, at least I know what I'm in for and can judge it on other merits.
As I read the opening of a paper I construct a mental rubrick that I will use to judge the paper: There better be a section of the paper that validates each of these claims: statistics that demonstrate that there is a problem (how often the same file exists on laptops), proof that demonstrate that this solves the problem (metrics about the reduction in backup time, bandwidth used), proof that shows this doesn't cause new problems (performance impacts), other problems that come to mind (laptops in "sleep mode"), and validation of their claim that it scales.
I will create this list of checkpoints and produce a grade for each one of them. If they wrote the paper well, I can do this in one reading.
By telling the audience the conclusion in the first sentence you save the audience time. This is true for the judges deciding whether or not to accept the paper, or after publication when people are deciding whether or not to read the paper.
Don't think that by holding back the good bit until the very end it will entice people to read the paper. If they are reading the entire book of proceedings they're more likely to skip a paper entirely if the relevence isn't made clear at the start. Sysadmins tend to specialize on storage, networking, operating systems, or so on. People usually read the papers that have to do with their specialization. If they can't tell your paper is about their specialization in the first paragraph, they're going to skip it.
The essence of good writing is brevity. Tell me what you are trying to say, then stop. Just be complete.
How is this less work for the authors? You still have to write the paper... What drivel! What you mean is that its less work for the readers/reviewers, which just makes it easier for them to pursue their own interests and push politics.