[TOS] choosing projects for students to contribute to

William Cohen wcohen at redhat.com
Mon May 11 19:15:12 UTC 2009


Joel Sherrill wrote:
> On Fri, May 8, 2009 at 1:52 PM, William Cohen <wcohen at redhat.com> wrote:
> 
>> tridge at samba.org wrote:
>>
>> 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.
>>
> 
> I hope that the students who found issues with the projects they evaluated
> gave
> feedback to the project.  Would be interesting for the evaluation to include
> feedback
> from the project or a report that they addressed an issue. :)

In these cases I told the student to ask on the mailing list how to submit the
patches (keypassx and soapui are two example). The project developers worked
with them and incorporated the student's patches into the upstream projects, but
I don't think there were changes to wiki or readme on these procedures. Maybe I
should have suggested to the students to write a patch on to describe how to
submit a patch for these projects. :)

> Sometimes the documentation they are looking for isn't there, sometimes it
> isn't
> where they thought to look, and sometimes it exists but could stand to be
> improved.
> It is important to realize that people have different chains of thought and
> what
> might be easy to find to one person might be near impossible to another.

Yes, the documentation and description of procedures leave something to be
desired for some projects. Developers that started with the project early on may
not be aware of those barriers for entry. Having students work on the less well
documented projects might be a valuable lessons for many students that are use
to working on one semester throw-away projects. The temptation is just worry
about writing a lot of code to implement the semester project. Having them feel
a little pain might make them more compassionate programmers that are willing to
spend a some time documenting the code and processes to ease the suffering of
other programmers. Too often student are told to do things in a certain way, but
they haven't taken the lesson to heart until after they find themselves on the
wrong end of one of those situations.

> But in the end, I hope all FOSS projects would be open to hearing
> constructive
> criticism and try to improve.  I know we do.
> 
> --joel
> RTEMS

Both the students in the class and the OSS project contributors were good about
having concrete discussions about the OSS projects. The software projects that
student worked on during the semester seeem to have taken the comments well and
work with the students to improve the OSS projects.

-Will




More information about the tos mailing list