Difference between revisions of "Tips for ELC presentation proposals"

From eLinux.org
Jump to: navigation, search
(create page)
(No difference)

Revision as of 18:31, 29 January 2018

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.


I started the Embedded Linux Conference over 12 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 (high) probability that your talk will not be accepted.

The review process

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

What the program committee likes

  • what we like to see, as a program committee
    • a clear indication of what the talk will be about
    • we believe you know what you're talking about
    • 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

  • about speaker level
    • we prefer most of our talks to be at the medium to advanced engineer level
    • We sometimes throw in a few beginner talks, but these are an exception

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.


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.

  • be specific about what you will describe
  • 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.