[TOS] choosing projects for students to contribute to

William Cohen wcohen at redhat.com
Fri May 8 18:52:55 UTC 2009

tridge at samba.org wrote:
> Hi All,
> While trawling through the TOS archives, one of topics that I saw was
> a discussion on choosing FOSS projects for the students to contribute
> to. I think it is really important that the students get a taste of
> participating in a real project, not just an artificial one created
> for the course, so Bob and I spent quite a bit of time thinking about
> this.
> We initially thought we should select a list of projects, and ask the
> students to choose one. At the time we thought this would be the best
> approach as it would ensure that the projects met some reasonable
> parameters that made them suitable for students to get involved with.
> However after thinking about it for a while, we decided that the
> students should select their own projects, but we would provide a set
> of criterion that the projects should meet. As it turns out, we are
> very glad we took that approach, as the students came up with a much
> wider range of really interesting projects to work on than Bob or I
> could ever have imagined.
> The criterion we chose was:
>     * The project is moderately active. 
>     * The project must use a FOSS license.
>     * We suggest choosing a project that is at least 3 years old. 
>     * The project should have produced a usable release.
>     * The project should be welcoming to new contributors. 
>     * The project should have several active contributors
>     * The project should be usable on the Ubuntu systems in the DCS lab 
> You can see more details on these criterion at
> http://cs.anu.edu.au/students/comp8440/labwork.php
> As you might imagine, we were concerned that the students might ignore
> these criterion and choose something completely inappropriate. To
> combat that we did two things:
>   1) the students needed to "claim" the project on a course discussion
>   forum. When a couple of students claimed inappropriate projects we
>   then discussed it with them and helped them choose better ones.
>   2) The students needed to give a 10 minute presentation on their
>   project at the end of the 5 day intensive part of the course. This
>   was only worth a small number of marks, but ensured that the
>   students had all chosen a project for their main assignment which
>   lent itself to study within the course.
> The other surprise to Bob and I was the number of students who took
> the course with very little programming experience (some had none at
> all). Some of the students had also never used a free OS. It still
> worked very well though, as those students just chose to contribute to
> projects in ways other than sending code patches. A number of them
> chose to help with translations, and other helped with
> documentation. The joy on one students face when during a lab he saw
> that he'd been accepted as the official translator for his native
> language for a well known FOSS project was marvelous.
> Cheers, Tridge
> _______________________________________________
> tos mailing list
> tos at teachingopensource.org
> http://teachingopensource.org/mailman/listinfo/tos

Hi Tridge,

I definitely agree with the this email! It is a valuable experience for students
to learn how to pick out their projects. Long after the class is over they are
likely going to pick out software projects that best meet their needs. If the
time is spent early on to pick a suitable project, then that can save a huge
amount of effort later on.

In the NCSU open source course (CSC591W) had a similar list in the "Evaluating
Open Source Software" lecture. Materials for the course are available at
http://people.redhat.com/wcohen/ncsu_opensource_course.tar.gz. There was a
written assignment to evaluate OSS projects. The students  addressed the items
on the list in their write up fairly well. One thing that tripped up the
students was some of the projects didn't have clear explanation on how to
contribute to the project. When doing it over I would certainly have the
students examine how new developers can get started on the project and whether
there are writeup explaining how to contribute to the project.


More information about the tos mailing list