Conference Submissions & BSDCan 2013

The BSDCan 2013 call for proposals is open. As a BSDCon committee member, it’s my responsibility to get you lot to submit interesting papers. So: submit!

More than once, I’ve been asked something like “How can I get a paper accepted at BSDCan?” or “Why was my BSDCan paper rejected?” Here’s my answer to that general question. Lots of this applies to any conference, but as I’m not on the committees for those other conferences, I can’t claim any authority there. Other conferences have their own ideas, and other BSDCan committee members might have independent thoughts as well.

The purpose of a BSDCan paper is not to advertise the presenter’s work, but to put butts in seats. Sometimes these overlap. I want someone looking at the BSDCan schedule to say “Wow, I HAVE to go to this!” But “be interesting” isn’t exactly useful advice. Some of this might be.

1) Present an topic that hasn’t been covered before. The previous proceedings are all available online. Some topics come up every year. Don’t submit those unless you have a fresh new take on them.

2) Tell us why YOU should be the one to present your topic. We frequently get multiple similar proposals, and have to choose between them based on who we think might do the best job. Don’t assume that everyone on the committee knows who you are. One of us probably knows that you run weaselBSD on twelve thousand workstations, but they probably won’t share than information with everyone else. (Paper selection is done via web form, which isn’t as conducive to back-and-forth discussion as in-person or mailing list discussions.) More than once I’ve had someone come up to me at a conference and say “Why did you have so-and-so report on X? I have forty times as much X as the speaker you chose!” My answer is, “You didn’t TELL US that you had so much.” I am not telepathic.

3) We get many FreeBSD proposals. I want more Net/Open/Dfly proposals, as well as for projects and devices based on them. Non-F/N/O/D BSD papers have much smaller audiences, so a paper on them has to be very interesting. Again, butts in seats.

4) Include “lessons learned.” Anybody can read a man page. If you were involved in recovering from the recent FreeBSD security incident, you should submit a paper about it. If you deployed OpenBSD in a nuclear submarine and learned about the importance of the little radiation-detection badge, you should submit a paper. “Lessons learned” implies that you made mistakes, and can upgrade your talk from the merely technical to a bit of a story. Don’t be afraid to embarrass yourself, we’ve all been there. Sharing mistakes helps connect your presentation to the audience.

5) Tell us what the audience will get out of the talk — e.g., if it’s a sysadmin talk: “Attendees will be able to configure weaselBSD’s anti-ferret features and understand how they integrate with email and Web.”

6) Spelling and grammar are not pimple cream, to be dabbed on where needed. If you’re going to indulge in floccinaucinihilipilification, you’d better be able to spell it.

7) Speaking of floccinaucinihilipilification, you’re better off saying why your stuff is awesome as opposed to running down someone else’s work. I know many reasons why computers suck. Learning something to make my job suck less is good.

That’s what I look for, at least. Others have their own opinions. And if you think a little bit, you can make your proposal answer all of these. Unless you’re running weaselBSD, that is…

Now: submit!