Proposal Advice

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.
  • 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 PyTennessee 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 PyTennessee. 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 a conference in the past. Everyone should submit a full proposal.

Sponsors


Site powered by Symposion.
"Python" and the Python logos are trademarks or registered trademarks of the Python Software Foundation, used by PyTennessee with permission from the Foundation