Wed, 04 Oct 2006

linux.conf.au submissions, rejected

I know, in the 250 abstracts I'm judging for linux.conf.au, I'm throwing out some pearls among the sand. And I'm probably unfairly biassing against people, but dammit, the number of "I am a member of an open source project so let me tell you how to code/run a project/create a community" papers I've seen is astounding.

Firstly, being a member of an OSS project describes the majority of our attendees: it's about the minimum standard for a speaker. If you expect over a hundred of them to listen to you, you've got to be in that top 1%, and you've got to convince me of it! So if your project hasn't done something significant or astonishing, don't waste my time submitting a talk about it. And if you weren't the key person doing that astonishing thing, ditto: unless you're a known awesome speaker, I'm going to rate you low. And if I can't tell if it was you who did the work, I'll rate you low, too. If you didn't tell me, sorry, no time if google didn't take me straight there...

Judging technical abstracts can be hard: there are so many Open Source projects! (Are our attendees really interested in your implementation of Yet Another window manager? Maybe not, but how to write a new window manager, maybe!) But judging non-technical abstracts is almost entirely a judgement on the person presenting. If noone has heard of you, and especially if you sound like a crackpot, sorry.

So, while you're best known for your implementation of a video codec in 23 instructions, you really feel you have a lot to say on Eastern philosophy and its influence on your post-Raymondian Free/Unlocked/Cooperative/Knowledge-based software design. I'm sorry, I can't judge whether your presentation will suck, so given the number of papers, well, perhaps you should just put it up on your blog. I'll read it, I promise. (And why didn't you submit a paper about that damn video codec?)

Flowchart for "should I submit an abstract to LCA":
(1) Have you done something related to F/OSS you're excited about? If so, goto (3).
(2) Is there a great demand for information on some subject on which you are a leading, recognised expert? If yes, please submit an abstract[1]. If no, please do not.
(3) When you describe/show this to collegues, are they interested? If no, please do not submit.
(4) Is what you've done expected to be widely used? If yes, please submit[2].
(5) Is what you've done original and useful for other F/OSS projects? If yes, please submit[3].
(6) Is what you've done so insanely cool that it makes people say things worth quoting? If yes, please submit[4].
(7) If you reach here, don't invent something to speak about. It'll suck, because like me, you're not inherently interesting.

Finally, be aware that preparing a talk is a significant amount of work. You need to prepare and weed the material, cast it into a coherent presentation, and practice several times (on real people if you're not an experienced conference presenter). This takes a good couple of days' time. And never do a tutorial: it takes much longer to prepare and needs far more practice, since you need to time and test the user interaction as well.

Bad speakers happen, but in the past we have had some speakers who didn't prepare. This is unforgivable, and I always oppose accepting proposals from those speakers again: our attendees deserve (and demand) better. The miniconfs or BOFs are the place for ad-hoc presentations.

[1] This covers "expert" talks like licencing talks, etc.

[2] "X.org development" vs "libmeanwhile development"

[3] "A new typechecking tool" vs "Haskall type experiments"

[4] "Build your own satellite" vs "My First Gnome Applet"


[/tech] permanent link