[Osdc-edu-authors] ARTICLE READY: CS professors speak back: capturing an hour of SIGCSE conversation

Mon Mar 28 21:23:59 UTC 2011

Picking up on 
https://www.redhat.com/archives/osdc-edu-authors/2011-March/msg00044.html, 
which is now ready to push. As usual, please edit (the ending could use 
a bit more punch, but is workable as-is), improve title, pick an image, 
etc. without blocking on me further - I'm trying to turn into a content 
machine at the moment.

--Mel

--------

CS professors speak back: capturing an hour of SIGCSE conversation

--------

We asked you earlier <a 
href="http://opensource.com/education/11/3/what-do-you-want-ask-1200-cs-professors">what 
you'd ask 1,200 CS professors about open source</a> given the chance. So 
when I headed down to Dallas, Texas for <a 
href="http://sigcse.org/sigcse2011">SIGCSE 2011</a>, the largest 
Computer Science education conference in the world, I took your notes to 
the <a href="http://teachingopensource.org">Teaching Open Source 
(TOS)</a> Birds of a Feather session and listened in on the 
conversations there - thanks to all who attended for the insights, and 
to <a href="http://blog.sdziallas.com">Sebastian Dziallas</a> from <a 
href="http://olin.edu">Olin College</a> and <a 
href="http://heidiellis.wordpress.com/">Heidi Ellis</a> from <a 
href="http://wnec.edu">Western New England College</a> for organizing!

Attendees ranged from PhD students like <a 
href="http://www.uci.edu">University of California, Irvine's</a> <a 
href="http://www.ics.uci.edu/~leep/">Patricia Lee</a>, 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 <a 
href="http://www.cs.trincoll.edu/~ram/">Ralph Morelli</a> from <a 
href="http://www.cs.trincoll.edu">Trinity College</a> who is one of the 
leaders of the <a href="http://hfoss.org">HFOSS (Humanitarian Free and 
Open Source Software)</a> collaboration. Conversation topics likewise 
ranged from <a href="http://code.google.com/soc/">Google Summer of 
Code</a> to IBM's SWT Java UI library to the <a 
href="http://openhatch.org";>OpenHatch</a> project for finding "starter 
problems" for students to tackle. A group on the side discussed the 
scaleability of Toronto's <a href="http://ucosp.ca/">UCOSP 
(Undergraduate Capstone Open Source Projects)</a> program while another 
group talked about incorporating open source participation into service 
learning initiatives. Thanks to collaborative notetaking with <a 
href="http://etherpad.org";>Etherpad</a>, 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? <a 
href="http://www.calstate.edu/">California State University's</a> <a 
href="http://www.ecst.csuchico.edu/~tyson/">Tyson Henry</a> 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.

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 - 
'This is what I hand to students to help them pick a project,'" said <a 
href="http://www.beloit.edu/computerscience/faculty/huss/">Steve 
Huss-Lederman</a> from <a 
href="http://www.beloit.edu/computerscience">Beloit College</a> 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, <a 
href="http://www.uwc.ac.za/?module=cms&action=showfulltext&id=gen11Srv7Nme54_9283_1210050506&sectionid=gen11Srv7Nme54_4157_1210050505">Grant 
Hearn</a> from the <a href="http://www.uwc.ac.za/?module=cms">University 
of the Western Cape</a> suggested competency categories rather 
than hard rubrics - did they do something related to 
documentation in the project, did they write some form of 
feature specification, can they hand you a chat log with a remote 
developer from their 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 <a href="http://www.immaculata.edu/node/259">Mary 
Elizabeth Jones</a> from <a href="http://www.immaculata.edu">Immaculata 
College</a> 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." <a 
href="http://www.pages.drexel.edu/~hislopg/">Greg Hislop</a> from <a 
href="http://drexel.edu">Drexel University</a> 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. <a href="http://heidiellis.wordpress.com/">Heidi Ellis</a> from 
<a href="http://wnec.edu">Western New England College</a> 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 <a 
href="http://www.cs.uic.edu/~jbell/">John Bell</a> from the <a 
href="http://www.cs.uic.edu">University of Chicago</a>, where his 
students run <a href="http://www.flourishconf.com";>FLOURISH</a> 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. <a href="http://cs.union.edu/~striegnk/">Kristina 
Striegnitz</a> from <a href="http://cs.union.edu">Union College</a> 
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 <a 
href="http://sugarlabs.org";>Sugar Learning Environment.</a>.

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.