Here's a sample talk proposal for a fictional project called SpacePug by the Animal Aeronautics and Space Administration. They use Python for everything, and they put pugs into space.
It's a good proposal, but it's not perfect. It does some good things, and some bad things, and we'll let you know what could be done to improve it.
TIP: The format below follows what you need to enter on https://us.pycon.org/2013/proposals/submit/talk/ when writing your own proposal.
SpacePug: How Python 3 Launched The First Pug In Space
I prefer a 30 minute slot
When the Soviets launched Laika the dog into space in 1957, the first question on many minds was, “but when will a pug be in space?” That time is now thanks to the Animal Aeronautics and Space Administration’s latest multi-bazillion bitcoin project, SpacePug.
All of SpacePug’s systems run on Python 3, and this talk aims to explain the choice for 3, the introduction of a new library, and detailed discussion of a new test runner. Complete with a live demo, you’ll get to see what goes into sending the crew of three - officers Buster and Tobias, lead by Captain Barry Zuckerkorn - into space.
Built entirely on Python 3, the SpacePug project is one of the first major projects to run on Python 3, and it’s the first to launch pugs into orbit.
Years ago, developers made an attempt to build a system on Python 2, but they found that it just wasn’t good enough to launch a dog into space, let alone a pug. One of the first problems they encountered was the GIL and the fact that the thrust controllers didn’t perform well enough to launch a dog of short, stocky stature. After switching to Python 3.2, which has an improved implementation of the GIL, the thrust controller performed so much better that analysis shows pugs could potentially join the Curiosity rover on the surface of Mars.
The astropugs are able to communicate back to mission control via a special keyboard to speak their language, represented in a previously unassigned Unicode plane. While developing the communications systems, the developers found that Python 3’s distinction between bytes and text makes their code more readable and easier to understand. They prepared benchmarks comparing a Python 2.7 implementation against a Python 3.3 implementation to show the 3.3 version is more memory efficient thanks to PEP 393.
Early versions of the project only supported one pug per spacecraft. Feeding and cleaning up after multiple pugs was a significant issue, so much that early testing sent the engineers back to the drawing board to start from scratch. In comes multipugging, a system to control multiple feeders and cleaners, removing the common bottleneck of dealing with the needs of multiple pugs in orbit.
This talk will show a live demo of multipugging scaling out to feed 16 pugs at once.
Everyone knows the first thing a project should do is write their own test runner, so we did just that with treadmill. It’s like putting a pug on a treadmill, but for code.
SpacePug is entirely open source software. You can check out the source tree at rcs.aasa.gov/pugware
This would be my first time speaking at a conference like PyCon. I’ve spoken at my local user group a few times and may have the opportunity to give a practice run to my local group. I have posted slides of past talks on my site at www.pypug.net/presentations.
Here’s what I’m thinking for timing:
This proposal gives a good look at what's going to be presented. It gives the reviewers a good indication that the proposer has thought this out, has thought about timing, and seems to have a good grasp on what people might want to know about the project. It does leave some open questions.
What's the backup plan for the live demo? If it falls apart, that's four minutes the audience might lose out on. Especially for a relatively inexperienced speaker, it would be nice to know what the backup plan is if the live demo starts to fall apart. In this silly proposal, consider the pugs as hardware. Many hardware related talks at PyCon have skipped the live demo and instead shown video, and they're some of the coolest talks we've seen. For example, see David Beazley's SuperBoard talk in 2011 and Kurt Grandis' squirrel-shooting computer vision talk in 2012.
Leaving time for questions isn't a hard requirement, merely a convention, so it would be nice to hear from them that they acknowledge that they'd be foregoing the Q&A. Additionally, a reviewer would probably want to know more about the test runner section because it's light on details, especially when you put it side-by-side with the other sections.