PyCon 2016 in Portland, Or
hills next to breadcrumb illustration

Proposing a Talk

To learn how to submit a proposal, visit the [main Speaking page](! This document is a guide to help you submit the best possible proposal, and offers tips to make your proposal more likely to be accepted. Please keep in mind that many more proposals are submitted for talks, tutorials, and posters than can be accepted. But following the recommendations provided here can increase your chances of acceptance. # Topics and Advice Recent articles, blog posts, tweets, and open source projects from the community can be a good source of topics and ideas, as can your own experiences as a developer. What do you wish someone had told you when you were starting out? What learning process has been the slowest or most frustrating over the past few years, and could you put together a talk that would short-circuit that whole process for the next Python developer who tackles the same problem? As you consider different topics, you might be interested in reviewing the slate of talks selected to appear at PyCon in previous years: * PyCon 2015 Talks * PyCon 2014 Talks * PyCon 2013 Talks * PyCon 2012 Talks There are also community members who have blogged about the talk proposal process. Here are a few of the most prominent resources, and a Google search will yield you several more: - [How to Get Your Talk Into PyCon]( — from Ned Jackson Lovely, chair of the talk selection committee for 2016! - [Rejected PyCon Proposals]( — Allison Kaptur (2014) - [Example PyCon talk proposals]( — Brandon Rhodes (2013) - [Pro Tips for Conference Talks]( — Craig Kerstiens (2012) - [How I Review a PyCon Talk Proposal]( — Doug Hellmann (2011) And another entire list of resources and links is maintained at the PyLadies blog: - []( # Good Ideas * **Submit your proposal early.** The program committee will provide feedback to talks in our system, and we _will_ work with you to improve your proposal if we have issues with it, but we can only do this if your talk is in before the deadline. * In your abstract, be sure to include answers to some basic questions: * Who is the intended audience for your talk? (Be specific; "Python programmers" is not a good answer to this question.) * What will attendees get out of your talk? When they leave the room, what will they know that they didn't know before? * Your outline should be an _enumeration_ of what you intend to say, along with time estimates. * It is not necessary to have completely written or planned your talk already, but you should have a basic idea of what the over-arching points you intend to make are, and roughly how long you will spend on each one. * If you are requesting a 45-minute slot, remember that these are in very limited supply. Be sure to explain how you will change your talk if we can only offer you a 30-minute slot. * Ensure that your talk will be relevant to a non-trivial set of people. If your talk is on a particular Python package or piece of software, it should be something that a decent number of people use or want to use. If your talk is about a package that you are writing, ensure that it's gained _some_ acceptance before submitting a talk. * Include links to source code, articles, blog posts, or other writing that adds context to the presentation. * If you've given a talk, tutorial, or other presentation before, especially at an earlier PyCon or another conference, include that information as well as a link to slides or a video if they're available. * Fill out your outline and biography completely, but concisely. The outline and background information often are used to eliminate proposals during the first cut, so incomplete details may be a cause for early rejection of a potentially great talk or tutorial. Don't let this happen to you! # Bad Ideas * Avoid infomercials. * That doesn't mean you can't talk about your work or company at PyCon. For instance, we welcome talks on how you or your company solved a problem, or notable open source projects that may benefit attendees. * On the other hand, talks on "how to use our product" (or similar) usually aren't appropriate. * Avoid presenting a proposal for code that is far from completion. The program committee is _very_ skeptical of "conference-driven development". * Avoid "state of our project" talks, unless you can make a compelling argument that the talk will be well-attended and that attendees will gain value from it. * Do not assume that everyone on the Program Committee will know who you are simply because you have presented at PyCon in the past. Everyone should submit a full proposal.