Re: Teaching GNOME to students...

[Sebastian Pölsterl <marduk k-d-w org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Emmanuel Fleury schrieb:
> 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),
> 
That's a wonderful idea. I always hated the programming stuff in
university were you program something that's already available and once
your done just through it away, because the same thing but much better
already exists. I could imagine that it makes more fun when you see that
a part of your code is actually included in a piece of software that is
used by many people.

> 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).
> 
I can understand that it's frustrating if it appears that nobody is
interested in your patch. I think it's the right choice to ask for bugs
developers are interested in first.

> 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).
> 
> 
In general I think looking at gnome-love bugs will already give you
plenty of bugs with different levels of difficulties.

What I don't understand is why you differentiate between bugs and
feature requests. From my point of view there's no big difference,
especially for a programmer. In both cases you get to familiar with the
code and write a patch.

For Deskbar-Applet currently three bugs come to my mind:
- - Adjust files modules that the query string can appear everywhere in a
file's name (case in-sensitive) (see bug 491404)
- - Add possibility to add/change/remove directories that the files module
searches in (see bug 443975). Add home dir and XDG special dirs by default.
- - Programs Handler should notice newly installed programs. Someone
wanted to work on this, but I got no update from him/her. In addition,
the gio port must be completed first. (see bug 343894)

- --
Greetings,
Sebastian Pölsterl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkN5YAACgkQ1ygZeJ3lLIfOsACcDyjjd8l1b/il1ntJEvqrvKmW
9eQAn3DXF25MsqVIIL5+4EAHDc+O4mss
=5Mhc
-----END PGP SIGNATURE-----