Planning for the Break

This post originally appeared on the Software Carpentry website.

We've had a busy nine months: 55 bootcamps since we restarted bootcamps last September, with 19 more in the next two months. We're taking a break then to catch our breath: we only have one event scheduled between mid-July and the end of August, which will give us time to reorganize our online materials and figure out what we're going to do in 2013-14. The list below outlines things that I'd like to see done during that break. I'm sure you have others; I'd be grateful if you'd add them as comments, along with your thoughts on things we shouldn't do, or should do differently.

Re-think the boot-camps repository and workflow.

This is our biggest task: it must be much simpler for people with middling-weak Git skills to create a space for a new bootcamp, find and import teaching materials used in previous bootcamps, and offer their materials back to the community.

1. Decide whether to make changes in place, or create a new repo and start afresh.
2. Catalog the material we have now.
3. Re-organize material so that it aligns with the instructors' guide (or rearrange the instructors' guide if that makes more sense).
4. Put generic setup instructions in the bootcamps repo, rather than in the main web site (the latter can easily refer to the former), and make it easy for instructors to clone and specialize those instructions. (People have some fairly strong opinions about how this should be formatted; we'll re-open that discussion at the start of July.)
5. Merge the stuff that's in our GitHub wiki pages into the bootcamps repository, then stop using wiki pages: our information is already too scattered, and since this is our least-used communication channel, it's the obvious candidate for weeding.

Regularize bootcamp operations.

This is the "how" to go with the previous item's "what". Much of it depends on a small SQLite database that cannot be in a public repo (since it includes personal identifying information).

1. Ensure that everyone is aware of the code of conduct, no matter how they sign up.
2. Make sure people know that anyone can use our content (which is all CC-BY licensed), but the Software Carpentry name and logo are trademarked, and that there are some restrictions on their use).
3. Create a unified online checklist for each bootcamp with to-do items for organizers and instructors. (There are currently checklists in two different repositories, which are inconsistent with each other.)
4. Create a mailing list per bootcamp, plus a host email address that forwards to the organizer(s).
5. Appoint an experienced lead instructor for each bootcamp so it's clear who's responsible for sorting out who teaches what, etc.
6. Incorporate a pre-assessment questionnaire into registration (or at least for those who get a seat).
7. Make immediate and delayed post-assessment a one-click process.
8. Make in-camp assessment more systematic (i.e., standardize a set of questions that should be asked at every bootcamp, and a way of reporting the answers).
9. Make it easier for potential instructors to find bootcamps, and for lead instructors to find partners.
10. Archive waiting lists from bootcamps so that people who didn't get in last time are first in line the next time. We could potentially keep track of no-shows as well: someone who has registered, but then fails to attend without explanation, should probably be put at the back of the line for future bootcamps, but this could be problematic to implement.
11. Automate synchronization of bootcamp announcement pages on the web site, EventBrite registration pages, bootcamp GitHub repositories, mailing lists, and GitHub tickets.
12. Collect feedback on instructors to help them improve their teaching (and then actually give it back to them). This will have to be done carefully—we have no wish to encourage a "big brother" atmosphere—but it will help maintain and improve quality.
13. Finish, deploy, and publicize the Windows installation script and the "check my machine" scripts.

Line up our next eight months of bootcamps.

We need to book things further ahead, so that we're scrambling at the last minute to find instructors less often. We also need to start targeting conferences and other disciplinary clusterings, rather than doing things geographically.

1. Contact all previous bootcamp hosts and ask if they'd like a return visit.
2. Since demand now outstrips supply, we should probably also think about some sort of bidding process, e.g., sites where people are doing instructor training or are willing to help out with bootcamps elsewhere get priority.

Finish the instructors' guide.

We desperately need more instructors; we also need to do more to ensure that people are teaching the same (kinds of) things, or at least are aware of what other people are teaching.

1. Create a concept map for each section. (None exist yet.)
2. Create challenge problems for each section. (About half are done.)
3. Draw 250 diagrams. (I'd rather stick a spoon up my nose, but it needs to be done.)
4. Create a printed version (because some institutions still take books more seriously than web sites).

Simplify contribution to the web site.

If we want more people to contribute more content, it needs to be a lot easier to update a page or write a blog post. In the long term, this probably means either building something that integrates with the services we use (like EventBrite and Google Calendar), or switching to a hosted customer relationship management system, but that's not going to happen this summer.

1. Start using Pelican (or maybe Nicola) instead of our home-grown tool.
2. Stop using sub-modules for the 3.0 and 4.0 material (which probably won't ever change again).

Rationalize the mailing lists.

Dreamhost (our ISP) supports Mailman, but doesn't give us access to Mailman's command-line scripting interface (because mail is hosted on different machines than shell accounts). We therefore have to manage list membership manually, which produces all sorts of minor inconsistencies. We're planning on switching ISPs anyway (Dreamhost is increasingly unreliable), so we have an opportunity to fix some of these problems.

1. Make sure the ISP we switch to offers scriptable mailing lists.
2. Integrate mailing list management with our roster.

Regularize instructor training and badging.

We're now running the instructor training for the fifth time, and we've learned a lot about what works and what doesn't.

1. Put a rough curriculum on the teaching web site.
2. Switch from a WordPress blog to a compiled web site using the same tooling as the main web site.
3. Clarify the certification process: people must complete the training and teach at least once under the supervision of an experienced lead instructor.
4. Start generating PDF certificates for instructors as well as digital badges.

Certify learners.

We've been asked several times to provide certificates of completion. We would rather provide certification of accomplishment, i.e., give people something only once they've demonstrated some level of proficiency, rather than for sitting through two days, but we can certainly do both.

1. Choose and publicize proficiency assessment criteria.
2. Automate production of PDF certificates and digital badges for both completion and proficiency.
3. Make sure that whatever we do for proficiency integrates with the driver's license being developed in conjunction with the Software Sustainability Institute.

Miscellaneous

• Create better publicity materials. We retired our 90-second pitch months ago because it no longer represented what we actually do. We need to create new ones aimed at potential learners, hosts, instructors, and backers. We also need to write a paper that people can refer to when they want to cite us—our Best Practices in Scientific Computing paper isn't quite that. (Software Carpentry: Lessons Learned is a start toward this.)
• Break the assets repository into several pieces. At the very least, assessment materials, papers, and checklists should be in their own repos.