Writing a talk proposal needn’t be a stressful undertaking. There are two huge factors that seem to stress people out the most about submitting a proposal, and we’re going to obliterate those right now, so here they are:
- It’s not always obvious how a particular section of a proposal is evaluated, so it’s not always clear how much/little should be in a given section, how detailed/not detailed it should be, etc.
- The evaluation and selection process is a mystery.
What Do I Put Here?
Don’t fret. Here, in detail, are all of the parts of the proposal submission form, and some insight into what’s expected to be there, and how it’s used.
Title
Pick your title with care. While the title may not be cause for the Program Committee to throw out your proposal, you should consider the marketing aspect of speaking at a conference. For example, there are plenty of conference-goers who, in a mad dash to figure out the talk they’ll attend next, will simply skip a title that requires manual parsing on their part.
So, a couple of DOs and DON’Ts:
-
DOs
- DO insure that your title targets the appropriate audience for your talk
- DO keep the title as short and simple as possible
- DO insure that the title accurately reflects what the talk is about
-
DON’Ts
- DON’T have a vague title
- DON’T omit key words that are crucial to understanding who the talk is for
- DON’T create a title that’s too long or wordy
So, in short, keep the title short and clear. There’s no hard and fast rule regarding length, of course, but consider how many best-selling book titles have ever had more than, say, 7 words? I’m sure it’s happened, but it’s probably more the exception than the rule. If you feel you need a very long title in order to meet the goals of the title, describe your proposal by some friends or coworkers, and when they say “So… how to do ‘x’ with ‘y’, basically, right?”, that’s actually your title. Be gracious and thank them.
Within your concise title, you should absolutely make certain to target your audience, if your audience is a very specific subset of the overall attendee list. For example, if you’re writing a proposal about testing Django applications, and the whole talk revolves around Django’s built-in testing facilities, your title pretty much has to say “Django” in it, for two reasons:
- If I’m a Django user, I really want to make sure I’ve discovered all of the Django talks before I decide what I’m doing, and if your title doesn’t say “Django” in it, lots of other ones do. A reasonable person will expect to see a key word like that in the title.
- If I’m *not* a Django user and show up to your “Unit Testing Web Applications” talk, only to discover 10 minutes into a 25-minute talk that I’ll get nothing out of it, I’m going to really be peeved.
Finally, unless you totally and completely know what you’re doing, DO NOT use a clever title using a play on words and not a single technology-related word in the whole thing. There are several issues with doing this, but probably the most obvious ones are:
- You’re not your audience: just because you get the reference and think it’s a total no-brainer, it’s almost guaranteed that 95% of the attendees will not get it when quickly glancing over a list of 100 talk titles.
- You’re basically forcing the reader to read the abstract to see if they’ve even heard of the technology your talk is about. Don’t waste their time!
Category
The ‘Category’ form element is a drop-down list of high-level categories like ‘Concurrency’, ‘Mobile’, and ‘Gaming’. There are lots of categories. You may pick one. So if you have an awesome talk about how you use a standard WSGI app in a distributed deployment to get better numbers from your HPC system without the fancy interconnects, you might wonder whether to put your talk into the ‘HPC’ category or the ‘Web Frameworks’ category.
In cases such as this, it can be helpful to focus on the audience to help guide your decision. What do you think your audience would look like for this talk? Well, of course there are web framework authors and users who will absolutely be interested in the talk, but there isn’t a lot of gain for them in a talk like this, is there? I mean, what are the chances that someone in the audience has always dreamed of writing web frameworks for the HPC market? On the other hand, what are the chances that an HPC administrator, developer, or site manager would love to cut costs, ease deployment, reduce maintenance overhead, etc., of their HPC system by using a totally standard non-commercial web framework? There are probably valid arguments to be made for putting it in the ‘Web Frameworks’ category, but I can’t think of any. I’d put it in the ‘HPC’ category.
One more thing to consider is the other talks at the conference, or talks that could be at the conference, or talks from past conferences. Look at last year’s program. Where does your talk fit in that mix of talks? What talks would your talk have competed with? Is there a talk from last year that is similar in scope to your proposal? What category was it listed in?
Audience Level
There’s a ton of gray area in selecting your target audience level. I’ve never liked the sort of arbitrary “Novice means less than X years experience” formulas, so I’ll do my best to lay out some rules of thumb, but ultimately, what you consider ‘Novice’, and how advanced you think your material is, is up to you. Your choices are:
- Novice:
- Has used but not created a decorator and context manager.
- Has possibly never used anything in the itertools, collections, operator, and/or functools modules
- Has used but never had any issues with the datetime, email, or urllib modules.
- Has seen list comprehensions, but takes some time to properly parse them
- Intermediate:
- Has created at least a decorator, and possibly a context manager.
- Has recently had use for the operator module (and used it) and has accepted itertools as their savior.
- Has had a big problem with at least one of: datetime, email, or urllib.
- There’s only a slight chance they’ve ever created or knowingly made use of metaclasses.
- Has potentially never had to use the socket module directly for anything other than hostname lookups.
- Can write a (non-nested) list comprehension, and does so somewhat regularly.
- Advanced:
- Has created both a decorator and context manager using both functions and classes.
- Has written their own daemonization module using Stevens as their reference.
- Has been required to understand the implications of metaclasses and/or abstract base classes in a system.
- May be philosophically opposed to list comprehensions, metaclasses, and abstract base classes
- Has subclassed at least one of the built-in container types
Still not sure where your talk belongs? Well, hopefully you’re torn between only two of the user categories, in which case, I say “aim high”, for a few reasons:
- It’s generally easier to trim a talk to target a less experienced audience than you were expecting than to grow to accommodate a more experienced audience than you were expecting.
- Speaking purely anecdotally and with zero statistics, and from memory, there are lots more complaints about talks being more advanced than their chosen audience level than the reverse.
The Program Committee uses the category to insure that, within any given topic space, there’s a good selection of talks for all levels of attendees. In cases where a talk might otherwise be tossed for being too similar to (and not better than) another, targeting a different audience level could potentially save the day.
Extreme?
Talk slots are relatively short. Your idea for a talk is awesome, but way too long. What if you could give that talk to an audience that doesn’t need the whole 15-minute introductory part of the talk? What if, when your time started ticking down, you immediately jumped into the meat of the topic? That’s what Extreme talks are for.
I’d recommend checking the ‘Extreme’ box on the submission form only if your talk *could potentially* be an Extreme talk. Why? Two reasons:
- The number of Extreme slots is limited, and
- If your talk is not accepted into an ‘Extreme’ slot, it may still be accepted as a regular talk.
Duration
There are 30-minute or 45-minute slots, or you can choose ‘No Preference’. I recommend modeling your proposal around the notion that it could be in either time slot: your ability to be flexible helps the Program Committee to be flexible as well. If your talk competes with another in the process and the only difference of any use that anyone can find is that your talk has a hard, 45-minute slot requirement, you probably have a good chance of losing that battle.
If you’d like to have a 45-minute slot, then it might help you out to build your outline for a 30-minute talk first, and then go back and add bullet points to it that are clearly marked “(If 45min slot)” or something. Alternatively, you can create the outline based on a 45-minute slot, and just use the ‘Additional Notes’ section of the form to explain how you’d alter the talk if the committee requested you do the talk in 30 minutes.
Description
This is the description that, if your talk is accepted, people will be reading in the conference program. It needs to:
- Be compelling
- Make a promise
- Be 400 characters or less
Being compelling can seem very difficult, depending on your topic space. It might help to consider that you only need to be compelling to your target audience. So, while a talk called “Writing Unit Tests” is probably not compelling to the already-testing contingent at the conference, it might be totally compelling for those who aren’t but want to. Meanwhile, a talk called “Setting Up a local Automated TDD Environment in Python 3 With Zero External Dependencies” is probably pretty compelling to the already-testing crowd and not so compelling to those who aren’t yet writing tests.
Making a promise to the reader means that you’re setting an expectation in their mind that you’ll make good on some deliverable at some point in the talk. Some key phrases to use in your description to call out this promise might be “By the end of this talk, you’ll have…”, or “If you want to have a totally solid grasp of…”. The key that both of those phrases have in common is that they both imply that you’re about to tell them what they can expect to get out of the talk. It answers a question in every conference-goer’s mind when reading talk descriptions, which is “What’s in it for me?”. If you don’t answer that question in the description, it may be harder for people to guess what’s in it for them, and frankly they won’t spend a lot of time trying!
Abstract
The form expects a detailed description of the talk, along with an outline describing the flow of the talk. That said, it’s not expected that the talk you outline in August is precisely the same talk you deliver the following March. However, if your talk is accepted, the outline will be made public online (it will not be printed in the conference program), so you’d like to hit the outline as close as possible.
The abstract section will be used by the program committee to answer various questions about the talk, possibly including (but certainly not limited to):
- Whether the talk’s title and description actually describe the talk as detailed in the abstract. Will attendees get pretty much what they expect if they only read the title and description of the talk?
- Whether the talk appears to target the correct audience level. If you’re targeting a novice audience, your abstract should not go into topics that are beyond that audience level.
- Whether the scope of the talk is realistic given the time constraints. If you asked for a 30-minute slot, your abstract should not make the committee think that it would be impossible to cover all of the material even given a whole hour. It’s not uncommon to be a little off in this regard, but being really far off could be an indicator that the proposer may not have thought this through very well.
- Whether the talk is organized and has a logical flow that incorporates any known essential, obvious topics that should be touched on.
Additional Notes
This is a free-form text field where you can pretty much talk directly to the Program Committee to let them know in your own way why you think your talk is awesome, how you envision it coming off, and how you see the audience benefitting from it and finding value in attending the talk.
Although there are no hard requirements for this section of the submission form, you should absolutely, positively include any of the following that you can:
- If your talk is about a new software project, a link to the project’s homepage, repository, and anything other relevant articles, interviews, testimonials, etc., about the project.
- Links to any online slides or videos from any presentations you’ve given previously.
- Comments discussing how you’d handle moving from a 45-minute to 30-minute slot, or from an Extreme slot to a regular slot, etc. In general, it helps the committee to know you’ve thought about contingencies in your proposal.
Great, so… How do I do this?
If you’ve never written a proposal before, and you’re not sure what you want to talk about, don’t have a crystal clear vision for a talk, have trouble narrowing the scope of your idea, and don’t know exactly where to start, I have a few ideas that might help you get the proposal creation juices flowing:
- Write down some bullet points in a plain text file that are titles or one-line summaries of talks you’d like to see. Forget about whether you’re even willing or able to actually produce these talks – the idea is to start moving things from your brain onto a page. When you’ve got 5-10 of these points, reflect:
- Could you deliver any of these yourself?
- Could you apply an idea contained in a point to a topic you’re more familiar with?
- Is there a topic related to any of the points that touch on things you know well?
- Do any of these points jog your memory and make you think of projects you’ve worked on in the past that might be a source for a talk idea?
- Do an informal audit of what you’ve done over the past year.
- Were there problems you faced that there’s no good solution for?
- Did you grow in some way that was really important, and could you help others to learn those lessons, and learn why those lessons are important?
- Did you make use of a new technology?
- Did you change how you do your job? Your development workflow? Your project lifecycle? Automation? Task management?
- Go through the talks on pyvideo.org. It’s such an enormous, and enormously valuable trove. You could just scan the titles and see if something comes up. If that doesn’t work, click on a few, but don’t watch the talk: skip to the Q&A at the end. Buried in the Q&A are always these gems that are only tangentially related, and it is not uncommon to hear a speaker respond with “…but that’s another whole talk…”. They’re sometimes right.
Make it happen!