This guide includes checklists for each role involved in running a workshop, and a long-form description of the story of a workshop. The description explains how workshops work, and the checklists below explain how each role contributes to a successful workshop. For instructions on setting up a website for a workshop, please see the workshop template home page.
You may also find it useful to look at this pitch, which explains to faculty, administrators, and others what a workshop is and why they should host one.
The Story of a Workshop
A workshop is a set of intensive hands-on lessons in which scientists learn software skills through short tutorials and practical exercises. A typical workshop runs over two days with 15-40 attendees and two or three instructors per room, and one helper for every 10 attendees. The members of a workshop team are:
The host, who is the principal local contact for the workshop.
The instructors, who present the tutorials and lead the practical exercises.
The lead instructor, who is in charge of deciding what will be taught by whom and ensuring the teaching aspects of the workshop go smoothly.
Helpers, who provide assistance during practical sessions, update and answer questions on the workshop Etherpad, and help with various practical matters.
The Software Carpentry administrator advises and helps the host with workshop organization, matches hosts with instructors, sets up registration and assessments, etc.
Learners come to the workshop to learn.
One person may have several roles in a workshop; for example, it's common for the host to also be a learner.
We require hosts, instructors, and learners to adhere to our code of conduct.
Using Our Name and Logo
As explained in our FAQ, anyone can use our materials and run a workshop. However, you must have our explicit prior permission to use our name and logo (which are trademarked). We normally require that the lead instructor be certified by Software Carpentry, and that the training covers our core topics.
Before the workshop organization begins, the host has to consider the answers to a series of questions. At some point in this decision-making process, the host will contact Software Carpentry admin to initiate workshop planning.
Who Is the Workshop For?
The host must think about the intended audience for the workshop. Will it be restricted to a specific lab, university, or company? Will it target people in a particular discipline (or range of related disciplines), or will it be open to all?
Open or Closed? Public or Private?
A closed workshop can be more easily restricted to a specific audience, which allows the instructors to tailor material to that field. In addition, attendees are more likely to know one another, which in our experience means they're less inhibited about asking questions and are more likely to help each other during practical sessions.
On the other hand, it may be harder to find enough people to fill a workshop if you restrict enrollment, and if your funding comes from the university or company level, it may be politically difficult to turn people away.
Having said that, there are a number of reasons why you might consider allowing external personnel to come to your workshop:
Others can see how a workshop is run and decide whether they want to run one too, which contributes to the growth and sustainability of Software Carpentry.
Attendees are given the opportunity to network and build relationships with researchers from elsewhere within your institution or community, or foster cross-disciplinary collaboration.
Your profile is raised within your institution or community as one experienced in hosting workshops which means others may seek your advice when they come to run theirs.
How Many Learners?
Workshops work best with rooms of between 15 and 40 learners. Above that, they become more like a lecture and the hands-on workshop feeling is lost. If you are expecting significantly more than 40 registrants, consider hosting a multi-room workshop.
Multi-room workshops can work very well because they allow us to stream learners into groups according to their computing experience. The disadvantage, of course, is that you have to book multiple rooms and recruit more instructors and helpers.
What About Cost?
The host needs to think about the cost of running a workshop and where the money might come from, and apply for funding if necessary.
Our instructors are volunteers, and do not need to be paid for their time, but workshop hosts are expected to cover their travel and accommodation costs. (As much as possible, we try to match instructors to nearby sites in order to reduce costs.)
Software Carpentry strives to be a global project and support a diverse set of organizations; any potential host that wishes to offer a workshop that would aid these goals is urged to contact the SCF to discuss waivers and other arrangements.
The Software Carpentry Foundation is able to accept payment of administrative fees through PayPal or by check or wire transfer to NumFOCUS. Please contact us to request an invoice as soon as the workshop's date and instructors have been confirmed.
Source of Support
Some possible sources of funding are:
"Miscellaneous" funds (e.g., a few thousand dollars in a faculty member's grant). This is by far the most common case.
Training budgets at the lab, department, or institutional level.
Workshop budgets set aside as part of conferences.
Charging for registration (typically $20-$40). This also reduces the number of no-shows from 20-25% to about 5%.
How to Reduce Costs
The host can consider these ways to reduce the costs of running a workshop:
Find out if there are others in your institution or community who are willing to help with instructor travel expenses, room bookings and other costs. They may be willing to share costs if their researchers can attend your workshop…
…or just go all-out and agree to run one jointly.
Use local instructors and helpers (by local we mean from within your institution, region or country) who will have lower travel costs.
Co-locate with conferences or workshops being run by your institution or within your community.
Should the Workshop Be Free to Learners?
The host and admin also need to decide whether the workshop is free or not. On the one hand, we want workshops to be as accessible as possible. On the other hand, charging $20-$40 for registration cuts the number of no-shows from 20-25% to 5% or less. Note that:
If the host decides to charge for registration and keep the revenue to defray the cost of catering and other expenses, we will still manage registration so that we can see how it's going, release people from the waiting list, access registrant information, etc.
Be aware that as soon as you charge anything at all—even a refundable deposit—some venues will charge for use of the space.
Refundable deposits are great in theory, but are an administrative nightmare in practice.
When Should the Workshop Be?
Many factors determine when to hold a workshop. The first is obviously the availability of instructors: admin will help with this.
If the workshop will be at a university, the start of term works better than the end of term (when people are tired, and busy with final assignments and exams), and the start of the second (or subsequent) term works better for graduate students than the start of first term. (The start of an academic year is busy anyway, and by their second term most students have a better idea of their research problem's programming needs.) In our experience mid-term breaks and reading weeks do not work well: workshops held then usually have high no-show rates.
Workshops can also be scheduled immediately before or after a conference (or run as a tutorial within a conference). In this case, the conference organizers must be involved early and often.
Should There Be Follow-Up Sessions?
The host will decide before the workshop what kind of follow-up they're going to offer (if any). Some groups run weekly lunch-and-learn sessions for a couple of months after a workshop to help people put what they've learned into action. Other groups set up mailing lists, and we've tried running online tutorials. Whatever they decide to do, figuring it out in advance means that they can tell learners about it at least a couple of times.
A workshop room of approximately 40 people needs at least two instructors, and a third is a good idea, because:
It's too much to ask a single person to talk for eight hours a day for two days.
Attendees will be more engaged if they hear from more than one person.
Having two or three instructors reduces the risk of having to cancel because of illness, travel mishaps, etc.
Instructors must be recruited before advertising the workshop or opening up registration. At least one instructor must be certified by Software Carpentry in order for the workshop to use our name and logo. The other instructors should have prior teaching experience, be taking the instructor training, or have helped with at least one previous workshop.
Once the workshop has a full roster of instructors, admin will set up a mailing list for the organizer, instructors, and helpers so they can discuss audience, content, schedule, dinner plans, etc. (This is optional—some workshop teams prefer to email back and forth without a mailing list.)
Software Carpentry admin can set up an Eventbrite registration page on our Eventbrite account, but some sites do use their own system: for example, workshops being run in conjunction with conferences may use the conference registration system.
If admin sets up an Eventbrite page, we can give the host administrator permission so they can send messages to registrants, download the registrant list, manage the waiting list, etc.
Setting Up Eventbrite
If the host would like Software Carpentry to run registration through Eventbrite, we'll need the following information:
- how many people will be registering
- how much to charge for registration, if anything
- whether the registration page should be public or private
Eventbrite events can be public, which means they appear on Google and in listings, or private, which means they can only be seen by people who have the link. We can also add a password to protect the registration page further.
The Workshop Venue
It's the host's job to identify and book a suitable room (or rooms) for the workshop.
You'll need a room with:
Front-facing tables so that attendees can watch an instructor and use their laptop at the same time. (Typing on a laptop for two days in theater-style seating can cause back strain.)
High-speed WiFi or network access that can withstand everyone using it at the same time.
Power outlets for all the computers. This often involves extension cords; make sure they're taped down.
Space for mingling without squeezing between chairs and tripping over cables. This is essential: if helpers cannot reach learners who are having problems quickly and easily, those learners will fall further and further behind as the day goes on. Again, theater-style lecture rooms are not recommended as their banked floors and fixed seating makes it very difficult for helpers to mingle.
High table or one that can be raised, to allow instructors to stand when live coding.
A microphone if the room is large or has poor acoustics, or if the workshop will be recorded.
Disabled access. (Make sure the washrooms are accessible as well.)
Air-conditioning, because all those computers (and attendees) will generate a lot of heat.
Space to serve coffee and snacks, because learning is hungry work.
The lead instructor and other instructors are responsible for creating the workshop's home page on GitHub. (The README on the template page explains how to do this.) The webpage should have instructions for attendees, including the workshop dates, the location, a link to the registration page, and so on. The host should make sure this page also includes local travel information, parking instructions, and whatever other information is needed. After the workshop topic list and schedule are finalized, they will be posted to the webpage too.
Software Carpentry admin will check that the workshop is showing up properly on the list of upcoming workshops.
Once the webpage is set up, the host will start spreading the word about the workshop. The host can tweet and blog about the event, and send emails to departmental mailing lists, discipline-specific mailing lists, specific people (e.g., lab directors or principal investigators), and anyone else who may be interested.
Software Carpentry admin is happy to promote the host's blog articles and tweets. We'll tweet and blog about the event, too.
If it's in the workshop budget, the host will provide coffee and snacks. Doing so cuts the time per coffee break to 10-15 minutes from 20-25 minutes. If this isn't possible, the host should identify somewhere nearby where attendees can get refreshments, and the schedule should include longer coffee breaks.
If snacks will be provided, try to allow for allergies and other dietary restrictions.
The Pre-Workshop Assessment
A few days before the workshop begins, learners will be asked to complete a pre-workshop skills assessment, usually as a Google form. The responses to the assessment will help the instructors tailor the workshop material to the group's needs.
Travel Arrangements and Reimbursement
If there is someone at the host institution who usually handles travel arrangements, admin or the host will connect them with instructors as soon as possible.
The host should also make sure it's clear who's paying for what and how people will be reimbursed before anyone buys plane tickets. The hosting site must reimburse instructors directly—Software Carpentry cannot route payments.
Instructors should not be shy about asking admin or the host about how to be reimbursed if they're not sure.
Pulling It Together
Once the initial conversations and setup are done, it's time to move forward with the nitty-gritty details of running a workshop.
Curriculum and Schedule
The lead instructor, other instructors and host will decide what content will be covered in the workshop. The lead instructor will put together a schedule of topics and assign an instructor to each topic.
In addition to booking a room and catering, the host is responsible for providing an assortment of equipment and supplies for the workshop. The host should check that the following equipment and information is available and working:
A projector (and a spare if you can find one, or a spare bulb if you can't).
A Mac VGA adapter if anyone is presenting with a Mac.
Extension cords and power bars if necessary.
Two different colors of sticky notes for use as flags and for feedback. You'll need enough for each learner to have four of each color per day. The two colors should be very distict and preferably clearly recognizable as "good" and "bad"—red and green work well (but be conscious of color vision deficiencies).
Guest usernames and passwords for everyone.
If possible, a couple of spare computers with the required software already installed, in case someone can't get access to the network, forgets their machine, has hardware problems, etc.
A handful of USB sticks with installers on them just in case there are network problems.
Photo release forms (if required).
Name badges or stickers for instructors, helpers, and attendees.
Helpers keep workshops flowing smoothly by assisting learners who are having trouble with exercises. It's the host's responsibility to recruit local helpers. There should be at least one helper for every ten attendees.
Most of our helpers are scientists who have either gone through a previous workshop, or learned most of what we teach on our own. Hosts usually recruit them from the hosting institution and nearby institutions.
Usually, workshops don't cover helpers' travel or accommodation expenses. Taking the whole team out to dinner the day before the workshop starts is a nice way to thank everyone and give them a chance to get acquainted.
If registration fills up, potential learners can add themselves to the waiting list (if the workshop is using Eventbrite). A week or two before the camp, the host or admin should contact the registered learners and confirm that they'll be attending. If anyone cancels and opens up a spot, admin or the host should offer that spot to someone on the waiting list.
Either the host or Software Carpentry admin can manage the waiting list. There are a couple of tricks to managing Eventbrite waiting lists:
You have to manually release people—Eventbrite doesn't automatically detect that a space has opened up and release a ticket.
You release tickets by selecting the person's entry on the waiting list and clicking "Release Tickets". When you release a ticket to someone their name is moved to the top of the list and they are sent email letting them know they have a day to register. If they don't register within 24 hours, the offer times out and the host or admin must manually rerelease that ticket.
Once the waiting list is activated people cannot register outright, even if there are spaces available; they must add their name to the waiting list and have a ticket released to them.
If the workshop will be photographed, recorded, or broadcast, the host will let learners know by posting on the workshop's website. Institutions may require the host to obtain a signed photo release from each person if pictures are being taken; the host is responsible for finding out if a release is required, and printing out enough copies.
The Day of the Workshop
The host will introduce the instructors and helpers by name, and remind the learners that everyone teaching/helping is volunteering their time, to help set learners expectations. The host will talk about why the workshop is being held and the desired outcome. They'll also let everyone know where to get coffee, whether they can bring drinks and snacks into the workshop room, and where the bathrooms are. The host will also remind learners of the code of conduct.
Sign-in Sheet and Sticky Notes
Before the workshop instruction begins, the host will hand out sign-in sheets and two different-colored sticky notes to each learner. The sign-in sheets help us keep track of how many learners we are reaching, and how successful our efforts to reduce no-shows are. The sticky notes let the learners communicate with instructors and helpers, both during the tutorials and exercises, and when giving feedback afterwards.
Feedback, or "What Are the Sticky Notes For?"
During demonstrations, learners post a red sticky note on their laptop to indicate that they have a question or need help.
During exercises, learners post a red sticky note at the start of the exercise and switch to a green one when they finish, so the instructor can clearly see when everyone is ready to continue, and helpers can see who needs support.
Just before each break, the instructor will ask learners to write down one good point (something they learned or enjoyed) on their green sticky and one bad one (something that they still don't understand or that is bothering them) on their red sticky. It only takes a couple of minutes for the instructors to sort through these, and it tells them whether they're going too fast or too slow, what they need to review after the break, etc. (If possible, someone will mail the sticky notes to Software Carpentry admin after the workshop so we can look for patterns.)
At the very end of the workshop, the host or lead instructor can ask learners to give one good point or one bad one about the entire workshop. This can be done on the sticky notes, the Etherpad, or through a Google form. (This feedback will also be sent to Software Carpentry admin.)
Once the workshop starts in earnest, the day will alternate between the instructor describing and demonstrating concepts and tools, and the learners completing short exercises. Sometimes the learners will type along as the instructor demonstrates. Learners are encouraged to work in pairs and groups, and to mix up their groups over the course of the workshop.
The instructor will ask lots of questions and encourage the learners to ask questions too. No more than ten or fifteen minutes will go by without the instructor engaging the learners or asking them to complete an exercise.
Helpers walk around the room looking out for learners who are confused or stuck with an exercise, or who have gotten behind the flow of the demonstration.
Meanwhile, there is an Etherpad open where all the learners and helpers are invited to take notes, post links and examples, and ask and answer questions. (This is a great opportunity for learners and helpers who aren't so gregarious to participate more fully in the workshop.)
Before the workshop ends, the host or an instructor will direct the learners to a post-workshop assessment. This is very much like the pre-workshop assessment, and helps us establish how well our workshops actually work.
We have plans to ultimately send a third assessment a few months after the workshop, to see how well and how long learners' new knowledge and skills stick around.
At the end of the workshop, the host or an instructor will give the learners some final pieces of information:
how to get more help with the things they have learned;
how to get involved with Software Carpentry; and
how to participate in any follow-up sessions the host is planning.
After the Workshop
Once the workshop is over, the host will send the number of attendees (and if allowed, their names and email addresses) to Software Carpentry admin. The host will also let admin know how the workshop went. Was it the right content? The right pace? Did it seem well organized or were there things we could improve? What did you hear from learners afterward, and would you like us to visit you again?
We're also happy to hear from the instructors, helpers, and learners with comments and suggestions.
Our goal at Software Carpentry is to have at least one blog post from each workshop, whether it's written by the host, an instructor, a helper or a learner. So if you've been involved in a workshop and you'd like to write a blog post, or if you have written one on your blog, let us know so we can post it or link to it.
Dialogue & Discussion
You can review our commenting policy here.