How to get your conference talk submission accepted

No readers like this yet.
open source button on keyboard

Opensource.com

Michael Davies, a part of the Linux.conf.au (LCA) conference talk review committee, spent a session at this year's conference talking about how they review talk submissions and choose which ones to accept for this large Australian open source conference. While he spoke specifically about LCA, his tips are largely applicable to those interested in submitting a talk proposal to any conference.

The LCA papers committee consists of experienced LCA attendees and volunteers who are both active in their communities and familiar with the conference. They try to keep a balance from year to year of fresh voices with experienced reviewers. The repeat reviewers help ensure that the conference maintains the same feel from year to year, so they use the previous year's papers committee with a few new members. They also consider the balance of the committee members.

"Even though this [conference] started with a heavy focus on kernel developers, we want balance," said Davies. "We want the width and depth of the open source community." They take into consideration when selecting the scheduleand thus have represented on the papers committeegender diversity, applications, software and hardware, engineers and writers (and more) so that all of those things are represented in the conference.

Abstracts are scored with software called Zookeepr, developed in 2007 for LCA. Each abstract is reviewed by about eight reviewers (out of a committee of 28) who choose a score for each submission from -2 to 2. LCA reviews approximately 300 abstracts in under three weeks. If you do the math, that's about 40 hours of reviewing per person in a short amount of time.

When an abstract shows promise and is submitted early enough in the process, the committee will contact the author asking for clarification, leading to iterative review. They may seek changes to the topic or title to help it get accepted.

What makes a good abstract?

  • A catchybut informativetitle
  • A story that's interesting to LCA delegates
  • Clearly about open source software that has been released
  • An intended outcome and takeaway for attendees
  • A clearly passionate speaker

They then hold a face-to-face meeting at which 10-12 of the 28 attend and others join over IRC, and they spend a day together with the scoring and leave with a list of speakers and backup speakers. They accept the universally well-scored abstracts (scores >~1.5 mean) and likewise reject the ones with universally low scores. It's the middle 80% or so they spend the day discussing to make sure that the conference is well-balanced in topics and that there's something interesting for every delegate in each time slot. They look for people who are good speakers, based on verifiable experience, videos, and referrals. They also want to know that the speaker is a subject matter expert, based on things like blog posts, mailing list contributions, and code commits (or other relevant contribution). At the end, they hand over to the core organizing team a draft schedule, including backup speakers.

When you're writing your abstract for submission, consider if it meets all of the conference's goals, which are usually well-described in the call for speakers. Remember, you know your project, but that doesn't mean the reviewers do. Give the background, status, and your intended result of speaking on the topic.

Zookeepr includes the option for a private abstract, which you'll see on many calls for papers. This gives you the opportunity to explain things directly to the review committee without it being shown in the description listed in the conference program. You can mention things that you hope to keep a surprise or how it's been successful at other events.

Poor abstracts

Of course, the flip side of the great abstracts is the poor ones. Daniels gave several qualities that are likely to get your talk rejected:

  • You're not an expert on the topic being submitted.
  • It's a sales pitch, which almost nobody wants to listen to.
  • The talk isn't relevant to the particular conference's attendees.
  • You submitted an excessively complicated abstract that none of the reviewers understand.
  • You submitted poorly written and unproofread abstract.
  • You're talking about vaporware. They want to hear about something that's real.

Concerned that your submission won't be good enough? You definitely don't have to fear being the most poorly written abstract. Davies' clear worst example (with identification redacted) of the worst abstract ever submitted was the following, in its entirety:

I do [project name].
[IRC nick]

Writing your abstract

When you write your submission, begin by looking at last year's program. See the depth and types of topics covered and think about why those were the ones that were submitted. If you can, take a look at blog posts from the previous year to see what people found the most interesting and popular.

Just because you work on an interesting project, though, doesn't mean it's a great talk. Find the right talk. Write down a few ideas of talks you might give, and find the one that will really shine on a conference program. That's the one to propose. Many conferences (including LCA) don't mind multiple submissions, though they're likely to accept only one.

Consider also:

  • Is the talk fresh, or is the same one you've been giving at five other conferences for the last year?
  • What will draw attendees into your talk?
  • What's the message you want to convey?
  • More is less (remember the quantity of reviewing the committee is doing)but give them enough to draw them in.

When it comes to submission time, make it easy for that committee. Write well, use punctuation and good grammar so it's easy to read. Tell them where you've spoken before and give them evidence of your expertise on the topic. Don't assume that they know you or your work. Don't expect them to go research it. And get some feedback from colleagues on your abstract before you submit it.

Also pay attention to your bio. What makes you stand out from the other submissions? Why are you different? What are you bringing to the microphone? And don't forgetlies are easily verified, and what you write about yourself is on the Internet. The Internet is forever.

Finally, "don't play chicken with the CFP dates," Davies said. If you're late, you're not getting accepted. On the off chance that you're so amazing they do want to make an exception, they're not going to think highly of you come next year.

User profile image.
Ruth Suehle is the community leadership manager for Red Hat's Open Source and Standards team. She's co-author of Raspberry Pi Hacks (O'Reilly, December 2013) and a senior editor at GeekMom, a site for those who find their joy in both geekery and parenting.

1 Comment

Great article and good reminders! I think it is easy to get sucked in by your research or discoveries in your abstract (while that thought nags you in the back of your mind that your writing needs to be relevant to your audience) that we can get paralyzed.
It is important to not only set out writing the abstract by answering these guiding questions, but to also revisit them throughout and at the end of the writing process.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.