What Does Done Look Like?

This post originally appeared on the Software Carpentry website.

After recent posts about where we are, our infrastructure, and our plans for the summer break, it seems like a good time to raise our sights and ask how we want Software Carpentry to run once it's all grown up, and what the practice of science will look like when every grad student in the world goes through our training. (Pause for maniacal supervillain laugh.)

We'll leave the second question to another post, but the infrastructure post implies answers to the first. Now that we're using a "host site pays travel costs model", there's no financial obstacle to us scaling up to a thousand bootcamps a year worldwide. What prevents us are a lack of instructors (to teach) and administrators (to coordinate who's going where). We're working on the first (our online training should give us 75 qualified instructors by the fall) but we need much better tooling to handle the matching: while We encourage people to set up bootcamps on their own, we'd still like to know about them so that we can help with advertising and ensure that our criteria for using the Software Carpentry name and logo are met. We will also need more regional coordinators to do what Mike Jackson is so ably doing in the UK.

Here's how it could work two years from now:

The Department of Redundancy Department at Euphoric State University has twenty-six new graduate students starting this September, and would like to run a bootcamp for them, and for the half-dozen undergrads in the department who are thinking about applying to grad school. Meanwhile, Paula Postdoc is planning to be in Euphoria for a conference, and would like to use the opportunity to organize a bootcamp. She attended one at Miskatonic University three years ago, helped out with one after that, then worked through the Software Carpentry instructor training and helped teach a couple of times (which has earned her an instructor's badge).

Euphoric State posts a bid to host a bootcamp on the Software Carpentry exchange. The exchange notifies Paula that there's a new bid matching her criteria (which are "anything in Western Canada or near a beach"), so she replies with her dates. After a bit of back and forth, ESU chooses her as the lead instructor for their bootcamp, and it is added to the Software Carpentry calendar. This automatically sets up a mailing list for organizers, a registration form, a pre-assessment questionnaire to gather information about attendees' skills and interests, and a blog post announcing the bootcamp, and creates a new fork of the bootcamp repository.

As lead instructor, Paula is responsible for maintaining the bootcamp's web presence, defining the exact schedule, and so on. She decides to use a three-day format: the first two days will be Software Carpentry's agreed core curriculum, while the third will cover refluxive bisection techniques (currently a hot topic in redundancy research) and open access over-the-web scientific publishing tools (which faculty attending the bootcamp are clamoring to learn). After getting this signed off by the Software Carpentry admins, she recruits a junior co-instructor through the exchange. Meanwhile, her hosts connect her with a couple of ESU grad students who are interested in helping out (and potentially becoming instructors themselves).

The bootcamp takes place:

Once it's over, Paula and her hosts are contacted for feedback. (The attendees, who were asked to fill in a standard questionnaire at the end of the bootcamp, will be surveyed again six months later to find out what actually stuck.) As part of their feedback, Paula and her co-instructors are asked to nominate people to join the instructor training program. Paula and her co-instructor also submit their expense claims to ESU.

Two weeks later, after she's had a chance to catch up with the rest of her life, Paula merges a couple of fixes and examples from her bootcamp's repository into the master copy so that other people can use them. She also writes a blog post summarizing the bootcamp and adds a comment to the instructor's guide to suggest another way to motivate dictionaries in Python.

This isn't the only way Software Carpentry could eventually work, but it looks like a good one to me. What else would you like to see?