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 was held at 1PM EST, Friday April 2nd. irc.freenode.net, channel #pycon. Here is the PyConPostMortemIrcTranscript.

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.

Total Paid Registrants: 364 -(Trevor and Neal verified stat)

Ideas for next time

• When registering users, get permission to send them status e-mail (or to put them on a mailing list), and offer them a check box giving permission to add their name to a public list of delegates (to avoid privacy issues).
• 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 talks (so delegates can move from room to room, people can find seats)
• Session chairs should strictly adhere to the schedule

• 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

  • There hasn't been a huge amount of feedback, but I'm inclined to consider this change for the next year, if only to give us a proper basis for comparison and satisfy those who have agitated for it in the past -- sh

• non-PayPal online solution (iMeme is planning on implementing a WorldPay gateway for PyCON 2005)

• Do we need to use pycon.org?
• Do we need to use python.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

• Use Wiki on pycon.org

• Use a calendar/issue tracker ex: http://www.pycon.org/dc2004/zwiki/FrontPage/issuetracker.

• Early Bird should be publicized earlier, and promoted to previous attendees. Talks is not required...that is the incentive for the discounted rate.
• 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.

  • Little doubt that was a bad idea, though it was done for a specific reason. Access to the food was also limited, leading to long lines which we need to avoid in future years. The deli/sandwich idea was well received in terms of food quality, though, so let's make sure we don't throw the baby out with the bathwater - sh

• Sprint leaders should have lists of "odd jobs" (small bug fixes, tests, docs, etc.) for casual volunteers, to make best use of, and help motivate, 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.
• At least a day of tutorials for an additional fee.
• Suggested talks, don't just rely on proposals
• Offer free attendance to all acceptad speakers as incentive
• ALL talk's slides need to be posted ahead of time and that link needs to be documented at the beginning of each talk

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.

Responsibillities for Future Years

This is just a draft of things that have been identified so far, and is not cast in stone. Feel free to add other suggestions.

• Neal Norwitz could use some help on the accounting side

• Venue choice, ?preferably in DC? - see PyConVenue

• someone to run Open Space
• Lightning Talks coordinator

• someone to promote Birds of a Feather sessions (BoFs)

• session/track chairs under one manager
• sprint organizer and sprint chairs
• program committee
• sponsorship coordinator
• catering manager
• publicity and press relations manager
• web content manager
• developer for the submission system
• volunteers and a coordinator
• Wiki editor - there's so much information about this year's and last year's conferences we are in danger of losing the message among the noise. It would be a really valuable contribution is someone could make sense of everything for us and refactor it to make it more useful.
• Mailing list manager(s) - not a difficult job, but can be distracting