SpacePug

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.

TITLE

SpacePug: How Python 3 Launched The First Pug In Space

AUDIENCE LEVEL

Intermediate

DURATION

I prefer a 30 minute slot

BRIEF OUTLINE

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.

DETAILED ABSTRACT

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.

Why Python 3?

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.

A new library: multipugging

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.

A new test runner: treadmill

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.

ADDITIONAL NOTES

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:

Intro (5 min)
1. Who am I?
2. History of dogs in space
3. Explain why pugs are awesome for space
Why Python 3? (10 min)
1. GIL changes
2. Text/bytes distinction, PEP 393 improvements
3. Under active development (it’s the future)
multipugging library (10 min)
1. The problem: single feeder and cleaner doesn’t scale
2. The solution: distributed feeders and cleaners
3. Each pug gets their own food in their own space, less fighting for food
4. Live demo (4 min)
treadmill test runner (5 min)
1. Explain why other solutions don’t work and why we needed to write our own

Review

Brief Outline: Not bad. It simply sells the topic and draws in the audience and sets up what's going to be covered.
Detailed Abstract:
- Why Python 3: Covers two big issues with explanation, includes benchmarks for the Unicode stuff, knowledgeable of new features/PEPs. If done right, this could be good advocacy.
- multipugging: Live demos are really hard to do well. They provided time estimates in the additional notes and give 4 minutes for a demo. That seems like a lot of time for a demo, especially if it bombs.
- Test runner: No detail at all. Since it's generally not needed to rewrite your own test runner, it would be nice to have some head's up of why they needed to go down this path.
Additional Information
- Nice that it's open source. Has a good take-home value in that attendees can look up the code later on and learn more.
- First-time speaker but they're not totally new, uploaded slides look alright for a quick local talk.
- Outline is nice to have, and it shows they don't plan to have time for questions at the end. Although it's optional, the common convention is 25 minutes talking time and 5 minutes for questions. May want to reach out to the speaker to gauge their thoughts.

Summary

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.