This page is for use by PyCon organizers to to record learning experiences from this year's conference, and to remember things that we could do better next time. Crosslinked to ["PyConDC2004Aftermath"] which might be the same thing with a less negative name.

A postmortem IRC session is scheduled for 1PM EST, Friday April 2nd. irc.freenode.net, channel #pycon.

Please record "concrete successes" in PyCon2004Successes. Start another page for "concrete failures" if needed? -- specifically not just negative feedback, but things that absolutely didn't work out.

Statistics

Pre-registered numbers: 340 attendees.

43 badges were never picked up. Some (10?) of these were for "Keynote Guests" added after registration, and therefore unpaid.

18 paid registrations on-site.

Ideas for next time

• When registering users, get permission to send them status e-mail (or to put them on a mailing list).
• When accepting proposals, request that users put their

  presentations under one of the [http://creativecommons.org Creative Commons] licenses, as [http://zak.greant.com/archives/000622.html the MySQL conference has done.]

• Put Lightning Talk sessions (one or two of them) in the program.
• Need more time between sessions

• Do feedback forms on the web (Shane McChesney's company [http://nooro.com/index.html Nooro.com])

• Schedule first day of Open Space before conference -- first day had hardly any Open Space going
• Put conference before sprint
• Have Sprints before and after the conference
• Make conference four days and sprint three days; last day of conference gears up for sprint
• Do we need to use pycon.org?

  • I found having two copies of information irritating, and the limited number of people who could update the pages was a bottleneck at times. Could we use the existing pydotorg CVS instead? --amk

    I'd rather use a Wiki whenever possible, or some system where people don't have to ask to update pages -- lac

    We definitely need to avoid the "battling web sites" phenomenon. This year we used pycon.org because, among other things, it allowed trevor to set up a Zope-based repository. I think there's room for a separate web site, but we'll take it under advisement -- SH

• Make sure that early bird registration deadline ends *after* all the papers have been accepted and the schedule has been created and posted for people to see.

  • This is mostly a matter of setting and sticking to the submission schedule -- SH

• Having the catering table in the back of the keynote room may not be a good idea; it's noisy when the staff refreshes the table in the middle of a talk.
• Sprint leaders should have lists of "odd jobs" (small bug fixes, tests, docs, etc.) for casual volunteers, to make best use of those who want to help but have limited time.
• Direct speakers to a breakout room after their talks if extended question time appears to be required.
• Think about opening the last afternoon to otherwise non-paying guests from education, government and industry and using the time to promote both the Python language and products writen in Python.

Tasks for next time

• Steve will chair one more conference; we need to arrange the succession for

  PyCon 2006. Perhaps having a vice-chair closely involved in next year's planning process would be optimal.

• Finish off and polish the conference software so that next year it doesn't have to be developed as capabilities are needed; having to do this resulting in our missing several promised deadlines and pushing things too close to the conference date.

  (AMK will do this. Please record ideas on [http://www.amk.ca/ng-arch/ConferenceSWIdeas this Wiki page], and join [http://www.amk.ca/mailman/listinfo/conf the conf mailing list] for discussion.)

• Design daily feedback forms for web input and fast analysis to allow day-by-day scheduling responses, repeats of talks many people missed, etc.