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 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:
- 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.
- 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...
- 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.
- 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.
- We have no "forums" nor any system designed specifically for
support.
- Support mailing lists have been going down for a long time
while support has mostly moved to unofficial channels.
- 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?
- 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
|
