Thank you Moray, and thanks to all other participants. Interesting topic, and
good content. There's no limit to how much could be said on the topic, but I'd
like to comment and add a bit [edit: or a lot].
I understand the talk's goals as easing the integration of new contributors in
Debian. Newcomers follow a path which we hope is accessible enough that the
contributor can get as close as possible from a theoretical unattainable point
where the contributor knows everything about Debian and can contribute to all
areas. While each contributor follows a unique path, these unique paths are a
series of paths through which several contributors go.
Each potential contributor who arrives wondering how he can help is starting
from a unique position determined by his skills and experiences. Moreover, as
nobody can aim for complete knowledge of Debian, nobody wants to reach the same
point. The destination chosen by a certain contributor may depend on the
contributor's career goals. It also depends on the distance, as contributors
will prefer to travel towards a destination not too far from their starting
point.
As a project, we have a huge challenge. We must first keep the roads as smooth
as possible, which, in a Debian-sized world, is an endless task; there are too
many roads to pave (and maintain). Second, we must advice travelers the best we
can on where to go and which paths to use so they can reach their destination.
The talk mentions some paths, none of which is as straight as we could hope:
* the packaging path
* the translation path
* the artwork path
It also briefly mentions the fundraising path and the press path, which are
rarely directly accessible for newcomers. Your talk shows improvements which could be done to our
roads and to our maps:
http://www.debian.org/intro/help
http://www.debian.org/devel/join/
http://www.debian.org/devel/join/newmaint
As the issues with maps exemplify, improvements aren't necessarily hard to
make, but costly. We need not only to keep investing in contributor
transportation, but to invest wisely.
I hope the above gives a good idea of the presentation's topic.
The packaging path
You point out that we direct prospects interested in the packaging path to
orphaned packages. http://www.debian.org/devel/join/ does contain:
Taking over an abandoned package is the best way to start out as a maintainer
-- not only does it aid Debian in keeping its packages well maintained, but it
gives you the opportunity to learn from the previous maintainer.
There is some logic in this too. Orphaned package are presumably those in the worst
state, so those which need love the most (in a sense), as the sentence seems to say.
However, someone's first package choice should probably be based less on how much the
package needs work and more on how easy (and rewarding) that choice will be. In a sense,
the sentence also considers this aspect - indeed, I suppose adopting an orphaned package
must be easier than packaging something from scratch. So I'm wondering if the sentence
wouldn't be trying to say something simple with an unfortunate choice of words. Could it
be that by abandoned package, it just meant packages in need of some help
(either O or RFA, perhaps even RFH)? I imagine taking over an RFA-d package should be
easier than an orphaned package. And responding to an RFH even easier than an RFA.
Packages not on WNPP
That being said, as I read this page, something even more worrying jumps out.
Although we don't explicitly forbid it, we don't say anything about working on
packages not on WNPP. In fact, the sentence
If you are interested in maintaining packages, then you should look at our
Work-Needing and Prospective Packages http://www.debian.org/devel/wnpp/ list
to see which packages need maintainers.
makes it very easy to infer that packages not on WNPP don't need [more]
maintainers. And yet, we've been complaining for years that new packagers
always work on pet packages rather than packages which matter. In fact, just a
few hours before your talk, an X.org maintainer led a BoF where he admitted
intentionally trying to get contributors involved in X packaging by leaving
some X driver packages rot for some time. Yet, there is no RFH for X on WNPP!
One may argue the maintainer should have sent an RFH. But really, which package doesn't
need help? Linux does, X does, Iceweasel does, Icedove does, KDE does. It will soon be a
decade since I started using Debian, and I can only remember thinking once that a certain
package was really well maintained (congratulations, Shadow package maintainers!). Oh,
and the ITS now shows 4 of its tickets tagged help. All packages need help.
(I'm not sure I'd say RFH-s are pointless, since some packages do need more help than
others.)
Unfortunately, I don't have a great alternative text to propose. With WNPP, we
have something clear to tell contributors to do. If a package is RFA-d and you
want to
