There are only two weeks left before PyCon tutorial proposals are due! If you have ever dreamed about delivering a valuable 3-hour tutorial in front of dozens of fellow PyCon attendees, you can read more about the proposal process here:
https://us.pycon.org/2016/speaking/tutorials/
You might have been pondering a question as you finished reading my post last week. It celebrated PyCon 2016’s more aggressive schedule, which moves the proposal deadlines closer to the date of the conference. But you might have been puzzled that there are now two separate dates:
The difference between the two dates is more than a month. Why aren’t talks and tutorial proposals simply due on the same day?
The answer is that the tutorial selection process is not as compressible as the process for talks. To understand the difference, first consider the task faced by the talk committee:
Each talk that the program committee selects is therefore going to be a relatively low-risk choice for the conference as a whole. They will be choosing from among the many proposals that look great, for a time slot that is only a small fraction of the whole conference, and that will not cost you anything if you pop into a talk for a few minutes but it winds up not meeting your expectations based on its description.
And so the talk program committee, equipped with new streamlined review software that replaces the grueling IRC meetings that the committee previously suffered, agreed to try tightening its schedule this year by nearly two months. I am going to do my best to support them!
The tutorials committee, by contrast, faces a quite different situation.
The tutorial selection process therefore carries higher risk for the conference. Every tutorial needs to deliver something very close to what its description promises — there can’t be any over-the-top claims in the abstract that fail to be delivered in the tutorial itself.
This leads the tutorials committee, burdened as they are by this extra level of trust — PyCon attendees are going to pay for every tutorial they approve! — to adopt a slower and more careful process. One of the volunteer tutorial chairs this year, Ruben D. Orduz, explained it to me this way:
I think that the difference in dates make sense overall. The January deadline for talks keeps us open for as long as possible to new technology and recent developments in the Python community. The earlier deadline for tutorials reminds us that the best tutorials are likely to be about well-established topics — the subjects that will make safe and productive tutorial topics for PyCon 2016, after all, will probably not depend on software or news that only emerges in December!
https://us.pycon.org/2016/speaking/tutorials/
You might have been pondering a question as you finished reading my post last week. It celebrated PyCon 2016’s more aggressive schedule, which moves the proposal deadlines closer to the date of the conference. But you might have been puzzled that there are now two separate dates:
- Tutorial proposals are due: 2015 November 30
- Talk and poster proposals are due: 2016 January 3
The difference between the two dates is more than a month. Why aren’t talks and tutorial proposals simply due on the same day?
The answer is that the tutorial selection process is not as compressible as the process for talks. To understand the difference, first consider the task faced by the talk committee:
- Talks are completely free for PyCon attendees. You can walk into a talk, decide that you might be more interested in the one next door, and (quietly!) slip out.
- Most talks last 30 minutes — a few are given 45 minutes — so a reasonable amount of solid, well-organized material will usually be enough for a talk to make good use of its slot.
- The primary problem that the talk committee faces is volume. Hundreds of talks are proposed for which there are only about 95 slots available. A large proportion of the proposals are very good ones, and would make great talks if admitted to the conference.
Each talk that the program committee selects is therefore going to be a relatively low-risk choice for the conference as a whole. They will be choosing from among the many proposals that look great, for a time slot that is only a small fraction of the whole conference, and that will not cost you anything if you pop into a talk for a few minutes but it winds up not meeting your expectations based on its description.
And so the talk program committee, equipped with new streamlined review software that replaces the grueling IRC meetings that the committee previously suffered, agreed to try tightening its schedule this year by nearly two months. I am going to do my best to support them!
The tutorials committee, by contrast, faces a quite different situation.
- Each tutorial costs money for its attendees. Last year the cost was $150 per tutorial for those who signed up ahead of time, and $200 for those who sign up on-site. For many PyCon attendees this is a weighty expense, and therefore a severe blow if they pay for a tutorial but it winds up not meeting their needs.
- A tutorial lasts a full 3 hours, split into two 1½-hour segments separated by a coffee break. Each tutorial’s material must use this full amount of time effectively, or attendees will feel cheated out of the full three hours of instruction that they were expecting.
- Each tutorial proposal will cover roughly 6 times the material of a typical talk, which makes for slower reading even if the proposal summarizes their material more briefly.
The tutorial selection process therefore carries higher risk for the conference. Every tutorial needs to deliver something very close to what its description promises — there can’t be any over-the-top claims in the abstract that fail to be delivered in the tutorial itself.
This leads the tutorials committee, burdened as they are by this extra level of trust — PyCon attendees are going to pay for every tutorial they approve! — to adopt a slower and more careful process. One of the volunteer tutorial chairs this year, Ruben D. Orduz, explained it to me this way:
“The number of reviewers is not our bottleneck. The issue is that we don’t accept or deny tutorials outright unless they are truly unsalvageable or already perfect. Instead, we go through each of the proposals, carefully, and we reach out to the authors. The authors are given a week or two to fix things we think will make their proposal even better. Then we go back and re-review them.
“It’s a very time-consuming process, but it helps in selecting the best lineup while making sure every tutorial that had potential was given a fair chance. Compressing the timeline would mean only selecting from the top well-known proposers and forgetting the rest. That would be against our philosophy of giving chances to new instructors and increasing diversity.”Given these differences in risk and process, I thanked the tutorials committee for being willing to shorten their process from 4 months to 3 months this year, and agreed that they should not try to compress their schedule any further. And so the result is that, for the first time, PyCon talk and tutorial proposals are due on different dates, each as close to the conference as the volunteers on each committee can safely manage.
I think that the difference in dates make sense overall. The January deadline for talks keeps us open for as long as possible to new technology and recent developments in the Python community. The earlier deadline for tutorials reminds us that the best tutorials are likely to be about well-established topics — the subjects that will make safe and productive tutorial topics for PyCon 2016, after all, will probably not depend on software or news that only emerges in December!
Comments