How to get a conference abstract accepted

I've just looked at the paper submissions for linux.conf.au, which has been described as "the OLS of the Southern hemisphere" by people who've been to both. There are many excellent paper proposals this year, and judging them is hard work. Some authors do themselves and their audience a disservice by not sending in a submission with the right details to properly judge them.

Conference committee members want to choose papers that will attract and entertain an audience, and develop the conference in the right direction. LCA, which is not the biggest conference, had over 100 submissions for about 50 slots.

Unlike some other conferences, LCA requires only an abstract to be submitted with the proposal. This possibly makes the work of selecting presenters harder, but it saves people writing a whole paper and having it knocked back. I suppose I would prefer people had more time to keep developing their projects rather than writing papers.

(I don't speak for the LCA Committee. This is not necessarily the criteria used to judge papers but merely a personal opinion.)

I have the impression that technical Linux conferences have the unstated purpose of advancing world domination, by encouraging people to write new and cool software; bringing new people into the fold by making them think it's fun and within reach. One important outcome to my mind is that everybody goes home and tries something they wouldn't have done before. Perhaps they install Linux for the first time, or perhaps they really get excited about not just using but helping with development. So there is both a practical side ("this is how distcc works"), but also a social, almost evangelical side ("this is how you build a little modular useful program; this is how you promote it and make it successful.")

This isn't to say that meta-technical issues, like licensing, or LUGs, or social issues, or whatever are not interesting or worthwhile.

Here are some ideas I think might help if you want to get a paper up. Obviously mileage will vary depending on the conference and the particular committee.

1. Give enough detail. Some people sent in just a few sentences giving a very broad description of the technology they were going to speak about. When there are so many more proposals than spaces these ones fall on the first fence.

   The abstract ought to hint at enough technical detail to pique the interest of the review, and to show that you really know more about the topic than can be gleaned from Freshmeat.

2. Include links! Allow the reviewer to drill down to discover more about the technical material, or about your background or experience. Hopefully the reviewer will find the project's web site so interesting that they really want to hear more about it. This can also help establish your credentials as a presenter (showing previous papers/slides/etc), or your association with the project.

3. Indicate your public speaking experience. The selection committee members ought to be able to tell from a good abstract whether the material will be interesting, but that says nothing about whether you're a good speaker or not. It's sad but true that somebody with an impenetrable accent or mumble probably won't be enjoyed by the audience.

   Obviously, as in everything else, be honest: if you don't have much experience it won't rule you out, everybody has to start somewhere. Talking at LUGs or uni presentations helps your resume and gets some practice.

4. Focus on your own original work. New material is more interesting to attendees. Not only do authors make more interesting speakers, but it also supports the purpose of encouraging developers. Make sure that your bio explains your connectiont to the topic.

5. If it ought to be a tutorial, or BOF (birds-of-a-feather / boring-old-fart) session, then say so, don't try to squeeze it into a paper. An overview of how to use a particular established tool is worth having, but it probably isn't so appropriate for a paper at Linux technical conference. (Perhaps the reviewers might suggest "better as a tutorial?", but it helps if you try to apply for the right category in the first place.)

6. LCA covers all Linux-related topics, in contrast to other conferences which focus only on the kernel or GNOME or KDE. So topic matter is a funny question: some papers are about somewhat topics that for a general Linux audience are a bit esoteric, like fingerprint recognition or SCADA. Perhaps this means less audience members will actually go away and actually use the technology, but on the other hand it makes it novel and interesting. Other proposals look at internal aspects of the kernel or some other software package, and again people might be interested to know about it even if they'll probably never write a virtual frobserver plugin. Basically the point is to make it clear that the material is novel but also relevant or at least interesting to attendees.

7. Potentially successful projects are more interesting. Sometimes you see projects that are technically OK, but that have no real plan for how they'll be widely accepted. Perhaps it's a needless reimplementation of something that already works pretty well. Perhaps it's a design that works on the author's machine and they've given no thought to how it would ever be put into a distribution, or used by other people. I won't say this is worthless, but it's not going to score as highly with me because it neglects important software engineering aspects, and because it doesn't further world domination.