[Linux-aus] Re: LCA: bringing the process forward
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
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