June 2013 Lab Meeting

We covered a fair bit of ground in 90 minutes; the highlights are below, and comments from both attendees and everyone else would be very welcome (either here or on the 'discuss' mailing list).

Making bootcamps more useful:

1. Clearly distinguish bootcamps for complete beginners from those for people who already have some coding skills.
2. Do not publicize the bootcamp until the curriculum has been specified so that learners can make an informed choice about signing up.
3. Provide a consistent pre-assessment to help people make this decision before they sign up (and to give instructors a clear idea of who they're going to be teaching).
4. Encourage people to teach bootcamps spread out over several days or weeks when instructors and learners are co-located.

Sustainability (see this post for background):

1. Poll hosts of previous bootcamps to find out what their actual costs were, and whether they would have been willing/able to donate $1000-$1500 per bootcamp to help keep the lights on.
2. Depending on the results of that poll, start asking for donations toward central costs.
3. Explore the PLOS model of different charges and waivers for different countries.
4. Pursue corporate sponsorship (either on a per-bootcamp basis, or as general donations to the cause).
5. Try once again to get funding through existing science training programs.
6. Encourage qualified instructors to teach Software Carpentry commercially, for whatever they can charge. (We will not be involved in these negotiations, and will not "tax" these activities, but would appreciate instructors talking with us before approaching clients so that we're not tripping over each other.)
7. Create a new mailing list for people interested in discussing this. (If you'd like to be added please mail me.)

Consistency:

1. To use our name and logo:
   • At least one qualified instructor.
   • At least two full days (though this may be spread out over a longer period).
   • Cover version control, testing, task automation, and modular program development.
   • Most attendees to date work in science, engineering, medicine, and related fields (we're not teaching web development to salespeople). We are already extending our reach to people in other data-intensive disciplines, but for now at least, the digital humanities are out of reach: we simply don't have enough instructors (or enough experience).
2. To be an instructor:
   • Complete our online training (which includes teaching at least once with a more experienced instructor),
     or
   • Demonstrate extensive relevant teaching experience (and teach at least once with a qualified instructor).
3. These requirements will only affect upcoming bootcamps and instructors, not those already scheduled or badged.

Simplifying our shared content, web presence, and workflow.

1. Designate a lead instructor for each bootcamp.
2. Streamline the reimbursement process. (Ideally, we want host sites to reimburse instructors directly, but we realize that we'll often be involved, particularly when people are teaching several bootcamps in one trip.)
3. Make it much easier for people who are not yet Git experts to update bootcamp web pages, contribute teaching materials, etc. We are discussing this on the 'gits' mailing list; please join us there.

Notes:

• Some people proposed having a warm-up day for complete beginners, followed by a regular two-day bootcamp that would appeal to people who already have some skills. We'll need to experiment with this to see how well it works.
• There was disagreement over whether testing should remain a required topic: some instructors barely touch on it, and others disagreed over what it ought to mean for day-to-day scientific computing. As Software Carpentry's CDFL¹, I ruled that it is required; however, we need to integrate into the other material rather than teaching it as a standalone topic.

[1] Curmudgeonly Dictator for Life.