[Linux-aus] LCA2014 update update - what can we do to reduce workload?

Michael Still mikal at stillhq.com
Sat Sep 1 15:25:36 EST 2012

On 01/09/12 11:49, James Polley wrote:

> I’d love to hear more ideas about things like this that would lighten
> the workload of LCA organisers - either by distributing the burden out
> to the broader community, or by sacrificing a bit of profit in exchange
> for a lot of work. *

One of the things we've done for 2013 is automating speaker acceptances.
This means we don't need nearly as many humans to keep track of the
current state of speakers, which was a really big job. The flow goes
like this:

Talks are proposed. Once papers are reviewed, the accepted talks are
moved to one of four statuses:

 - offered
 - offered travel
 - offered accommodation
 - offered travel and accommodation

This has the side effect of enabling a magic acceptance URL in zookeepr,
where the user is asked to do one of:

 - accept their talk offers
 - withdraw their talks
 - contact us for help

If they got travel assistance, we also ask them for their source and
destination airports.

An external mail merge script then emits emails to speakers including
the magic URL. Speakers clicky clicky, and we don't need to manually
track acceptances or travel _at_all_. Some time later, we dump a report
of the travel needed, and hand it off the to travel agent.

Basically, its awesome. Most of this is James Iseppi's work, and is a
good example of the sort of Zookeepr hackery I think there _is_ a
continued need for. James also has nice hair.

So, what else could we automate? The layout of time_slots / events /
schedules in zookeepr is another obvious example.

We can also reduce the workload on the team by pre-empting as many
questions as possible. For example, people commonly ask about the
partner's program at registration time, so we're going to provide a
complete draft program before registrations open. That means we don't
need to wade through a million tickets addressing everyone's questions,
we just need to fill in the gaps where we missed things.

If someone not on the 2013 team wanted to collate a list of likely
questions people ask, we'd be happy to check that they're all addressed
when we open registrations. I think it needs to be someone outside the
team though, because the team has been talking about this stuff for over
a year now, and there's a lot of shared assumptions that we're not even
aware of any more.


More information about the linux-aus mailing list