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: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
