-
Notifications
You must be signed in to change notification settings - Fork 0
Program
How program works is (and should be) very much up to the Program Chair. What I'm going to describe here is a mixture of the general structure that I've applied when I've run it, and some specific things that have worked well (or not). The "I" in this page, at least at this time, is Benno Rice coming off the back of doing PyCon AU 2025. You should not feel chained to what is written here, and I've attempted to explain the "why" as much as the "what" so that you can try to get good outcomes out of whatever process suits you.
The goal of the Program Chair is to put together a collection of content that is informative, entertaining, and thought-provoking for the Python Community in Australia. What defines "the Python Community in Australia" is 100% vibes-based but presumably, since you're now the Program Chair, you've got a sense of what that vibe is. We want that group of people to have a good time at PyCon AU and while the Director and the rest of the Core Team are making sure there's a place for that to happen and that people are going to show up, the goal of the Program Chair is to arrange the presentations that they're going to see.
Along with this you're also a voice for the content side of things in other areas of the conference such as workshops and other conference events.
We've been using PreTalx for a while. It's worked well for us and fits will with the workflow we use, described below in the section on the CfP. We generally pay for the use of the hosted version and various people know the author/operator Tobi/rixx and can introduce you if you need to ask technical questions or get bugs dealt with. We've made heavy use of Google Sheets for Thunderdome and post-CfP tracking of things like waitlists and backup speakers. Any replacement tools should be considered in terms of how they fit the process you want to use.
The "traditional" PyCon AU program format consists of a day of specialist tracks, followed by two days of main conference. Specialist Tracks are where one of the venue rooms is given over to a group of people from a specific interest area and they will select the program for that room for that day. The Program Chair has veto power over what goes on in the track but I've never had to exercise it. The number of specialist tracks is generally the same as the number of presentation rooms being used for the main conference although depending on the venue it could vary, the main goal is to allow for some highly area-specific content selected by people who know that area well.
The "traditional" format also has lightning talks as the last hour of each main conference day. These are 5 minute talks that attendees will propose on the day, to be presented that day. More on them below.
The rest of this document assumes you're following something close to this structure. You don't have to, but I'd encourage you to remember The Goal. Likewise if this format doesn't seem to be meeting The Goal any more, it should absolutely be changed.
- Determine Specialist Tracks (should be done before CfP opens)
- Call for Proposals (must be complete 4 or more months prior to conference open)
- Finding and Locking In Keynotes (should be done as soon as practical)
- Recruiting Reviewers (can be done during CfP)
- Proposal Review (allow 2-3 weeks, starting after CfP close and final anonymisation pass)
- Thunderdome (allow one full day, ideally)
- Schedule Construction (should be ready ~3 months out from conference, will change)
- Lightning Talks (working out who's selecting, and who's hosting)
- Pre-Conference (everything between initial schedule release and conference open)
- Conference (on-the-ground cat herding)
The number of specialist tracks you have will generally be the same as the number of main conference rooms you have since they'll generally be using the same rooms. Once you know how many specialist tracks you're running (we've had 3 and 4 in the conferences I've been Program Chair for) you need to then work out who's running them. Various approaches have been used for this ranging from just asking people to run a pre-selected set of tracks to running a mini-CfP soliciting proposals for tracks from various groups and then selecting from those. In same cases this mini-CfP process has resulted in overlapping proposals and in some cases this has been resolved by seeing if the overlapping groups are willing to merge. Other ways of doing this are fine, so long as you're ending up with a group of specialist track organisers you have confidence in. Once you have your specialist track organisers locked in, then you're ready to open your Call for Proposals.
Before the CfP can open you'll need to have whatever tool you're using ready to go. In PreTalx this would involve creating the event and configuring the CfP for it, and assuring that someone on the committee (could be you but more likely should be the Treasurer or the Director) has made sure we've sorted out all the contractual and billing stuff.
If you're using PreTalx then there will probably be prior years' events you can look at to get an idea of how to configure your event. If you don't have access to that then badgering the previous year's committee or SteerCo should work. There's a bunch of event-specific settings that are reasonably obvious, and then there's settings specific to the CfP. The main things you're going to need to set up in the CfP section are a Session Type for your standard talk (traditionally a 30-minute talk), a Track for each of your specialist tracks as well as the Main Conference, and then the Headline and Text for the PreTalx CfP landing page. Then you should add your close date as the deadline, bearing in mind that we generally define our close time as a date "Anywhere on Earth" (AoE). The AoE approach avoids confusion over timezones but the way we generally implement it is to take midnight in the time zone with the largest negative offset from UTC, convert that into the local time of the conference venue, and set that time as the CfP deadline in PreTalx.
For review to work well, proposals should be as anonymous as possible. The CfP instructions should instruct proposers to avoid names, biographic details, and anything else that would clearly identify them. Unfortunately this can sometimes include projects where they are a sole contributor so they may need some help working out how to do this. Anonymisation can also be fixed on our side, more on that below.
We also add a bunch of Custom Fields that are important:
- Presentation-specific questions:
- Content warnings - Ask whether the proposal should have content warnings displayed in the program. It's a good idea to point to some guidelines on what kinds of content should have what kinds of warnings.
- AV Requests - Speakers should be able to assume we'll have the equipment to project slides from a laptop. If they need anything special like audio playback, live cameras, or whatever we need to know so we can work out how to do it, or if it's not workable.
- Speaker-specific questions:
- What pronouns do they use?
- What are their social media handles?
- Are they part of an under-represented community?
- Do they want to be on the announcements mailing list?
- Do they need financial aid to attend the event? IMPORTANT: It must be made clear that the speaker requiring financial aid will not directly inform whether their proposal is accepted. Acceptance comes first, and then if financial aid becomes a problem we may have to drop the proposal out in favour of an alternate.
- Legal butt-covering:
- The speaker(s) must assert to us that they have the legal right to present everything in their proposal.
- If we're doing live streaming we must get permission from the speaker(s) to do this. If we don't get it they can still present but we have to make sure they're not streamed.
- We must get permission from the speaker(s) to post recordings of the presentation under a CC BY-NC-SA license. Again, if they don't give this permission they can still present but we must not post a recording.
The main issue we've had with PreTalx around tracks is that PreTalx assumes that any given proposal is only going to be submitted to one and only one track. PyCon AU has traditionally been fairly flexible with tracks and is fine with the idea that people can submit to multiple tracks. In 2025 we tried having track selection as a separate Custom Field but inadvertently left the "normal" track selection enabled as well. This caused confusion. If PreTalx adds the ability to submit to multiple tracks then that would be fantastic, if not it may be worth trying a few ways of doing this to work out what the least confusing workaround is.
Lastly it's worth having a rough idea of how many proposals you're going to need. A one-day specialist track using our traditional 30-minute talk slots will need 10 presentations. The Education track has generally run a Student Showcase that fills several talk slots so they need less. A main conference day that starts with a keynote and ends with lightning talks will need 6 30-minute talks per room, so in 2025 with two days of talks across three rooms we needed 6 * 3 * 2 = 36 talks. The conference may want to sell some talk slots to sponsors so knowing how many of those are going to be sold, and thus deducted from the number you need, is important.
This will require coordination with whoever is handling marketing and/or communications since you want the announcement of your CfP to reach as many people as possible. You'll want to post to a bunch of mailing lists and social media networks. You'll also want to reach out to various local user groups, including getting people to talk about the conference and the CfP if possible. In keeping with The Goal, the goal here is to get as broad a selection of proposals as possible so you've got a really good pool from which you can construct the schedule. You're likely to get questions while the CfP is open as well, usually around things like subject matter or financial aid. It's good to respond to these promptly so they don't get lost.
Assuming you set the deadline in PreTalx the CfP will close at the time you set and you don't have to do anything. One thing to be aware of are that people will often ask to submit after close and they should generally be told that we don't do that. I'm not your Dad though (unless I am, but that would be odd) so you do what you feel is right. The bigger thing to be aware of as you come up to your close date though is whether you have enough proposals.
The "right" number of proposals is not really a thing but what you want is, firstly, enough to fill your program. In reality you need significantly more than that because you will 100% get proposals that you don't want to put on. You want enough proposals so that you can reject the ones that don't pass muster and still have enough left to fill the schedule. If you're getting close (a week out is a good time to check) to your CfP close date and you feel like you don't have enough proposals you can extend the CfP but this will eat in to your review time and possibly throw out things like planned Thunderdome dates. To extend or not is a very situational decision. 2025 was the first year PyCon AU extended its CfP and it was very much the right idea, however 2025 was running on a very compressed timeframe for Reasons™ and so had been running with, arguably, a too-short CfP to begin with. Do what you feel is right.
Our traditional review process has involved a first pass by reviewers where all proposals are anonymised. The people submitting proposals are not always perfect at ensuring their proposals are sufficiently anonymous though. PreTalx will hide the obvious identifying fields during anonymous review and it also allows authorised users to redact information in other fields. You and/or one or more designated people who are willing to sit out the anonymised review phase should go through all the proposals and redact anything that could be identifying. This can include:
- names
- institutions (e.g. a proposal once mentioned that the presenter was a student at a specific school)
- projects (e.g. where the presenter is also the sole contributor)
- links to prior presentations, or prior instances of the same presentation
PreTalx will indicate whether a proposal has been through the anonymisation review process by changing the icon next to it in the main list of submissions from a square to... some kind of secret agent looking thing.
This may be entirely your job or the Director may want to have some (or all) say in this. The timing of this is fairly independent of the CfP but it's really important to remember that people who are the kind of people you may want to tap as a keynote presenter may need to be approached a fair way in advance in order for them to be available. This applies even more to any overseas keynote you may want to get in, but an overseas keynote may also require the conference to pay for travel and accommodation and the budget may not stretch to that. We also, in general, would prefer to highlight local people where we can although sometimes an international keynote could be a good way to bring in a particular perspective or subject area. Beyond that this is, again, rather vibes-based. In general though, and in keeping the with vibes of the community, it's really important to ensure that you're not just going after straight, white, cis-men. If you need help coming up with possibilities, ask around. The local user groups could be good for ideas.
You are going to want a decently-sized pool of people to review all the wonderful proposals you just got. The expectation of reviewers is that they're going to review as many proposals as they can (ideally all of them, but that's 100% aspirational), and that they will provide some level of feedback into Thunderdome. That feedback can be nothing, it can be a list of proposals that they want to highlight (both positively and negatively), or it can be participating in Thunderdome itself (more on that later). Specialist Track organisers are automatically reviewers since they're going to be reviewing the proposals for their track but they're encouraged to review all the proposals since sometimes a proposal to one track (or to the main conference) may also be a good fit for another track (or the main conference) and so it helps if they're aware of these. Again, local user groups are a possible source of extra reviewers. Past speakers are also good candidates. The main criteria are that they have at least some understanding of the vibe of the community and that the overall pool contains as much diversity as possible so as to get the most diverse range of input we can.
Timing-wise the only constraint is that the reviewers be ready to go once the CfP has closed and the final anonymisation pass has been done. That said, reviewers can be added late but they'll have less time to do anonymised review.
The goal of this stage is gathering feedback from your reviewers that will inform which proposals are selected to go on your initial schedule, waitlists, and backup lists. How you do this is up to you but I'll describe how it's been done for the last several PyCons AU and you should use as much or as little as you want.
PreTalx allows users to be added to a review team, and allows review phases to be defined. We define two phases, the first anonymised and the second not. During the anonymised phase the reviewers are presented with the proposal with none of the indentifying fields visible, and any redactions applied during the anonymisation pass in place. The reviewer then assigns a score, represented as an integer between -2 and +2, and an optional comment. The meaning of the scores is as follows:
- +2 - I will fight for this proposal to be on the program
- +1 - I support this proposal being on the program
- 0 - I have no opinion on this proposal either way
- -1 - I do not support this proposal being on the program
- -2 - I will fight against this proposal being on the program
Once the anonymised review phase is complete, reviewers can go back and reassess their scores and/or comments.
We all have unconscious biases, whether we like to admit it or not, and we want to, in the initial phase, judge the proposal and not the speaker. Sometimes a well-known speaker may also submit a proposal that is weak and we don't want their profile to influence the review when a lesser-known speaker submitting a proposal of the same quality would not get that benefit. Both of these problems are solved by having an anonymous review phase. There are absolutely proposals where knowing who the speaker is, or what their background is, is an important factor in whether a talk is accepted but this is dealt with by having the second de-anonymised phase.