├── README.md ├── presentation_slides.md └── talk_proposals.md /README.md: -------------------------------------------------------------------------------- 1 | # PyCon Best Practices 2 | 3 | This repository contains best practice guidelines for a number of topics relating to [PyCon](http://us.pycon.org/). It is an effort to document things that help make each PyCon a great conference. 4 | 5 | ## Contributing 6 | 7 | If you have guidelines to contribute, please do one of the following: 8 | 9 | * If what you're proposing is widely accepted as the best practice of a particular topic, you can submit a pull request. 10 | * If what you're proposing is one of two ways to handle a particular topic, you should submit an issue or start a discussion thread on the relevant PyCon mailing list. However, if you fully understand and can fairly represent both sides, a pull request may work. *Note: there should be very few of these two-way entries.* 11 | * If there are more ways to handle the topic, there is no best practice for it. 12 | -------------------------------------------------------------------------------- /presentation_slides.md: -------------------------------------------------------------------------------- 1 | The following best practices are useful when creating slides for presentations at PyCon. They're gathered from conversations with attendees and speakers alike, and they can help provide a nice experience for your audience. 2 | 3 | ## Aspect Ratio 4 | 5 | The projectors currently used at PyCon are set to a 4:3 aspect ratio, so configuring your presentation software with that setting (often the default) will produce the proper slide size. 6 | 7 | ## Code 8 | 9 | The Zen of Python says "Readability counts." Since you're presenting on Python, including code examples at some point in your presentation is likely. However, including code can be different than any of the other text-based slides you'll write. 10 | 11 | ### How much code 12 | 13 | Generally, fewer words on slides are better, and the same goes for lines of code. **It's better to optimize for readability over correctness by including small snippets of code.** Consider sharing a link to complete working example code that you've uploaded on the web rather than including a long function. 14 | 15 | While you're building your slides, take a few steps away from your screen to emulate being toward the back of your presentation to see if you can actually read it. 16 | 17 | ### Colors 18 | 19 | We commonly hear that code slides are hard to read, thanks to a number of factors -- some a presenter can control, some they can't. **One way to take control and provide the most readable slides is by choosing to present code with dark text on a light background.** 20 | 21 | While other color schemes work well in other environments, the combination of our room layouts, lighting, and projectors make for a situation where not all colors work equally well. 22 | 23 | ### Syntax Highlighting 24 | 25 | Syntax highlighting is helpful while you're writing code, but it doesn't usually add value to a short snippet of code on a slide. The readability of dark text on a light background goes further than attempting to match the code editors we often use. 26 | 27 | ## Vertical Alignment 28 | 29 | For the benefit of people in the back of the room, consider how much content you're putting on each slide. While everyone can see the top of your slides, not everyone can see the bottom. 30 | 31 | Bryan Veloso gave a lightning talk at PyCon 2012 titled [Recruiting Designers for your Open Source Project](https://speakerdeck.com/bryan/recruiting-designers-for-your-open-source-project) with "for the benefit of the people in the back, I refrained from putting anything important here" taking up the bottom portion to shine light on the fact that people might be missing out on those last few lines of a slide filled with content. -------------------------------------------------------------------------------- /talk_proposals.md: -------------------------------------------------------------------------------- 1 | The following best practices are useful when submitting a talk proposal for PyCon. They're gathered from members of the Program Committee, who are tasked with creating the schedule of talks. 2 | 3 | ## Deadline 4 | 5 | The deadline for PyCon 2016 proposals is . 6 | 7 | As much as possible, try to submit your proposal as early as you can in the call for proposals to take advantage of the program committee's reviewers. By submitting early you gain an advantage that later submitters don't get: the reviewers will provide constructive feedback to help you make a better proposal, which you can then apply to the proposal before they're evaluated both individually and in comparison to other similar proposals. 8 | 9 | ## Proposal Fields 10 | 11 | The PyCon proposal form contains several fields to describe your topic, approach, and any supporting details. 12 | 13 | ### Title 14 | 15 | A couple of words represent all of the work you put into a proposal; your slides, the rehearsals, and everything else about it. The title is your chance to attract people, and it's also one of the few ways to find your presentation after you give it. 16 | 17 | * Substance is often more valuable than flash. If your title doesn't allude to the topic you're talking about, you may need to spend more work in the description to hook people. 18 | * Try to keep it short. A full sentence title is often harder to remember, thus harder to search for. 19 | 20 | ### Duration 21 | 22 | PyCon has a limited number of 45 minute talk slots, and asking for one is merely a suggestion to the program committee chair who constructs the schedule. If you think you have a 45 minute talk, go ahead and select it, but be aware that it might not fit in the schedule and you may instead be offered a 30 minute slot. 23 | 24 | ### Description 25 | 26 | Your description will end up both in our printed program and in the online schedule. It's limited to 400 characters, so it's a nice supplement to your title. 27 | 28 | A few sentences to introduce the topics and goals of your proposal will make for a good description. 29 | 30 | ### Audience 31 | 32 | Since PyCon attracts a wide range of people across a broad range of skill sets, you're going to end up with some attendees who are learning your topic for the first time, some who know *about* it, some know it, and sometimes even the people who created it. Who do you want to reach out to the most of all? Who do you want to hear questions from at the end? 33 | 34 | ### Python Level 35 | 36 | Be as accurate as you can be. A lot of people come into PyCon looking for talks that will help them level up, so you may get a beginner who is going to try and attend a bunch of intermediate talks and push themselves. If we're all fairly accurate, we can put information in that person's hands that is within reach to help them learn. 37 | 38 | ### Objectives 39 | 40 | What do you want people to get out of your presentation? Think about what you'd want to talk about in the hallway or at lunch with your talk's attendees. What do you want your attendees to tell their friends about? 41 | 42 | ### Detailed Abstract 43 | 44 | This text ends up on our website, clickable from the schedule and talk lists. This is where you explain in paragraph form what you're going to talk about for 30-45 minutes. 45 | 46 | Let readers know why you're giving this talk. Why is the topic important? What are the issues surrounding the topic? What are solutions to those issues? This is where you expand on the short [description](#Description) you started with. 47 | 48 | This field is Markdown enabled. 49 | 50 | ### Outline 51 | 52 | The outline helps reviewers get a feel for your level of preparedness on the topic as well as how organized your thoughts are in covering the topic in a live presentation. If you've thought about how much time you want to spend in a particular area, listing the timings can be helpful. 53 | 54 | You don't need to have your presentation finalized when you're proposing it, so don't worry if the outline isn't fully finalized. 55 | 56 | This field is only visible to reviewers. 57 | --------------------------------------------------------------------------------