Time for me to fill you all in on some work I’ve been doing in preparation for linux.conf.au 2017. I’ve been looking into how we can better run the conference website, and reduce the workload of our volunteers into the leadup to the conference.

linux.conf.au has, for the last 10 conferences, used a home-grown conference management system called Zookeepr. I got administration experience in Zookeepr after being involved in running PyCon Australia for a couple of years, and continued to help manage registrations for the years following. While Zookeepr is a venerable piece of software, my 4 years of experience with it has helped me become familiar with a bunch of its shortcomings. Most of these shortcomings are in the area of registration handling.

A problem with conference management software is that the people who come to develop on it are often highly transient — they’re conference organisers. They show up, they make their modifications, and then they get as far away from developing it as possible. Zookeepr’s been affected by this, and it’s meant that difficulties with workarounds are usually overlooked when fixing things.

So I decided to look elsewhere.

Back in 2012, the Python Software Foundation funded a conference management suite called Symposion.

Symposion solves a bunch of problems that Zookeepr solves, and more importantly, it doesn’t suffer from the lack of continuous contributions that Zookeepr has: It’s an actively-maintained app, built on Django, and it has a community of developers supporting it in the form of the Pinax project. In the Python world, it’s used for a very large number of conferences, from PyCon US (a big conference, getting some 1000 talk submissions yearly), down to local regional conferences like PyOhio. It’s well known, and improvements to the system aren’t contingent on conference organisers maintaining interest in the system after they stop running conferences.

Unfortunately, for various reasons, Symposion doesn’t handle conference registration.

So after OSDC2015 in Hobart successfully ran their conference website with Symposion, I decided to plug the gap. In January this year, I jotted down all of the things that I thought was good about Zookeepr’s registration system, and thought about how I could go about objectively improving upon it.

I threw together a data model, and wrote a test suite, and liked what I saw. I asked the Python Software Foundation for a grant to let me do some concerted work on the project for a month or so, and they accepted.

The result is Registrasion (that’s Registra_tion for Sympo_sion (sorry)). I’ve just put out a 0.1 release, which I believe is suitable for running a conference if you’re happy to pull data out of the system with SQL queries, and take payments with bank transfers.

Registrasion was designed with a few key goals in mind, all of which came from observing how Zookeepr struggled around some frequent edge cases that, incidentally, come up late in the process of running a conference. Those late-occurring edge cases are invariably the ones that don’t get fixed, because volunteer conference staff all need to go and run their conference.

In particular, I focused on:

  • Eliminating manual work for registration managers (Zookeepr has a lot of that)
  • More flexibility in how we automatically offer certain items to end-users (selling flexible accommodation dates was a difficulty one conference year had)
  • Handling money properly, so that it’s possible to easily reconcile inventory and what’s in the invoicing system

Many of these goals solidified after talking to past conference organisers, who’d all used Zookeepr.

I’m quite proud of a few things in Registrasion. The first is that Registrasion makes it really easy for attendees to add extra things to their registration as they decide they need to. We also take care of automatically giving out freebies that attendees forgot to select during initial registration. In PyCon AU’s case, that’s a lot of manual work we can avert.

Another is a really flexible way in managing what parts of the inventory are available to our users, and at what time. We can show and hide items based on voucher codes, or based on whether they have other products selected. This averts a whole pile of manual work that a past linux.conf.au reported, and I’m glad that our year won’t have to

Finally, I’ve made sure that Registrasion has a lot of documentation. It was a key goal to make sure that new conference organisers can understand vaguely how the system fits together. Python’s tools, and Read The Docs, has made this very very easy.</a>

There’s a pile more work to be done, but there’s also plenty of time before lca2017 opens its registration (in October, probably?). But so far, it’s been super-fun to dive back into Django development, given it’s something I haven’t played with in a few years, and to solve a problem that I’ve been dwelling on for a couple of years now.

Hopefully, in Registrasion, we’ve got a piece of software that can serve the community well, will find use outside of LCA, but will still serve LCA’s needs well for years to come.

If you’re interested, please come along and contribute! I’d love to have you on board!