[EuroPython] Python conference software

[Jacob Hallen]

onsdag 25 januari 2006 19.29 skrev Jean-Marc Orliaguet:
> Jacob Hallen wrote:
> >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
>
> There are 120 pages on the current europython site (not 25). Doing that
> on a wiki with banners, menus, ... is not completely as trivial as you
> suggest (see for instance what you'll get with a wiki
> http://wiki.python.org/moin/PyCon2006 )

I count 25 distinct pages that are viewable by visitors to the site, plus a 
few off-site links. I don't know what the other 95 pages do. They seem to be 
overhead to me.

I'm not suggesting that building the website is completely trivial.I'm saying 
that the solutions we have seen so far have made the job more difficult than 
it needs to be. Laura Creighton and I were the main content providers both 
for the 2005 and the 2004 conferences. We found that Plone imposed a number 
of limitations on the overall look of the website, and that it had a 
cumbersome interface for entering content. CPS fixed the limitations of the 
overall look, but imposed arbitrary limitations on page design (for instance, 
I could not scale pictures as I liked). It also has a workflow model that is 
unsuitable for close collaboration on individual pages,as you are supposed to 
develop pages in your own sandbox and then publish them. We ended up building 
everything in the published space and giving full privileges to everything to 
everyone wanting to do any modifications. 
 
> Concerning registration most conferences I've attended handled
> registration via email or via fax (cf
> http://www.python.org/pycon/2006/register.html) or via simple HTML/CGI
> forms. They certainly use some desktop software to organize talks,
> attendees, schedules, but I don't see the value of doing this through
> the web. It is definitely overkill and cumbersome as it proved out to be
> during last year's conference.

For these conferences, how did they produce badges? How did they produce 
invoices? How much time did they spend on handling administrative matters? 
How many problems tracking payments did they have? What sort of organisation 
did they have backing the conference (perhaps that organisation already had 
an accounting system and a secretary doing a whole lot of typing)? Did they 
actually take into account the individual preferences of the attendees, or 
did they just create a schedule on speculation? Were the organisers, each 
with his own needs for information, spread over a whole continent? How did 
they distribute proceedings? How much did their overheads cost?

What did you consider to be cumbersome with the handling of talks and 
scheduling during last years conference?

Jacob Hallén