By Philip Fowler, Department of Biochemistry, University of Oxford.
This post is based on my experience of organising and hosting the first Software Carpentry workshop at the University of Oxford.
For a workshop to be successful, there has to be one and only one local person who is ultimately responsible for the workshop. A host brings the attendees, the instructors and the helpers together in such a way that things get learnt and everyone enjoys themselves. Being the host sounds kind of glamorous, but really what it means is coming in early on both days to buy the donuts, set out the chairs and check that there are no builders drilling. (And on the second day this work will be done after at a night at the pub.) If this is you, or might be you, read on…
1. Who's invited?
Be clear what sort of workshop you will run. Can anyone apply or is it restricted to a specific university or company? You'll need to decide this very early on and then stick to it, because the type of workshop you host will drive many of your other decisions: from the topics covered, to the room used, to how you plan any follow-up sessions.
There are pros and cons either way. A closed workshop can be more easily tailored to a specific audience, the attendees are more likely to know one another and follow-ups will be easier. On the other hand, you won't have any problems populating an open workshop.
If you choose a closed workshop, I have found that they are so popular you will have to continuously resist people who will try to persuade you to open it up. If you've got good reasons to keep it closed or invite-only, keep it that way.
2. Put yourself in the attendees' shoes
Think about the workshop from the perspective of the attendees. Put yourself in their shoes: will they know anyone there? If they don't, how will they find out peoples' names? Do they know where the room is?
Repeatedly going back and looking at the workshop from the point of view of an attendee will help you make - seemingly small - improvements that will add up and make a big difference. For example, at our workshop over half of the attendees knew each other very well. By sitting the other attendees close to at least some people they knew, providing name tags and communal tea, coffee and biscuits, everyone got to know everyone else by the end of the workshop.
Note that all of the above applies equally to your instructors and helpers. Do they have accommodation? Would they like to go out to dinner, or have a quiet night?
3. Get help early.
You might be the host, and thus responsible, but you can't do it all on your own. Recruit your helpers early and get them involved from the start. Get them to read the top tips on being a Software Carpentry helper and how to help at a boot camp, which will help them understand their role.
Having more people to hand not only helps spread the load, it also brings together a wide range of different skills.
4. Prepare the software
You will need help for this task: make sure the software stack is installed and validated on all of the machines. This is crucial. Every time the workshop is brought to a halt by a command not found the buzz that's been built up starts to ebb away. Next thing you know, Facebook will appear on browsers and people will start thinking about what else they might be doing.
Of course, installing software is a thankless task as no-one notices when it all works. We coordinated the installation and validation process using a Google Drive spreadsheet to which all the helpers had access. Having read tip #3 you may decide that the attendees will learn better if they bring their own laptop. This will make software installation more difficult. We held a drop in clinic the day before the workshop to sort out any teething problems. I can guarantee you will find problems you didn't anticipate, so start this work early….
Oh, and don't assume that the collected geek-power of the instructors and helpers will be able to blow away any problems on the day of the workshop. For example, we found the best way to install the python dependencies we needed on a Mac was to use MacPorts. This compiles everything from source. So far so easy, but one of the dependencies for scipy turned out to be gcc. And that can take three hours to compile.
5. Make lists.
The day before is hard. There are lots of little tasks to complete, you'll be worrying about how well it will go and your mind will start to go in circles (mine did). So a good week beforehand get a coffee, sit down (maybe with your helpers), and write down everything that needs to be done before the first session. The day before the workshop, work through your list and tick everything off. Now I really mean everything: from checking the data projector, to getting red/green stickies, to buying the tea and donuts. There are some good tips for preparing in the how to run a Software Carpentry boot camp guide
This is also the time to add some contingencies. Everyone might have said that their laptop can connect to the Wifi, but get some guest logins just in case. Likewise, set up some guest accounts on a workstation that you know works. If someone has a missing piece of software on their own machine, they can at least ssh into a working machine whilst you install the software.