Re: to DPL candidates: getting new people to Debian
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
Reply to: