Programming: Tracks and Session selection

farriss's picture

This thread is for all throughts about tracks and session selection. The group came up with the following questions to get the ball rolling:

  • How many tracks and sessions?
  • What is the right ratio of presentations and BOFs offerings to conference attendees? How do we determine more sessions vs larger rooms for sessions.
  • What should the tracks be?
  • Should there be track chairs and, if so, what are their responsibilities?
  • When should the call for submissions be opened? For how long should it be open?
  • How far out from the conference should the schedule be announced?
  • What is the right balance between offering popular (e.g. voted) sessions and curated cohesive conference program?

We'll be discussing this topic and the responses listed in this thread as a group at our next IRC meeting, October 1, 2009 from 11am-noon Central time.



Crell's picture

While a lot of conferences nail down their schedules 6 months in advance, Drupal moves too quickly for that to be feasible, IMO. However, the 2 week (or less) warning for DC Paris was also entirely unacceptable.

As a frequent speaker, I'd want to know at least 6 weeks out what I'm going to be presenting. That gives me enough time to properly prepare, but it's also not so far in advance that what I'm talking about is likely to change drastically. It also should be enough time for people who are waiting to book flights until they know the schedule to do so.

If we give track chairs 2 weeks to get sessions together (yes, we do want track chairs), that means we want all sessions submitted by 8 weeks before the conference. Figuring at least a month for session submissions, that means we open the call for papers around T-minus 3 months at the absolute latest. Expand as needed for each phase.

Track chairs should be responsible for curating the sessions for their tracks to ensure a good distribution of sessions within that track, and work with a session manager who is keeping an eye on all tracks to ensure a good distribution between tracks.

I'm not sure what the proper balance is between popularity and "planned coordinations" for sessions, except that it needs to be made a lot more explicit than it has been in the past. (That is, I don't think anyone knows what the balance is.) It's been suggested before to switch from "+1!" style voting to 5-star-esque ratings, so as to reduce the first-poster bias and the natural win-more problem where the higher rated sessions get noticed and therefore get more votes. I think that would be a very good idea.

I don't think we can reasonably have more than 6 rooms going at once, which is what DC had. More than that and even going to a session every time slot you'll barely be scratching the surface of the content, and DrupalCon is not yet big enough that you can have entirely separate wings with unrelated content a la SXSW. Even 6 is kinda pushing it there, especially if we intend for people to also go to unconference or BoF sessions.

My thoughts

gdemet's picture

I've been thinking about these issues for some time now, and am grateful for the opportunity to provide my thoughts. To provide some context, I've presented sessions at four Drupalcons, was one of the track chairs for Szeged, and have also presented at other tech conferences, including twice at SXSW Interactive.

  • I agree with Crell that setting the schedule 6 months in advance is a bad idea for Drupalcon, however, I think there are some aspects of session planning that can begin that early. Nearly every other conference I've spoken at begin at least some session planning several months in advance, even if the final schedule isn't finalized until a month or two before the event:
    • If there are specific speakers we want to invite (i.e.., keynoters and/or high-profile Drupal luminaries), the programming committee should secure their participation several months in advance of the conference. This will enable us to get more high profile speakers.
    • Likewise, if there are specific sessions that the programming committee would like to see offered at Drupalcon (e.g., a beginner's training workshop), they should be able to begin recruiting speakers for those sessions months in advance of the event.
  • Publicly-submitted session proposals need to occur further in advance of the event than they have in the past, and the deadline for publicly-submitted session proposals needs to be well-advertised and strictly enforced, which has also not consistently happened in the past. That's the only way to be fair to everyone.
  • Right now, the date that sessions are announced often occurs after all the tickets have sold out, which sucks for folks whose attendance may be contingent on whether or not they're speaking. I know there was at least one high-profile speaker for Paris whose session was selected, but had to be canceled at the last minute because she couldn't get a ticket in time to make travel plans. We need to either provide speakers with complementary tickets, or make sure enough are set aside to ensure that all selected speakers are able to attend.
  • I'd like to see more questions asked as part of the session proposal process, including a list of what sessions the presenter has given at past Drupal events (camps, cons, etc.), so that conference programmers can have a better sense of the presenter's public speaking experience and follow up on the quality of past sessions they've presented.
  • In addition to asking for description, level, and audience, I'd also like to see the session proposal form ask for a list of 7-10 "questions that we'll try to answer in this session", as well as a field asking what specific things attendees will be able to take away from the session. This information will make it easier for the track chairs and/or programming committee to identify session proposals that have had a lot of thought put into them, as opposed to something that was just whipped together before the deadline
  • In terms of how sessions are selected, I think we should adopt a formula similar to that used by SXSW, where an advisory board's recommendations count for about 40%, the event staff's about 30%, and public voting about 30% of the overall decision-making process. I think adopting a clearly and publicly defined formula for Drupalcon that incorporates public votes, along with the recommendaitons of track chairs, and a larger programming committee would allow us to make better decisions about session programming earlier in the process.
  • Public voting, regardless of whether it's a +1 or 5-star, should not begin until after all the proposals are in, and no new sessions should be added while the voting is ongoing!! We've seen time and time again that sessions submitted early get the most votes, and the results are of almost no value to the people responsible for selecting sessions. Public voting needs to take place during a distinct period separate from the session proposal period.
  • After sessions are selected, conference staff should check in regularly with presenters to make sure their session preparation is going well and to offer assistance if needed. One of the things that I really like about SXSW is that they have a volunteer (separate from the conference programmers) who regularly keeps in touch with presenters via e-mail to answer any questions they might have and offer suggestions as needed. If the presenter is unresponsive, or if it sounds like they're having problems of some kind, that volunteer is able to let the conference programmers know soon enough in advance so they can provide assistance or make changes as needed.
  • Inexperienced speakers should have the opportunity to receive mentorship from people who have spoken at past Drupalcons well in advance of the event. The session that Emma Jane did before Drupalcon DC was great, but we need additional opportunities earlier in the process for people to get advice on presentation technique and content from people who have been there before.
  • I'd like to see post-session audience evaluations, either through an online voting system restricted to registered attendees, or by passing out evaluation cards and pencils that get collected by volunteeers at the end of each session. The later method ensures higher participation and better results, but requires more resources and coordination than an online system. Attendees should be asked to rate the quality of the speaker, the usefulness of the session, and have the ability to make comments. The results of these evaluations should be availble to future Drupalcon program planning committees to use when selecting speakers for their events.