The PyCon 2016 call for proposals opens today. Do you want to speak? I want it, greedily—I'm greedy for speaking at software conferences, because I'm greedy to connect with you, and standing on stage is a sure way to start the discussion. The best stuff comes after I give the talk.

In the last year my proposals performed well and my greed was indulged by conference committees. I was accepted by PyTennessee, PyGotham, OSCON, QCon, MongoDB World, and Open Source Bridge, and I got two talks into PyCon 2015. In gratitude, I'll tell you what I learned about submitting talks.

Your Topic

Make It Fun

Convince the organizers that your talk will be:

• Entertaining
• Of broad interest
• Educational

More or less in that order.

Do not confuse academic conferences with software conferences like PyCon. In academia, you convince the organizers that your research is a substantial advance in the field. No one cares, I hear, whether your talk will be good. Your specialist expertise is what qualifies you to speak. A talk about your great hack is welcome.

Software conferences, on the other hand, want great talks. You need not be an expert, and you certainly do not need to present original research. In fact, most original research is a terrible topic for conferences because it is not entertaining or of broad interest. The goal is to have talks that are fun, and appeal to a large proportion of attendees. Maybe they also teach a tiny bit, or not.

Be General And Basic

We are all specialists, but a talk on your specialty is very unlikely to be accepted. Certainly my proposals on the areas of my expertise have been widely rejected. I hope you write an article instead of proposing a talk; an article is where your special expertise is valuable.

Submit about three proposals to each conference. My colleague Emily Stolfo taught me to hedge my bets this way. Your proposals should range wide: a basic general talk, an intermediate talk, and a non-technical talk. (Non-technical topics include management, mentoring, self-care, diversity, ethics, business, and so on.) There is a good chance that one of your three proposals fits an undersupplied track in the organizers' agenda.

Do not submit an advanced talk. For one thing, advanced topics are usually specialized topics, and what you call "advanced" is too specialized for any software conference. For another, advanced topics cannot be covered usefully in a half-hour talk. In fact, what you think is "intermediate" is probably too advanced. Please write these ideas as articles instead, I look forward to reading them. For talks, stick to basics.

... Or Get On Your SoapBox

The goal of this advice is to get your proposal accepted, of course. But you may have a different goal in mind: to communicate an idea. If you are passionate about an idea then you should certainly propose a talk about it. I proposed my mentoring and writing talks to conferences, not so much because I expected it to be popular with organizers, but because I care about the topic and I want to express my opinion to you. I give my weather visualization talk regularly because I want people to know how well MongoDB and NumPy work together. Several talks at last year's PyCon were intended to advance an opinion: Glyph exhorted us to develop a code of ethics, Carol Willing convinced us we could all contribute to famous projects, and Kate Heddleston argued we must fix our workplaces to ensure diversity.

These were some of the best talks. After all, giving a speech about how some code works is bound to be troublesome, and we are still refining the form. But in human history there is no more compelling nor more honored method than a speech to deliver an argument.

Title

Moldy Snowclones

Certain phrases are deprecated and will be removed from the next version of English. "For fun and profit" is the worst by far, but "Zen and the art of", "demystifying", "real-world", "at scale", "the hard way", "in production", and "beyond" are cliché, too.

Since you are banned from these moldy snowclones, you must instead determine your talk's thesis and state it engagingly in the title. See the submissions for Open Source Bridge's Call For Proposals last year for inspiration: many are novel and will encourage you to be original and precise when you title your talk, too.

Vague And Specific

Hilary Mason writes:

Your title should be both vague and specific. A vague title offers you a lot of flexibility in altering the content of your talk as conditions change without betraying the expectations of the audience based on the materials published earlier. But if your title is too vague ("Stuff and Junk") people won’t be excited for your talk, and you’ll lack an audience entirely or won’t make it through the CFP process at all. Be specific about the frame of the talk, but leave the details vague.

Abstract

Prove You Prepped

Hilary's "vague and specific" is right for your title, but for the abstract you should be very specific. It's ok if you stray from it by the time you deliver the talk. For example, my abstract for Eventually Correct: Testing Async Apps at PyCon promised four subtopics, but my talk covered only one. No one complained.

Your abstract should be a half-dozen paragraphs, perhaps 400 words, and should demonstrate by its detail that you have thought hard. The conference organizers do not want to waste slots on underprepared speakers. An underprepared abstract is their first warning. Show you are willing to put in the time to make a great talk.

At the same time, organizers do not want speakers to go over time, so be realistic about what you can cover. How do you learn to estimate? Choose a video of a well-delivered talk that is close to your target length, and read its abstract. Even better, write an abstract of that talk. PyCon 2015's 30-minute and 45-minute talks are all available on YouTube. If you are new to speaking at conferences, I recommend you write abstracts of what was covered in a few of the best talks. Once written as an abstract, it is clear how slimly fitted a good talk must be.

Revise Ruthlessly

I write the abstract like any substantial work: I spend a few days brainstorming and talking to friends until I have a long list of subtopics. Then I choose the best and try to order them sensibly. If the best cannot hold together, I swap subtopics in and out until they do. The thesis of the proposal improves as I work on the abstract. For example my mentoring talk for PyTennessee evolved from "how to mentor" to the more operative "how to design a mentorship with the prerequisites for success." Once complete, the abstract is a good first draft of the talk itself. It is also a draft of an article on the topic.

Allison Kaptur maintains a repository of PyCon proposals with contributions from several speakers. Both the accepted and rejected proposals are examples of good abstracts.

Note To The Organizers

PyCon's CFP forms give you a text box to talk directly to the committee. Tell them your speaking experience, link to positive tweets about your previous talks, and share any videos of yourself speaking—you want to show you have been well-rehearsed, entertaining, and educational at previous conferences, and that you can meet your time limit. Your expertise on the topic is relevant, too, and this text box is the sole location on the form where it is appropriate to show your bona fides. But even here, subject-matter expertise is secondary to your expertise at speaking.

If you are green, on the other hand, highlight that. Conference organizers like to give opportunities to green speakers. But you must argue from related experience that you are up to the challenge. Maybe you have given internal talks at your company or led a recitation in college. There may be time to speak at a local Meetup before the CFP is due, to expand your record.

Time Slot

Some conferences offer several durations; shoot for the abundant one. PyCon's handful of 45-minute slots, for example, are even more competitive than their regular 30-minute slots, so ask for a 30-minute slot when you submit your proposal. If "any length" is an option, choose it, and in your note to the organizers explain how you will adapt the talk to a short or long slot.

The tutorials that precede conferences like PyCon and OSCON are less competitive. Propose a tutorial if you want to get your foot in the door, or you want to teach a topic in depth including a hands-on lab.

Get Help

Get critique from your colleagues, especially those whose own proposals perform well. For each new proposal I submit, I ask for comments from a few trusted advisors, and I ask at many stages: the raw idea, the early draft, and the nearly-final one. Google Docs is a good medium to share and comment.

I've learned which friends give frank criticism, and I return to them. A great critic will tell you hard facts: my proposals have begun boastful, or incomprehensible, or boring, and through review I fixed them. Sometimes I abandon an idea if a friend talks me out of it.

Reduce, Reuse, Recycle

I maintain a folder of completed proposals in Google Drive. When a CFP comes up, I may already have three relevant proposals for it. I keep a list of incomplete ideas, too. My speaker bio is in a separate file, along with a speaking resume to put in each proposal's "note to the organizers". Here it is. When I actually submit a talk, I cut my speaking experience down to just a few relevant lines.

A proposal begins life in the ideas list, and I complete it when I need it for a CFP. After that I keep using it. If it is repeatedly rejected by conferences I thought it was good for, I give up on it.

I turn most proposals into articles at some point, even ones that aren't accepted as talks, since a detailed abstract is half way to an article. Waste not, want not.

Lately I record screencasts of my talks before delivering them at conferences. For example here is a screencast of my PyCon talk "Eventually Correct: Testing Async Apps". The advantage of a screencast is that I can do it again until it's good. Even better, I closed-caption my own screencasts for the sake of Deaf viewers—conferences rarely caption videos, and my own captions will always be best.

If a proposal performs well I reuse it for a year or two. Eventually I get tired of a talk, or organizers stop wanting it. Committees like a talk with a track record, but not once it's overexposed. Its time in the sun is brief. If I am fortunate enough to give a talk at a couple big conferences I retire it.

If you can make it at PyCon you can make it anywhere. Their CFP is the most rigorous I have seen. This year's long window for submissions, September 28 through January 3rd, will make it even more competitive. But PyCon also provides the most guidance. Read their proposal advice and Brian Curtin's commentary last year in full; these articles are deeper and better than mine. For tactical insight into the selection process and criteria, see committee chair Ned Jackson Lovely's PyCon Process article.

Next: Why Should You Speak At A Conference, Anyway?

Image: Emmeline Pankhurst, British suffragette, in 1916, exhorting men to volunteer for the army.