Software Carpentry at Oklahoma State

This post originally appeared on the Software Carpentry website.

I recently instructed Git for the third time at a Self-Organised workshop on the Oklahoma State University main campus. I enjoy instructing and helping with the Software Carpentry workshops (and hopefully will get to do a Data Carpentry soon) and each workshop is always different from the last, so I was excited to participate again.

Because of a scheduling conflict, we only had the lab for five hours on Day One. In five hours (with two 15-minute breaks), we went through the entire bash shell lesson without many hiccups. One thing we did create for the bash shell lessons was a series of three-question quizzes we launched live on Socrative before each break. The learners had good feedback about this and felt it was a good way to break up the lessons and provided a good review of concepts they had just learned.

On Day Two, we started Python, but because of some delays, we started behind. Once we got started, lesson went well (not very many typos!) and we were able to get through a few episodes in the Python lesson, but we weren’t able to get through much of the material we had hoped to teach. We also decided not to issue the Python quizzes because we were behind.

However, at this point, the learners seemed satisifed with their progress thus far! The coffee and donuts may have helped, too!

Side note: many of the learners wanted more experience in Python. This was also reflected in the surveys. We are going to take this into account with future workshops in that we should plan to be more Python-heavy. Because we weren’t able to get to a lot of the material, we are offering an additional afternoon Python workshop to everyone who was at the Python session within the next two weeks. Luckily, all of our learners were local.

After lunch, we started on Git - my lesson! For the third time teaching Git at a SWC workshop, it went the best it has ever gone! I was enthusiastic to get started. I had typed up my own notes and had a PowerPoint slide of images I wanted to use to demonstrate Git concepts. I even had some Git jokes up my sleeve to keep the class on its toes. I’ve found that with each time I teach Git I get more and more comfortable to the point that I can go “off script” and throw in extra jokes, tidbits of information, etc.

What really helped the Git lesson go smoothly is that I had a Git “partner-in-crime” who has been helping me with the collaboration portion of the lesson since I first began teaching Git. If you break the class into pairs and are using two instructors to go through the local and remote steps, I find it helps to spend a minute or so making sure each member of each pair knows which instructor they are supposed to follow. We did this by writing “Partner A” and my name and the word “local” on the whiteboard. We also wrote “Partner B”, my partner’s name and “remote” on the board. I told the pairs that all the people sitting to my left (holding up my left hand) was a “Partner A”, and all those sitting on my right was a “Partner B.” Then I had all the “Partner A” learners raise their hands when I asked who was to follow me. Then my partner had all the “Partner B” learners raise their hands when she asked who was to follow her.

Side note: I had also frequently used the word “local” in the lesson leading up to this point to describe our repositories on our own computers, so I think this helped establish the difference between “local” and “remote” well before we got to the Github/remote repository portion of the lesson.

We started the Git lesson at 1:05 p.m. and ended the conflict portion of the lesson at 3:45 p.m. This gave us 15 minutes to briefly go over things like open science, licensing, citing & hosting as well as to encourage the learners to take the post-workshop survey while we answered questions and ended the day on an uplifting note. At the end, everyone was happy the workshop was over, but I think ending the workshop on Git is a good idea because the material is less “type-heavy” and more interactive. And again, the jokes!

Find some Git jokes here

---

If you’re interested in what happened leading up to the workshop, you can continue reading below.

I want to mention that SWC and DC probably operate a little differently at OSU than most other institutions. Over the past year, we’ve built a solid “Carpentry team” consisting of six certified instructors, a plethora of helpers and a list of students, faculty & staff who want to become certified in the near future. We all meet monthly, and because of this, my experiences with planning, coordinating and instructing this workshop will probably be a little different than most.

Planning: When the team met up at the beginning of the academic year in August, we knew we wanted to host a workshop fairly quickly. After looking over several dates, we decided on October 13-14 because classes were cancelled on the 14th for OSU’s fall break. We thought this might give students, faculty & staff an opportunity to attend the workshop all day on Friday. However, when we went to go book the computer lab we normally use for the workshops, it wasn’t available until noon on the 13th. After a little bit of discussing, we decided to go ahead and do a five-hour session for Day One, and then do the normal 9am-4pm schedule for Day Two.

Coordinating: Because I’ve coordinated one of our local Self-Organised workshops, I helped a team member who was going to be more active with the coordination duties get this workshop set up. Once he filled out the SWC workshop request form, I helped him get an EventBrite registration page set up and recorded registrant information in a shared spreadsheet, while he worked on building the workshop webpage and Etherpad and communicated with Maneesha Sane at SWC.

Pre-workshop: About a week before the workshop, all the instructors and several of the helpers met up to go over the gameplan for the workshop. The instructors discussed how we were going to prepare our lessons and what material to make sure to include and what we could leave out if we were running short on time. In previous workshops, we had one to two learners who fell behind the class and sometimes slowed the pace down to ask questions, so we picked a few more experienced helpers who said they were willing to help with any learners who might be falling behind. We suggested that helpers focus in on a section that way they wouldn’t be running into each other going from one side of the room to the other. Finally, we set some “expectations” for instructors and helpers, i.e., it is ok for the helpers to let the instructor know if they need to slow down/speed up based on their observations of the pace of the class.

At this time, we also looked at our list of registrants from our EventBrite site to determine what fields of study or departments they were coming from and to gauge their experience levels and what type of data they might be working with. I would definitely suggest putting a few demographic questions in with your EventBrite registration.

If you made it this far, I hope this was all helpful advice if you’re getting ready to coordinate your own workshop!