This article is co-authored by Heidi Ellis.
Last week 11 academics and two industry professionals spent three days in New York participating in something that would look like a doc sprint to open source contributors. Instead of working on project documentation, though, this sprint was focused on producing computer science- and open source-focused learning activities, which are similar to "experiments" for those familiar with chemistry or physics courses.
What is a doc sprint? A doc sprint is a short period when a group of people come together, virtually or face-to-face, to collaborate on writing documentation. (from Mozilla)
The goal of this sprint was to create activities that instructors interested in incorporating open source into a variety of different courses can use. The sprint was supported by a National Science Foundation (NSF)-funded project to investigate the potential for student learning from a professional open source community (called "vertical teaming").
Creating learning activities—or, in fact, any curricular materials—is usually something the instructor does alone, and it’s incredibly time-consuming. Even the creation of an end-of-unit quiz requires deep subject matter expertise along with knowledge of good testing practices. Learning activities can be more time-consuming to create, as they involve interactions with real-world systems, or in the case of open source, real world communities, which are constantly changing—and are not well-documented in textbooks.
Taking a doc sprint approach, however, allowed the instructors to combine their individual skill sets—along with those of the two industry participants—in order to collaboratively generate a variety of high-quality learning activities that can be used across computing curricula.
Who was there and what did we do?
Over the past several years, Red Hat and the NSF have funded serveral Professor’s Open Source Software Experience (POSSE) workshops, which help faculty members learn how to involve students in Free and Open Source Software (FOSS) projects. A set of materials has been created, and during this workshop instructors worked to expand that initial set of activities. The participants were all leaders or alumni of POSSE:
- Greg Hislop from Drexel University
- Lori Postner and Darci Burdge from Nassau Community College
- Heidi Ellis and Stoney Jackson from Western New England University
- Evelyn Brannock and Nanette Napier from Georgia Gwinnett College
- Ben Coleman from Moravian College
- Ruby El Karboutly from Quinnipiac University
- Suzanne Mello-Stark from Worcester Polytechnic Institute
- Alex Mezei from Lenoir-Rhyne University
- Gina Likins and Nick Yeates from Red Hat
Following the "scratch your own itch" motto that is prevalent in FOSS communities, the group split into teams of 2-4 people based on participants’ interests and gaps in materials that had been created in previous POSSE sessions.Teams worked on activities for areas as varied as mobile applications, capstone projects, CS1, and "open source for non-programmers." The team also made progress on some higher-level issues, like activity templates and organization, which allowed us to move forward on some big picture issues as well.
Original image by Heidi Ellis, CC BY-SA 4.0.
Periodic "report out" sessions allowed each team to inform the group of progress, get feedback on what they had completed, and identify potential areas for further work. In addition, the face-to-face nature of the meeting allowed teams to quickly regroup as necessary. For example, after a report-out session, I temporarily joined a group working on a UI/UX activity, as I have experience in that area.
All the materials—18 new activities and several more updated ones—are licensed under Creative Commons and available for modification and use. Though the materials were created with college courses in mind, some activities can even be used with K-12 students.
Original image by Heidi Ellis, CC BY-SA 4.0.
Why use this approach for curriculum development?
The materials sprint has many advantages when developing course materials. In addition to the very real benefit of developing additional ways for instructors to involve students in open source, the camaraderie of group development provides motivation and makes the experience fun!
Group development provides additional input into the activity development, while also providing additional eyes to proof and test the activity —similar to another FOSS motto that "given enough eyeballs, all bugs are shallow." Involving industry professionals brought another set of benefits—their industry experience allowed us to make the activities more relevant and meaningful for students.
And finally, it’s always neat when you practice what you preach: Instructors using a docs sprint-like approach to collaboratively generate open source curriculum materials is a beautifully self-referential and effective activity.