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

Re: Paths into Debian

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:

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


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.


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? ;-)


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

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

Reply to: