Re: Teaching GNOME to students...

[Behdad Esfahbod <behdad behdad org>]

Hi Emmanuel,

This is very interesting.  I wonder if it's possible to share your experience
and/or teaching material with others wanting to do the same in other schools
(myself included).

d-d-l may not be the best place for that.  academia-list [1] is.

Regards,

behdad

[1] http://mail.gnome.org/mailman/listinfo/academia-list

Emmanuel Fleury wrote:
> Hi all,
> 
> I'm associate professor at Bordeaux University and since few years I'm
> running a course with few other teachers about 'reading, understanding
> and managing _real_ code'. Since 2007, we chose to focus on the GNOME
> project because it matches everything we ever wanted to have for such a
> course:
> 
> - A large amount of code,
> - Enough complexity to get the students over-helmed with it,
> - Highly documented,
> - A skilled and reactive community,
> - A bug and feature-request database (see later on),
> 
> Our course is composed of a few theoretical courses and (mainly) three
> small projects:
> 
> 1- Dig a part of GNOME and extract some technical understanding of it.
> Make some slides out of it and present it in front of all other students.
> 
> 2- Take a bug from the issue list and dig it (bug resolution is not
> mandatory but at least have a deep explanation of the bug).
> 
> 3- Take a feature-request from the issue list and implement it.
> 
> Last year we chose the bugs almost on our own (thank a  lot Vincent Untz
> who did provide his precious help to us when we had to sort a bit the
> bugs and the feature-requests). Here is the result (in French, I'm
> afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html
> 
> For this year course it is now time for us to select bugs (not yet
> feature-request) and we would like to strengthen our link with the GNOME
> community by letting GNOME's developers suggest some bugs for our list.
> 
> Benefit will be for all of us (you, students and my teachers team).
> 
> First, it will let you choose bugs that you are interested to get solved
> (or a least... explored). Second, we noticed that our way of choosing
> last year made a lot of students very disappointed because nobody did
> get immediate interest in looking at the solution they proposed on the
> bugzilla (not all of them did post a patch but at least a few did).
> 
> Having somebody interested in the resolution of the bug means that this
> shouldn't happen again. Third, browsing all these bugs, trying to
> evaluate their complexity, if they might be just too stupid or too
> difficult cost us a lot of time... where GNOME's developers could
> already have this knowledge.
> 
> Now, let me describe the kind of bug we are looking at:
> 
> - It MUST involve programming skills (fixing the spelling of a
> documentation is not our focus).
> 
> - It MUST be confirmed, 100% reproducible and architecture independent.
> 
> - It SHOULD have a medium complexity (meaning that it requires at least
> to browse and understand at least several hundred lines of code in the
> application to get a deep understanding of it... remember that our
> course is about reading and understanding a code which is not theirs. On
> the other hand, don't expect the student to be good at it, so if the
> difficulty is too high this might be risky).
> 
> - It SHOULD not be in a high priority to fix it (if so, the students
> would be in concurrence with others and won't learn anything).
> 
> 
> We know by experience that choosing unsolved bugs is quite awkward
> because, indeed, they are 'unsolved'. So what if:
> 
> - The difficulty you did expect for this bug is the wrong one:
> 
> Well, this is the game. If you got misled and our team, when looking at
> the bug, did the same, it is up to the student to show us in his report
> that we did a wrong evaluation.
> 
> - The bug get solved before the student give his report back:
> 
> Still, he has to understand it, describe and evaluate the solution of
> the bug. This is not a problem.
> 
> 
> What do we expect from you...
> 
> Well, submit bugs (several if you wish) that you think are relevant in
> this context. We need the bug ID in the bugzilla database and maybe few
> lines to explain why do you think this bug is relevant. The list of the
> bugs which will be selected will appear here:
> http://www.labri.fr/perso/fleury/courses/EMC08/projects.html
> 
> We need about 12-15 bugs.
> 
> If some students select your bug(s), just take a look at the discussion
> about this bug on the bugzilla from time to time. I insist on the fact
> that you are NOT requested to reply to the students (they are on their
> own concerning their relation with GNOME community). Do reply only if
> you want to.
> 
> If a patch is posted, just do as usually... take a critical look at the
> patch and do what you want with it (hopefully, accept and merge it).
> But, you are not requested to give a mark on it (we do this internally
> and with our own criteria).
> 
> Concerning the feature-request, the constraints will be about the same
> (but later... :)).
> 
> 
> Thanks in advance for your help !
> 
> Regards