Tips for ELC presentation proposals

From eLinux.org
Revision as of 15:11, 10 February 2020 by Tim Bird (talk | contribs) (Note on your chance of success)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page is written with the intent to help you, the reader, to write a better abstract for a proposal for a presentation at Embedded Linux Conference.

Introduction

I started the Embedded Linux Conference over 14 years ago. I've been on the program committee for the event and for it's companion event in Europe since their inceptions. I've read literally thousands of session proposals, and I have opinions of what I like to see, and what I don't. This document will help you write the kind of abstract that I like to see, and help you understand the program review process. This will hopefully accomplish 2 things:

  1. Help you write a better abstract, that is more likely to be accepted
  2. Make you feel better about the (unfortunately high) probability that your talk will not be accepted.

The review process

  • each reviewer ranks the talks from 1 to 5
  • some reviewers assign tags to each talk, to indicate topic area
    • all talks are scored by adding their ranks
    • talks with highest scores are accepted
  • each talk is discussed
  • we look to see if a talk has been given at another event
  • we check to see if the presenter has provided slides for their previous talks (if any)
  • we check to see how many talks are in each topic area
    • we try to avoid having too many talks in the same topic area
  • we try to avoid having too many talks from a single company
  • we see how much travel budget we have, and only accept talks that request travel funding, up to our budget limit
    • travel budget is allocated for talks that are higher in rank first
    • this means that once we run out of travel budget, a talk, even if it is highly ranked, may be rejected
  • we accept talks up to about 95% of our slots, leaving a few empty for possible use by sponsors
  • Then we wait-list a set of talks, and send out acceptance, wait-list and rejection notices

What the program committee likes

What we like to see, as a program committee:

  • a clear indication of what the talk will be about
  • an indication that you know what you're talking about (mostly from the biography, but you can often tell from the abstract)
  • a talk that appeals to a large audience
  • a talk on a topic that has not been covered before (see "dislikes" section on repeats)
  • the technology is ready and available now
    • the thing you describe should already be upstream or already open-sourced
      • We've been burned by projects that the company claimed would be "open source" soon, but then the source never materialized.
    • sometimes, we make exceptions for speculative technology or APIs
      • These are allowed when public discussion of the new technology is desirable.
  • a talk that presents material likely to have lasting reference value
    • we record talks, and the video of a talk could be used for years as a technical reference for a sub-system or technology area
  • the talk should be for a medium to advanced developer
    • We sometimes throw in a few beginner talks, but these are an exception
  • the speaker has given popular talks in the past (but not this exact talk)
    • this is a bit unfair to new speakers, as it's hard to break into the existing circle of known speakers, but that's the breaks
      • we specifically include a few new and unknown speakers in each event, if their proposals are good, to try to get new blood

what the program committee dislikes

  • talks that have been given before
    • especially if the abstract is identical
    • especially if the prior talk is already recorded
    • sometimes, we make exceptions for talks of high value that we want a different geographic audience to see (e.g. a talk given in Europe was really good, so we allow it to repeat in the U.S.)
  • a sales pitch for a commercial product
    • Sometimes it is obvious that a talk will be about a company's product that is for sale. ELC is not intended to be an advertising mechanism for your product. If you want to do that, you have 2 options: 1) become a sponsor, and get a paid session slot (there are a few of those at each event), or 2) get a booth in the exhibition area. That's what those booths are for - for you to sell your product (or convince people to join your Open Source project).
    • A pitch for people to join an open source project is OK.
    • Sometimes people try to hide the fact that they plan to include a sales pitch. We can often detect this. Don't have the marketing department write your abstract.
    • It's OK to mention your commercial product in the course of delivering a talk about a related technology or open source project. We know people have commercial products. Just don't turn the talk into a sales pitch.
  • we strongly dislike it when a presenter fails to provide their slides
    • the slides are an important output of the event, that are intended to help the whole industry, including developers who could not attend the event
    • if you have spoken at previous events, we check to see if your slides are available from those events. If not, that usually results in a significant reduction in your proposal ranking.
  • talks that are not about Embedded Linux
    • we take some talks on tangential topics from time to time; like Open Hardware, firmware (e.g. U-Boot), legal topics, and community involvement (mainlining)
    • However, our focus is on Embedded Linux software itself - the kernel and user-space, and the tooling and methods around those pieces of software.

Tips

  • be specific about what you will describe
    • provide numbers for things that can be measured (boot-time reduction, size reduction, performance increase, etc.)
  • don't use up your entire abstract describing the problem or introducing the topic
    • I see this a lot: 2 paragraphs describing the topic, 1 paragraph saying how important it is, and 1 sentence saying what the talk will be about.

Here's a made-up example of a really, really BAD abstract:

 The Internet of Things is the network of devices that collects data, performs
 computing functions, or causes some action, and can communicate on the Internet.
 It is projected that by 2030, there will be 3 trillion devices connected to the
 Internet of Things.
 
 It is important to make IoT devices secure.  There have been an increasing
 number of exploits for IoT devices.  This is a really serious problem.
 
 There are many ways to make IoT devices secure.  This talk will present
 some ways that the presenter has found to make IoT devices secure.

The first paragraph is completely superfluous. If someone cares about IOT security, they know what IoT means. The second paragraph also does not say anything that is not widely known. Maybe if it mentioned specific exploits and how the talk would address mitigating or avoiding those, it would be worth mentioning as justification for the talk. The third paragraph is just frustrating. It describes what will be presented in only the most vague and hand-wavy terms. There is absolutely no way for the program committee to determine what this talk will be about, and whether it will be valuable or not.

Some notes on your chance of success

Many factors that affect the probability of your talk being selected are out of your control.

Here are some factors that nobody can anticipate ahead of time:

  • what other talks were submitted in your topic area
  • how "hot" is your topic area
  • how many talks were submitted overall

The talk that is accepted is the best one its "category". This means that you might have a really great talk proposed, but if the maintainer of the sub-system, who has a great track record of public speaking, makes a proposal on the same topic, you're pretty much out of luck. Your talk will get pushed out by competition.

Note also that you can't compare your proposed talk to others. We might only get one talk on kernel debugging, and four talks on bluetooth networking. Your talk on bluetooth might be much better in quality than the one on kernel debugging. But in order to get diversity of topics we only take one talk on debugging and one talk on bluetooth networking. Even if your talk is great, if it is the second-best one on bluetooth networking, it will not be accepted. Or, if you have a really great talk, but it's been given before, we might accept a "lesser" talk over yours, in order to get a different perspective on the same topic.