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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
