this isn't a swancon report
just some notes to do with the UnderConstruction panels on Sunday - Monday's will follow soonest.
The first segment of UnderConstruction was on Knowledge Retention, which for some reason I can’t spell. The audio recording and a transcription (by Hespa Mann and Emilly McLeay) will be available soon. Kick me if I haven’t mentioned it in two weeks or so!
So, knowledge retention in conrunning: how so hard? SF conventions have been done well before; many of the issues that come up are solved problems. And yet every year, something fixable breaks. What’s with that? And can we stop it?
Red Book
One big piece of work on wiki.sf.org.au is the Red Book, basically the instructions on how to run a Swancon. I kicked off the discussion by saying how uncomfortable I, as a Victorian, felt at the idea of editing the Red Book. It’s often the first point someone suggests when I ask about convention running, but it hasn’t been updated for ages. It’s reputation as being out of date means that some Swancon committees don’t even bother looking at it, let alone working to keep it up to date!
Even without the issue of it being up to date, there are people who are interested in running conventions who haven’t heard of it. Perhaps - once it has made its way into the 21st Century - WASFF should take it on to make sure incoming committees know it’s there.
Rather than creating a clone, and starting the green book, one idea was, where necessary, create region-specific pages within the categories as necessary. Originally, apparently, a lot of the information was very Perth-specific, in terms of hotels & venues. We can have a page with very general venue information, and then a page each for Perth and Melbourne or wherever else.
And perhaps, reorganise the wiki a bit so that convention running isn’t stuck inside the Swancon section, which is itself within the WASFF section!
The conversation kind of moved into reasons why knowledge retention doesn’t work all that well. The Swancon method of a new committee every time means that information might be passed on from the old committee to the new one - but perhaps only to one new committee member, and not always to the right one. Continuum’s method of having people on the previous committee still on the new committee - even if not in the same job - works better in this regard. John Parker’s conventions have a similar set up. Old committee do burn out and sometimes leave but previous Swancon committee can be contacted via WASFF.
The debrief
Try and make sure one happens!
Two possible methods: get a professional facilitator, someone outside of the community, to create a safe space for the debrief - Damien. There’s possibilities for funding for that, from groups like Lotteries West and other groups whose aim is helping the community - Mark.
The other idea is much more informal; a dinner party or a weekend where everyone gets together to tell war stories - John and Mark.
(Not that I remembered to say it in the panel but Continuum have a committee meeting about two weeks after the con, which is handy for going over what did and didn’t work.)
The committee
Make sure people know what to expect. Obviously we can’t help if people quit because they have a significant life event happens while they were on committee, but they shouldn’t have to quit because the job isn’t what they thought it would be. GenghisCon, Perth, has someone read out the job descriptions before they take nominations for committee positions - Samara.
Actually be con-goers, and help out at other conventions. Remember, though, that a lot of things happen invisibly to the convention, six months or more before you get there: the hotel bid, the conbook.
Also remember that a lot of the things that go into running a convention have more than one right way to do it! - Rohan.
Timelines
We all agreed that timelines could be invaluable. The best tool for creating a timeline is seeing other people’s - we need to put up examples, which can be picked apart and remixed for different conventions with different needs. When setting up your timeline, remember to include dependencies, so that whole jobs are moved around together - PRK. If you can include your timeline on wiki.sf.org.au, that would be awesome - try and annotate it so that it makes sense outside of your committee, too.
Programming:
So many things! We could easily have spent the whole four hours just talking about programming, and giving the computer programmers a twitch.
Things to think about when putting together a program:
Anna: Remember the programmer's preferences are not the preferences of the community.
John: There are as many different ways to program as there are people!
PRK: What is the purpose of the program? Stuff to do at the convention, stuff to advertise the con?
Dave: Part of being a good programmer is developing skills to counteract your own blind spots.
Sue Ann: Programming is all about knowing your community. You need to sit down and listen, analyse other programs, listen to complaints, look at what is done. You need to be totally aware.
Ways to put together a program:
Sue Ann swears by giant boards with sticky notes - make sure you get the super sticky notes! It’s not super efficient - it’s hard to move around - but it is easier for to see the whole story at once.
Other people in the room prefer to work on the computer for the whole process.
LiveCon is still a baby but is going to grow into some freaking awesome programming software someday. I didn't manage to actually take notes on LiveCon cause I was too busy being excited to type.
Google docs has been used a fair bit for collaborative work on conventions: some people thought it worked well while others not so much.
Programming templates could be put onto the wiki: some big ticket items have only one place to go. But make it clear that templates can be messed with.
Whether on screen or on paper, colour code types of program items, to make it obvious when you have two hard sf items up against each other.
Damien pointed out that the maths in this has already been developed, it’s a solved problem. If you want to, he is more than happy to talk about it.
People on programming:
The people who do a lot are usually the people who are reliable, interesting, and worth having on lots of panels. But you still can’t let one person dominate programming!
Remember panellists and guests are people too and will want to go see some of the programming!
Sue Ann brought up the Worldcon program participant survey she used last year. It asks potential program participants to nominate the things they would be happy to talk about, people they’d like to work with (or not work with!) and can be really useful to find those people who you don’t realise have a speciality. Swancon 2011 had something similar but generally it’s not used as well in Australia as it could be. I have a copy of the Aussiecon IV wording and I’ll put it up in the wiki soon as I can.
Notification for people on programming: generally speaking, this needs to work better. It’s probably worthwhile letting people know what else is on at the time of their panel - sometimes there will be invisible clashes with the people who aren’t technically on a event but are needed to make it run, like carers, or technical people.
A couple of final questions:
How do you refuse people’s participation tactfully?
“It doesn’t fit with our program at this time”
Sometimes people will complain, and you just have to deal with it.
How do we deal with items that are there more for the panellist than for the audience?
Turn them down tactfully? We didn’t really have a chance to discuss this one - we ran out of time!
I have the audio files and they are partially transcribed, as well as Callistra’s tweetstream from all the panels. Hopefully when we sort out the bulletin board, we’ll be able to include all these files too, so that you can totally pretend you were there too.
To Do List:
*monday's panel notes
*finish transcribing audio recording, upload
*ditto with keepstream
*wiki updates (have started already, yay!)
*bulletin board
*upload timelines; program questionnaire
*email everyone re: having done all of the above
*rewrite this to do list to include monday's stuff
*panic re: continuum 7 book submission (this is on every to do list now. erk.)
This entry is crossposted from DW. Comment here or there.
The first segment of UnderConstruction was on Knowledge Retention, which for some reason I can’t spell. The audio recording and a transcription (by Hespa Mann and Emilly McLeay) will be available soon. Kick me if I haven’t mentioned it in two weeks or so!
So, knowledge retention in conrunning: how so hard? SF conventions have been done well before; many of the issues that come up are solved problems. And yet every year, something fixable breaks. What’s with that? And can we stop it?
Red Book
One big piece of work on wiki.sf.org.au is the Red Book, basically the instructions on how to run a Swancon. I kicked off the discussion by saying how uncomfortable I, as a Victorian, felt at the idea of editing the Red Book. It’s often the first point someone suggests when I ask about convention running, but it hasn’t been updated for ages. It’s reputation as being out of date means that some Swancon committees don’t even bother looking at it, let alone working to keep it up to date!
Even without the issue of it being up to date, there are people who are interested in running conventions who haven’t heard of it. Perhaps - once it has made its way into the 21st Century - WASFF should take it on to make sure incoming committees know it’s there.
Rather than creating a clone, and starting the green book, one idea was, where necessary, create region-specific pages within the categories as necessary. Originally, apparently, a lot of the information was very Perth-specific, in terms of hotels & venues. We can have a page with very general venue information, and then a page each for Perth and Melbourne or wherever else.
And perhaps, reorganise the wiki a bit so that convention running isn’t stuck inside the Swancon section, which is itself within the WASFF section!
The conversation kind of moved into reasons why knowledge retention doesn’t work all that well. The Swancon method of a new committee every time means that information might be passed on from the old committee to the new one - but perhaps only to one new committee member, and not always to the right one. Continuum’s method of having people on the previous committee still on the new committee - even if not in the same job - works better in this regard. John Parker’s conventions have a similar set up. Old committee do burn out and sometimes leave but previous Swancon committee can be contacted via WASFF.
The debrief
Try and make sure one happens!
Two possible methods: get a professional facilitator, someone outside of the community, to create a safe space for the debrief - Damien. There’s possibilities for funding for that, from groups like Lotteries West and other groups whose aim is helping the community - Mark.
The other idea is much more informal; a dinner party or a weekend where everyone gets together to tell war stories - John and Mark.
(Not that I remembered to say it in the panel but Continuum have a committee meeting about two weeks after the con, which is handy for going over what did and didn’t work.)
The committee
Make sure people know what to expect. Obviously we can’t help if people quit because they have a significant life event happens while they were on committee, but they shouldn’t have to quit because the job isn’t what they thought it would be. GenghisCon, Perth, has someone read out the job descriptions before they take nominations for committee positions - Samara.
Actually be con-goers, and help out at other conventions. Remember, though, that a lot of things happen invisibly to the convention, six months or more before you get there: the hotel bid, the conbook.
Also remember that a lot of the things that go into running a convention have more than one right way to do it! - Rohan.
Timelines
We all agreed that timelines could be invaluable. The best tool for creating a timeline is seeing other people’s - we need to put up examples, which can be picked apart and remixed for different conventions with different needs. When setting up your timeline, remember to include dependencies, so that whole jobs are moved around together - PRK. If you can include your timeline on wiki.sf.org.au, that would be awesome - try and annotate it so that it makes sense outside of your committee, too.
Programming:
So many things! We could easily have spent the whole four hours just talking about programming, and giving the computer programmers a twitch.
Things to think about when putting together a program:
Anna: Remember the programmer's preferences are not the preferences of the community.
John: There are as many different ways to program as there are people!
PRK: What is the purpose of the program? Stuff to do at the convention, stuff to advertise the con?
Dave: Part of being a good programmer is developing skills to counteract your own blind spots.
Sue Ann: Programming is all about knowing your community. You need to sit down and listen, analyse other programs, listen to complaints, look at what is done. You need to be totally aware.
Ways to put together a program:
Sue Ann swears by giant boards with sticky notes - make sure you get the super sticky notes! It’s not super efficient - it’s hard to move around - but it is easier for to see the whole story at once.
Other people in the room prefer to work on the computer for the whole process.
LiveCon is still a baby but is going to grow into some freaking awesome programming software someday. I didn't manage to actually take notes on LiveCon cause I was too busy being excited to type.
Google docs has been used a fair bit for collaborative work on conventions: some people thought it worked well while others not so much.
Programming templates could be put onto the wiki: some big ticket items have only one place to go. But make it clear that templates can be messed with.
Whether on screen or on paper, colour code types of program items, to make it obvious when you have two hard sf items up against each other.
Damien pointed out that the maths in this has already been developed, it’s a solved problem. If you want to, he is more than happy to talk about it.
People on programming:
The people who do a lot are usually the people who are reliable, interesting, and worth having on lots of panels. But you still can’t let one person dominate programming!
Remember panellists and guests are people too and will want to go see some of the programming!
Sue Ann brought up the Worldcon program participant survey she used last year. It asks potential program participants to nominate the things they would be happy to talk about, people they’d like to work with (or not work with!) and can be really useful to find those people who you don’t realise have a speciality. Swancon 2011 had something similar but generally it’s not used as well in Australia as it could be. I have a copy of the Aussiecon IV wording and I’ll put it up in the wiki soon as I can.
Notification for people on programming: generally speaking, this needs to work better. It’s probably worthwhile letting people know what else is on at the time of their panel - sometimes there will be invisible clashes with the people who aren’t technically on a event but are needed to make it run, like carers, or technical people.
A couple of final questions:
How do you refuse people’s participation tactfully?
“It doesn’t fit with our program at this time”
Sometimes people will complain, and you just have to deal with it.
How do we deal with items that are there more for the panellist than for the audience?
Turn them down tactfully? We didn’t really have a chance to discuss this one - we ran out of time!
I have the audio files and they are partially transcribed, as well as Callistra’s tweetstream from all the panels. Hopefully when we sort out the bulletin board, we’ll be able to include all these files too, so that you can totally pretend you were there too.
To Do List:
*monday's panel notes
*finish transcribing audio recording, upload
*ditto with keepstream
*wiki updates (have started already, yay!)
*bulletin board
*upload timelines; program questionnaire
*email everyone re: having done all of the above
*rewrite this to do list to include monday's stuff
*panic re: continuum 7 book submission (this is on every to do list now. erk.)
This entry is crossposted from DW. Comment here or there.