[Linux-aus] Re: LCA: bringing the process forward

Michael Bennett mib at homemail.com.au
Thu Feb 23 20:33:02 UTC 2006

Leon Brooks wrote:

>On Tuesday 21 February 2006 20:04, Michael Bennett wrote:
>>It also means that a lot of the same work is repeated
>>year after year.
>This seems to be the nub of the matter.
It is some of it. The other part was competition. Competition by bidding 
means you find out who the best bidder was not who can run a conference 
the best. Having the competing teams run a small conference which is 
judged would be cool and would actually find out who can run the best 

>LA has instituted processes like the "Ghosts of Conferences Past" 
>meetings (the kiwi group should pack some Maori masks) to pass the 
>torch of knowledge along to some extent.
>Such processes can and should and almost certainly will continue and be 
>further developed, but one thing I want to do here is call into 
>question the unwritten assumption that near-total rewrites-from-scratch 
>are an inherently Bad Thing.
It is definitely not an inherently Bad Thing. It has worked well in the 
past. What I'm suggesting is an inherently better thing.

>Yes, some effort is wasted, but I doubt that as much of the effort in 
>raising a conf is as reusable as many people seem to think.
I have to disagree. A good schedule of when certain things should be 
organised by can be reused (just change the end date and recalculate). 
Reuse applies to scripts of how to do various parts the organisational 
process (how to organise catering for 500). All of the backend software 
to manage registrations, payment, attendees, and badges should be able 
to be reused with minor changes (year++). Checklists and templates for 
various letters, emails and contracts can all be reused. All of these 
minor things can save a considerable amount of time and effort.

>Over against this, you have to set the potential for innovation and 
>fresh ideas that LCA harbours.
Most people really don't want innovation, they want the same thing with 
a few tweaks. An example is suggesting a different way to select the 
organising team. The next email on the subject was why things should 
stay the same.

What I am suggesting provides better grounds for innovation and fresh 
ideas. Most innovations are incremental innovations being built upon 
what has already been done. Knowing what has been done previously shows 
how many ideas are actually incremental innovations.

Also innovation usually only occurs on a small subset of the conference 
at a time. For areas where the organisers are quite happy to do what 
they did in previous years, reuse makes it easier for them.

Innovation can be restricted if you do not have enough time to implement 
it. Reuse saves time which can then be focussed on the innovations. Also 
most people probably don't have many innovative ideas (that work well) 
for say conference bag stuffing. However if someone has studied in this 
field and can provide a best method, then it should be documented so 
that organisers can use it.

>For technically minor but illustrative 
>examples, Linus wore his first (and so far only) penguin suit at 
>LCA2003, and got dunked at LCA2004. About the only commonality in 
>schwag has been those IBM LAN/phone cable thingies. The tee-shirt 
>designs have all been utterly different. We had water-pistol wars at 
>Adelaide, cycling and a pizzavalanche at Canberra, dinner at a castle 
>in Dunedin.
The reuse here is email Linus an invitation to the conference. Ask him 
to do __insert zany thing here__. If he agrees to come then organise 
what ever needs to be organised. Also with schwag, the organisers need 
to go out and get samples and quotes, get test runs done and check the 
contrast on t-shirts, then order the gear well in advance.

Places where you don't want reuse is in theming, such as graphics, 
logos, slogans, etc.

>All different, all fresh*, all new people, all of the _non_core_ stuff 
>was "+++ REDO FROM START"ed. Much of the core organisational effort is 
>location-dependent, so has to be redone at each new spot anyway.
Location-dependence is relatively small as the process for organising 
venues, catering, and dinners remains relatively unchanged no matter 
where LCA is held. There will always be location-dependent issues that 
you will only ever have at one place and the organisers need to deal 
with them. Other issues appear year after year and having a good process 
can minimise these problems.

The whole point of it isn't to turn LCA organisers into drones. It is 
about providing them with a way to do as much as possible with the least 
amount of effort. If the organiser like how it was done last year then 
they follow the script. If they think they have an innovative idea then 
they do it their way. Future organisers can then choose from the 
different ways that have occured before. It may open up the door for a 
small team to organise a conference in Broome when it might not 
otherwise be feasible. Having said all this, if a team wanted to just 
reuse the conference out of the box with no modification then they 
probably aren't the right team to run an LCA.

LCA already reuse most ideas from the previous years as they work well. 
LCA is always hosted at a university. There is always network access. 
There are miniconfs followed by the main conference. The keynotes are in 
the morning. There is a penguin dinner with something that raises money 
for charity, professional delegates networking session, speakers dinner, 
saturday lunch, morning and afternoon teas, and schwag to name a few 
things. I was also disappointed that there was no RDP as in previous 
years. All of these things have parts which can be saved and reused in 

Having it as an FOS project hosted on the web allows people to 
contribute ideas on running a conference and allows other people to 
build on our success.


More information about the linux-aus mailing list