[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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

- 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: