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.
- 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.
- 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.
- 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.
- 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.
- 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.)
- 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.
- 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.