Teaching GNOME to students...

[Emmanuel Fleury <fleury labri fr>]

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
-- 
Emmanuel Fleury

Associate Professor,         | Room:  261
LaBRI, Domaine Universitaire | Phone: +33 (0)5 40 00 69 34
351, Cours de la Libération  | Email: emmanuel fleury labri fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury