On Sat, Mar 16, 2013 at 04:28:03PM +0100, Lucas Nussbaum wrote [edited]: > On 16/03/13 at 15:31 +0100, Serafeim Zanikolas wrote: > > have > > you considered assignments for the preparation of patches for wishlist bugs > > in > > native and pseudo-packages (eg. infra-related sw projects)? > > Have others thought about that/tried to organize such university > projects?
There's this (master's, I think) module, ran by an academic who's a FreeBSD member, with goals amongst others: Appreciate and understand maintenance activities Be able to change existing systems http://www.dmst.aueb.gr/dds/ismr/intro/indexw.htm http://www.dmst.aueb.gr/dds/ismr/index.htm You can see in their "hall of fame" examples of successful contributions. > YMMV, but due to the way student projects are organized in France, the > following problems are often blockers: > - Tasks are not long enough. Typically, what you need is something that > would take an experienced DD about 40 hours (for part-time projects > with groups of 2 to 4 students). Many of tasks are much > smaller than that, and you can't just aggregate several tasks, because > then, the project loses interest in terms of "project management". Assignments don't necessarily have to have a patch as the sole deliverable. Smaller ones could very well be about producing a design or triaging bugs (reproducing, documenting approaches that didn't work, and so on). > - I don't know the software, and there's no one willing to act as > backup-mentor on the Debian side, in case I cannot answer the > students' question. > > - The project is not motivating enough for the students (it does not > result in exposing the students to sufficiently-interesting > technologies, for example). If I understand correctly, in the aforementioned course, they don't point students to specific projects or issues to work on. So it's up to the students to find something they find do-able and interesting enough to work on. > - The amount of learning required to be able to do the project, compared > to the amount of work to do, is too high. I don't see that as a problem if documenting what one's learned is part of the deliverable you grade. > - (for infrastructure) setting up a development instance is not > documented, impossible, or extremely difficult. Indeed that's an issue for infra projects -- and a point of improvement for us. Anyhow, I think that whatever we'd do to make such academic assignments easier would be useful to potential contributors in general. A couple of other ideas to encourage work on wishlist bugs of infra & native packages: - tag them as wontfix, needs-discussion or patch-welcome - for patch-welcome bugs, tag them also in terms of order of magnitude of time required to fix (eg. hours, days, weeks; yes, it depends on a bunch of factors, but it'd be better than nothing) With this info in place combined with debtags data (eg. implemented-in::*), one could develop a web page where newcomes can ask "I know language X and have a spare weekend to code. what should I do?" (this would be similar to wnpp-by-tags.debian.net but for native Debian projects instead). -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20130317135412.GC6878@mobee
