We asked you earlier what you'd ask 1,200 computer science professors about open source given the chance. So when I headed down to Dallas, Texas for SIGCSE 2011, the largest CS education conference in the world, I took your notes to the Teaching Open Source (TOS) birds of a feather session and listened in on the conversations there. Thanks to all who attended for the insights, and to Sebastian Dziallas from Olin College and Heidi Ellis from Western New England College for organizing!
Attendees ranged from PhD students like University of California, Irvine's Patricia Lee, just starting her teaching career with a computer architecture class and looking to venture into teaching open source from the start, all the way to seasoned faculty members like Ralph Morelli from Trinity College who is one of the leaders of the HFOSS (Humanitarian Free and Open Source Software) collaboration. Conversation topics likewise ranged from Google Summer of Code to IBM's SWT Java UI library to the OpenHatch project for finding "starter problems" for students to tackle. A side group discussed the scaleability of Toronto's UCOSP (Undergraduate Capstone Open Source Projects) program while another group talked about incorporating open source participation into service learning initiatives. Thanks to collaborative notetaking with Etherpad, we managed to capture the highlights of our conversations. Turns out the professors had some questions of their own.
How do we select appropriate student projects? California State University's Tyson Henry turned the question on its head and pointed out that students were far more engaged in projects they chose--and furthermore, that learning how to identify good opportunites for contribution was part of the learning experience. It was quickly noted that one role of the professor in this case was that of sanity-checker--excited students often propose grand projects on a monumental scale, so faculty members with more project management experience need to step in and help student teams focus in on realistic goals so they can make a solid first step towards their vision in the space of a semester.
Finding the balance between freeing students to experiment and guiding them enough to ensure success. When working with real-world environments such as open source communities, professors have to balance the duality of helping their students become independent learners with the desire to make sure they have a successful experience. When do you need to add structure to the messiness so that students don't get lost, especially given the time constraints of getting something meaningful done within a semester? "I wish someone could show me a worksheet [to] hand to students to help them pick a project,'" said Steve Huss-Lederman from Beloit College while explaining that teaching materials could help strike a nice balance between independence and guidance. Since this is a shared problem amongst professors getting their students involved in open source communities, fostering a commons of things like homework assignments and evaluation rubrics would be beneficial.
How do you gauge student success? When the completion of a project hinges on many factors outside a student's control, professors need to find different ways of grading. It's unfair to penalize a student for good work that wasn't accepted as a patch simply because an external dependency slipped or an outside developer didn't respond to their email before the semester ended. To address this, Grant Hearn from the University of the Western Cape suggested competency categories rather than hard rubrics--did the student do something related to documentation in the project? Write some form of feature specification? Can the student hand you a chat log with a remote developer from upstream (regardless of the outcome of that conversation)? Figure out learning objectives and turn them into benchmarks that are under the student's control.
What things are open source experiences good at teaching? As Mary Elizabeth Jones from Immaculata College pointed out, the same introductory CS class material may lead to completely different learning experiences. Compare a CS 101 class whose goal is to learn basic Java syntax to one whose objective is to experience your first software development lifecycle. Greg Hislop from Drexel University added that open source projects are particularly good at soft skills that are harder to measure than, for instance, whether a student has memorized the difference between shell and bubble sort. The benefits of seeing and working with code they haven't written, gaining multicultural sensitivity via working with teammates from all over the world, or having to defend their feature proposals to an audience of industry veterans are more difficult to quantify, and easy to miss in the rush of the semester. That's why objectives like "become an effective team member" need to be supported by assignments like journal writing or team dynamics counseling that make students step back and engage in metacognition about the non-technical skills they're picking up.
How open source projects should present themselves to faculty. Avoid being perceived as unstructured, multiple professors suggested. Highlight the many different types of contributions all levels of students can make. Many faculty associate "open source" with "code contribution" and relegate it to the realm of senior capstone projects, mising potential opportunities to get younger students involved with documentation, testing, or design.
Open source projects aren't perfect. Sometimes open source projects have poor software development practices. This is the reality of the "natural software development experience"--when was the last time you joined a company that did everything perfectly? These are actually great opportunities for students to turn around and try to improve their project's practices using the skills they're learning in class. Heidi Ellis from Western New England College told of the "aha!" moment incomplete documentation gave her students--"Oh! That's why I should comment my code!"--as she silently cheered at the revelation.
It's hard to relinquish the seat of expertise at the front of the room. "My students know more than I do," said John Bell from the University of Chicago, where his students run FLOURISH, an annual conference on open source. John himself hasn't gotten involved in an open source project, but came to SIGCSE in part to spread the word about what his students are doing - something that takes a lot of courage for a faculty member who's typically expected to be "the sage on the stage" with all the answers. Multiple professors suggested easing into teaching open source with small independent study groups instead of starting with large classes right away, since both students and professors are used to thinking about independent studies as learning engagments steered by students and facilitated--rather than dictated--by faculty.
Open source really does make a difference to students. Despite the awkwardness and occasional missteps that come from trying anything new in the classroom, the early promise of their first experiments with students were what motivated faculty to keep trying to make open source work in their classroom, year after year. Professors told stories of their students coming back from job interviews saying that they'd spent the entire time discussing their open source work with prospective employers. Kristina Striegnitz from Union College explained that she'd gotten involved in open source in order to attract more women to her school's CS major and now had a multidisciplinary group of female students meeting outside of class to work on the Sugar Learning Environment..
It was this last point that made the biggest impression on me throughout all of SIGCSE; every single attendee I met was there for their students, in some cases flying halfway around the world to attend. I saw faculty members buying robotics kits with their own money to give away to teens from lower-income families in the hopes it would inspire them to play with technology. I thought I had been burning the midnight oil in preparation for the conference - until I realized that many attendees had done the same and were still doing grading in their hotel rooms every evening after conference activites were over. These were professors who genuinely cared about making a difference in the lives of their students, and I was heartened and inspired that they'd found open source participation one way to do so.
1 Comment