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 adopt, go say so on the ticket, upload a new version when the
maintainer agrees, closing the ticket, and have fun. But we don't have an
equivalent process for someone who would be willing to help packaging the
radeon driver.
Yet, packages not on WNPP are probably better options for starting the
packaging path than packages on WNPP, as those not on WNPP should have a larger
team ready to mentor the prospect (unless a package should be on WNPP but isn't
because the maintainer is just MIA). On the other hand, a healthy package might
be a worse option since it usually has more users, hence errors will have a
greater impact. So basically, starting with a package on WNPP may be harder for
the contributor, but starting with one not on WNPP may be less useful and safe
for users.
What can we do to encourage (or at least not discourage) prospects from helping
with packages that matter? Which other distributions do better?
More paths
The first "map" listed above (/intro/help) has 11 items, most of which could be
considered as paths. I find the first 2 points there very interesting. The first says people can
test and/or report issues. This certainly constitutes a path (quality?). The second says people can
help advise users (IRC, mailing lists). If we talk strictly about Debian development paths, support
for users may not be a path, as this would at best indirectly contribute to Debian's improvement.
However, in the metaphor I described, following a path means to improve yourself as a contributor,
and people following the "support path" can definitely learn a lot about Debian while
helping users.
Then, if we jump a bit further to point 5 and 6, we see there's also a
documentation path, either by writing or translating packaged documentation, or
by contributing to a website such as the wiki or www.debian.org.
I believe the people who are most likely to need driving directions are those with the least
driving experience. Those who know the least on computer science, and particularly on free
software. I also believe the "quality path", the "support path" and the
documentation path are particularly interesting for newcomers, as they offer some safe and
accessible roads. A contributor simply travelling each of these roads could do a pretty nice Debian
trip. Therefore, I believe our sourcing efforts should pay attention to these 3 paths (others are
important too). I'd like to expand on them a bit.
These paths are very interesting because in a sense they have absolutely no
barrier to entry:
1. Quality: A user reporting an issue, perhaps for selfish reasons, will have
to go through a number of tickets to make sure he's not reporting a duplicate.
From there, it's very natural to comment on a ticket the user isn't
experiencing, and then to find himself contributing to the package's tickets.
2. Support: A user asking a question on IRC will see other users asking while
waiting for the answer to his own questions. If the user can answer someone
else's question, it would be a shame not to - if you managed to ask a question
on IRC, answering one shouldn't be difficult. From there, it's very natural to
stay and answer a few more questions...
3. Documentation: A user following a howto on the wiki notices a typo. If the
user is familiar with wikis, fixing it is about 2 clicks and a keystroke away.
In these cases, one can go from user to contributor in one minute (perhaps
ignoring wiki registration here). However, these paths are also imperfect. As
our projects ages, our infrastructure does too.
1. Our 20th-century ITS has no web-based edition capability. Adding information
to a ticket is quite easy, and opening one isn't difficult, but there's a
certain barrier to go beyond.
2. We have no "forums" nor any system designed specifically for support.
1. Support mailing lists have been going down for a long time while support
has mostly moved to unofficial channels.
2. Even IRC isn't in great shape, with our forces still split on 2 networks
years after the move to OFTC (which is poorly managed).
FWIW, I found myself in a discussion on another project's usage of IRC
for user support, already a couple of years ago. Although IRC is certainly not
perfect, I was arguing that nothing could match its efficiency (or IM's
efficiency) from the contributor point of view. Those who brought up the topic
said other media (they were thinking web stuff) could attract more users (which
is supposed to be a good thing ;-) ). If I go really deep in my memories, I
think I may relate to that. It could be that people new to free software will
find IRC intimidating. Idea: add a screenshot of someone asking on #debian to
our support page?
3. Our web documentation is split between www.debian.org and the wiki. 2 technologies,
quite some redundancy. The wiki is newer, but goes back to 2001. In both cases, history
has let us with serious licensing issues, particularly on the wiki. While the wiki is
anarchic, www.debian.org (still using CVS) is on the other extreme of control, with poor
sourcing. Of course, a lot of our documentation is in packages. As explained in the
packaging path, there's the private team operation issue again here. While code is a
"natural" barrier to making small contributions to lots of packages, the
technical barriers to entry to any package's documentation are small, so artificial
restrictions are making it much harder than it should to contribute efficiently to the
documentation of packages. Granted, since most of our packaged documentation comes from
upstreams, major restrictions would be left even if we would do our best to fix this.
In the end, the only place appropriate for a scratching-your-own-itch
documentation path will be the wiki.
Drawing borders harms mobility. People will often avoid a country rather than
going through customs. Privatizing Debian areas has the same effect, not only
on the documentation path of course, but in an awful lot of places. Soft
security can replace borders, but is uncommon in Debian. Proactive recruiting
compensates for borders, but is one of our weak points.
Once a contributor has traveled a number of accessible paths, he'll feel better
about more bumpy roads, and eventually enough to use a road which needs repairs.
Driving visibility
So we have lots of opportunities for improving roads, but they can have large costs. As
mentioned in the talk, "more communication from teams" is certainly one major
source of potential improvements. However, more communication has costs.
But what matters isn't only the volume of communication as the number of signs visible to
drivers. If teams operate as black boxes, the information which is communicated can be
lost. Passive transparency is one very cheap investment achieving "more
communication from teams /reaching contributors/".
Directions
No doubt our maps could use improvement. I found another one in the FAQ:
http://www.debian.org/doc/manuals/debian-faq/ch-contributing.en.html#s-contrib
Also problematic, I filed ticket 721207 on that.
intro/help
As your call for help implies, there's a lot of way to go between /intro/help
and what some other distributions have. Since we're on the topic of task ideas,
and since the need for that work is clear but nobody seems to be available for
it, why not add working on these pages in the website's TODO list? ;-)
Graphics
Just an idea - I think it makes sense to show people on intro/help. Why not
Debian contributors... if we don't see balanced demographics as a requirement,
anyway. And what would be better than a Debconf group photo for that? A
swirl-shaped Debconf group photo? Well, a quick search brought 2 interesting
pictures (thanks Aigars):
http://www.flickr.com/photos/aigarius/542611451/
http://joeyh.name/pics/debconf/6/Espiral-Debconf6_2048x1536.png
I could imagine some better use of Debian colors in the swirl or as background
(who wants to organize a winter DebConf and distribute red coats), but I think
these existing photos or minor adaptations can do very well too.
Personalized advice
Obviously, no matter how much we work on maps, they will still give imperfect
advice. As mentioned in the talk, a prospect-to-existing-contributor relation
can help a lot to get newcomers started. This can happen between students in
the same univerity, or members of a LUG. Obviously, these situations are ideal
as they allow both quality advising and customized teaching (and have potential
for combining Debian work with interesting social interactions). However,
forming and maintaining a user group can be costly. Not every prospect will
have this chance, or the courage to show up at a Debian meet-up when they don't
know anyone.
As an alternative, we could try directing prospects to places where they can
get personalized advice online. I've seen a number of prospects show up on
#debian asking how they can help over the years, and redirected a few to
#debian-devel. We should add something at the end of /intro/help suggesting to
go to #debian-devel or debian-devel@ for personalized advice. It would even be
good at some point to have dedicated channels for that.
Going further
As the examples have shown, there is much difference in the paths of contributors. At least 1 of the 3 started on the quality path. I would be curious to know how many contributors did the same. And how many started on the support or documentation paths. The more we know about the paths of existing contributors, the more wisely we can invest in road improvement, and the easier it will be to improve directions. Surveying them could highlight the most popular starting roads, and show some correlations between various roads. This might also confirm that there are various contributor "profiles", and what they are. Unfortunately, we don't have a database of contributors (but soon will, yes Enrico ;-) ). Nevertheless, we could get a fair picture by surveying drivers on our main roads. If Lucas Nussbaum's survey of new packagers should be repeated, I'd like to see a few more questions, like "What was your first contribution to Debian?". They should probably be well considered so we
can aggregate the results. Maybe determine a set of roads and have one question for each:
How long did you drive on the quality path?
[] Haven't started yet [] Reported a few bugs [] Triaged at times []
Regularly triaged
How long did you drive on the support path?
[] Haven't started yet [] A few minutes [] A few hours [] More than 10
hours
How long did you drive on the translation path?
[] Haven't started yet [] A few minutes [] A few hours [] More than 10
hours
(etcetera, with more care given to phrasing)
While we're at it, have there been surveys of Debian contributors asking about
their careers, their relation to Debian/software, and how much experience (in
software development, free software development and/or peer production
projects) they had when they started contributing to Debian?
--
Filipus Klutiero
http://www.philippecloutier.com
