[EuroPython] Python conference software

Jacob Hallen 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.

a) Invoices.

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 
invoices.

b) Badges.

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.

c) Programme

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 
programme.

d) Statistics

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 
general public.


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 
gun.

Jacob Hallén


More information about the EuroPython mailing list