For the boot camp at UCL, we tried using Mercurial (with EasyMercurial) instead of Subversion in the version control segment.

You can see the plan for the segment on this EasyMercurial project page. Briefly, we opened with a few plain slides about the purpose of version control, followed by a hands-on example in three parts (working by yourself, working by yourself with an online remote repository, and working with others). We started at the beginning and got as far as “hg bisect”, but did not cover branching.

I was presenting the segment, so I’m not well placed to judge how effective it was as a learning experience.  But I did make some notes.

Read more…

We’ve come to the end of a hot, slightly sweaty, two days of learning in UCL and have just done a straw poll of participants of the good and bad points of this bootcamp. Something that was trialled at UCL was asking participants to sign up in small (3-4 people) teams drawn from their local research group.  In total, we had a little over 40 learners and 10 helpers. We also taught the version control portion using EasyMercurial (thanks to Chris Cannam from SoundSoftware).

Here’s what we learned…

Read more…

The online portion of our work with learners at the Space Telescope Science Institute wound up today. 6 of the 14 people who took part in the on-site workshop submitted “graduation exercise” videos, and three more sent apologies (time pressure, technical difficulties, etc.), which I think is a pretty good completion rate. As always, we finished up by asking everyone to give us one good and one bad thing about the class:

Some of the apparent contradictions in the “Bad” column reflect the diversity of learners’ backgrounds; once again, I think this was the biggest challenge we faced. Overall, though, it was an interesting contrast to my experience running a class through P2PU. I’ve taught the content of Software Carpentry dozens of times over 14 years, so I had something immediate to draw on for the folks at STScI. On the other hand, I’ve never completed a course online myself, so I didn’t have relevant personal experience to bring to bear at P2PU. I hope that by engaging local helpers in future boot camp follow-ups, we’ll help to grow a pool of people who can do that kind of teaching better.

We have been asking people the questions below before the start of a boot camp in order to get a handle on how much they already know. As part of evaluating the current round of work, we’d like to expand the list a little, and touch on a few more topics.  Our rough categorization of how much someone should know about various things is in the competence matrix; ideally, we want another 3-4 questions on each topic. Our criteria are:

Read more…

Last week’s boot camp at the University of Toronto was not the most successful one we’ve ever done: quite a few registrants didn’t show up, and based on feedback from the instructors, we tried to cover too much, too fast. That said, the learners who stuck with us all the way through to Friday afternoon came away knowing a lot of useful things (or at least knowing that those things existed). We’ll gear back a bit for next week’s workshop at Indiana U. and see how that goes.

We have finalized our first set of Software Carpentry badges—with luck, we’ll list the first set of recipients later this week.

	for people who complete the core curriculum
	for helping to teach (either workshops or online)
	for organizing workshops
	for creating (or fixing) content

Before writing yesterday’s post about assessment, I should have explained what I mean by”fundamental concepts”.  I’ll start with Lewis Epstein’s wonderful book Thinking Physics:

Read more…

The single biggest challenge Software Carpentry faces right now is how to tell what impact it’s having. This is only partly to satisfy funders—as I said back in December, if we don’t know how to tell if we succeeded, we’re going to fail. It would be (relatively) easy to put together a multiple-choice quiz to see how much people have learned about basic shell commands, the syntax of Python, and so on, but that would only address the shallowest aspects of learning. We’re trying to impart some fundamental principles, and what we need is questions that will tell us whether people have internalized them. (As many studies have shown, it’s possible to get a decent score on a quiz without actually understanding the subject matter.)

For example, consider this question about Subversion:

Emmy wants to see what has changed in her working copy since revision 120. The command she should run is:

1. svn log -r 120
2. svn diff -r 120
3. svn revert -r 120
4. None of the above

It addresses Q05 (“How can I keep track of what I’ve done?”) fairly directly, but not R02 (“Use a version control system”), R03 (“Automate repetitive tasks”), or any of the basic principles. Open-ended answers might do the latter, but it’s hard to come up with ones that don’t lead the witness: asking, “When would you use a version control system?” isn’t going to give us much insight into what people actually think. We could combine a few multiple-choice with a few open-ended, but realistically, if it takes more than 10-15 minutes for people to answer, many (most?) won’t. If anyone can see a way to square this circle, I’d welcome ideas.

One of our key deliverables for the Sloan Foundation-funded work is a badging program built on top of Mozilla’s Open Badges Initiative. Riffing on our new logo, Carri Han has designed three badges for us:

	for people who have mastered our core content
	for people who have organized and run workshops
	for people who have created content

Please let us know what you think.

I’ve been asking people to fill in the short questionnaire below before our workshops in order to give us a better idea of what they want and what they already know.  How do you score, and how could we improve the questions?

Read more…