[EuroPython] Python conference software
jacob at strakt.com
Wed Jan 25 17:38:57 CET 2006
onsdag 25 januari 2006 10.16 skrev Michael Hudson:
> Aroldo Souza-Leite <asouzaleite at gmx.de> writes:
> > Hi list,
> > a Python software solution for the Europython conference would be cool.
> > If there is someone (Joachim Schmitz) prepared to configure it using the
> > experience of the last conferences, it seems to me that this little bit
> > of Python sectarianism won't keep us from concentrating on the
> > conference content.
> FWIW, CERN's indico conference software is written in Python too (and
> is open source, gpl I believe). I also failed in my attempt to
> install it, though...
When making the choice of registration software, there are some rather
important points to consider.
1. The software has to work on the day we start taking registrations.
This may sound self evident, but we have had problems in the past. Using
something that has been tested saves a lot of grief.
2. The software needs to do a good job in supporting all the actors using the
system. This means that speakers and attendees should have an easy time
registering. The track chairs should be able to view and handle all the talks
in their tracks. The schedulers needs to have support for scheduling. The
registration administrators must have access to many different views and a
powerful search interface. Last year I was able to place a payment by
searching for all attendees from the UK who had ordered a T-shirt and for
whom a payment was not yet registered. There were many other such incidents
where the search interface saved many hours of work.
3. Producing quality outputs is essential. There are 3 major products and some
minor ones needed.
You must be able to produce invoices in accordance with legal requirements.
The smallest amount of work for the organisers is generated if attendees can
print their own invoices. Don't expect everyone to manage to print an invoice
at registration. You need an interface so they can come back and make a
separate printout. They need fields for entering an organisation number and
other reference information on the invoice. You must put the attendee
information in a place that is not part of the address fields, or some
organisations will complain. You must have complete payment information on
A lot of work went into making name tags that are actually readable and that
contain useful information. I decided to go for name, organisation, email
address and country (plus attendee category) as useful information to put on
the badge. Email address was made in a smaller and harder to read print,
because I wanted that bit of information to be a bit harder to access. If the
badge holder wants to give it out, he/she can point to the badge.
All the major fields require scaling, as some individuals have very long names
or organisation names, while most people have reasonably short ones.
Adjusting everyone for the longest names means that everyone gets badges that
are impossible to read.
Making a printable programme with all necessary content is not a trivial
exercise. So far we have been relying on the software of Reportlab for this
task. It has the nice feature of allowing each attendee to print a customised
You should be able to generate statistics lengthwise and crosswise. How many
staff, track chairs, speakers, students, early birds, on-sites, no-shows,
people from different countries etc.
e) Talk materials
You need places to store these and make them available to attendees and to the
Moving to a solution that doesn't support these things would be a regression,
as would having a registration procedure that does not build on the lessons
we have learned in previous years of Europython. Getting it right was
actually hard work.
This said, I'll be just as happy not doing registration with the CAPS system,
as it would require a bit of work from me. However, I think that the CAPS
system encapsulates the lessons we have learned in a way that the other
proposals are unlikely to do.
For the website with information about the conference, what we had the last 2
years was hopelessly over-engineered. There is need for some fairly advanced
templating, which allows for the display of banner ads, unified dropdown
menus and such, but the content management behind has really been in the way
of collaborative work on the website. The ideal solution from my horizon
would be a very small directory tree with a simple include mechanism and
files written in either xhtml or Rest. The webserver would handle the
includes, the Rest translations and finally fill in the dynamic content
before serving up a webpage. Doing Plone or CPS for handling a site of about
25 web pages is as impractical as shooting mosquitos with an anti-aircraft
More information about the EuroPython