Re: Question for A. Towns - NM
David N. Welton wrote:
A. Towns writes, in his platform:
I think it's important that the project accept contributions from as
large and diverse a group of technically skilled people as we can
manage. I think the best way to achieve this is:
2. To have newcomers be invited to act as assistants to existing
groups; and for helpers be treated like individuals, rather than a
new build that needs a standardised test suite run over it.
Can you elaborate? What does this mean in practical terms?
So, part two.
Newcomers to Debian have a bunch of hurdles to overcome these days. As
part of finding a package and uploading it to the archive through a
sponsor they're expected to:
(a) find some piece of interesting software
(b) that's not so interesting anyone else has already taken it
(c) work on it for weeks or months for almost no recognition
(d) potentially have to beg random people for support for every
(e) have to do all this without official access to any of the
resources developers usually have access to
Beyond sponsored uploads, they also have to go through the n-m queue,
which means begging someone to say they like you, and then in many cases
(depending on AM) answering a fairly long series of not very interesting
and often not even very relevant questions.
This isn't a terribly effective way of running things -- its only
benefits are that it's simple, that it's scaling fairly well and it's
currently working. Its drawbacks are that it still wastes a lot of time
for a lot of people, and discourages good people from joining the
project -- eg, Jeff Waugh, who's release manager of Ubuntu has been
trying to make his way through new-maintainer for something like three
years now , at present, still unsuccessfully. Is there really any
doubt that the release manager of Ubuntu, and the past release manager
of Gnome doesn't have the technical skills to be part of Debian or
doesn't understand free software well enough to participate?
So I think the new-maintainer process has become far too bureaucratic;
and while there are certainly good historical reasons for this, I don't
think it's acceptable to keep it the way it is.
I believe the main resolution needed here is to change the AM role from
one of "quizmaster" to one of "mentor" -- that is the process of joining
Debian should be working with someone who's already an experienced
developer, basically assisting them with their work. To me that seems
beneficial for everyone involved: Debian gets a good chance to see if
applicants are skilled (and in what areas) and whether they can work
well with people, the mentor gets someone to help with their work, and
the applicants get someone to talk to while they're learning the ropes,
and can work on things that are immediately useful and directly
appreciated. I think the few times we've tried mentoring arrangements
within Debian they've worked really well.
There are a number of problems with actually doing this though.
Mentoring is good at creating cohesive teams that work effectively
together, but it's a small step from that to ending up with "cliques" --
that is, teams that don't work effectively with anyone outside the
clique, and easily end up in opposition to them. Other issues include
making sure that we've got enough people around who are good at
mentoring and teaching people who'd like to have new maintainers help
them out how to mentor. And there are still other potential problems,
like making sure that the concerns of people who've already been working
on these sorts of topics are dealt with rather than being roughshod
over; we certainly don't want to end up with a situation where
new-maintainer simply gets closed again.
I think these problems can be overcome though , and, if elected, one
of my first priorities (after supporting the RMs in getting the relesae
out, and improving the signal/noise on the lists) will be to work on
finding out how the above can be achieved and how any drawbacks can be
 There are a whole lot of free variables that can be tweaked -- both
advocates and sponsors already have some possibility of a mentoring
role, eg, though this isn't always taken advantage of. There's also
a lot of flexibility that can be taken advantage of in who can be an
AM and which applicants are assigned to which AMs.