Is it hard for new contributors to help Debian? Can we improve things a bit?

Debian could use more manpower, but is it actually easy for new contributors who would like to help to do useful things, and get the impression that they actually improved Debian?

There are several problems here:

  • Find bugs that are not too hard to fix. I don’t know about your packages, but in mine, there are some bugs that are easy to fix, and it’s just a matter of finding the time. If someone provided a patch, I would be very happy and apply it or provide feedback as fast as possible.
  • Find packages with active maintainers. It is no secret that if you choose the wrong package, your patch could very well sleep on the BTS for years.
  • Find bugs that actually matter. It’s not strictly a requirement. But fixing bugs in packages that should probably be removed from Debian instead is not really rewarding.

I think that other projects are better than us at providing directions to newcomers. Gnome has the whole Gnome Love thing, for example.

I’m thinking about building lists of “interesting” bugs. That would include RC bugs without patches, of course, but could also include a list of bugs based on an usertag that would mean “This bug is suitable for new contributors (it’s not too hard, and you could learn things fixing it). If you want to work on this bug, I’ll provide help and feedback and integrate your patch ASAP.

(This is very different from the “help” tag, which usually means “I couldn’t fix this, it’s too hard, I need help.“. It’s a bad idea to direct newcomers to bugs that are too hard for the package’s maintainer!)

Additionally, a nice feature would be to be able to filter the list of bugs with the packages that the user has installed.

  • What do you think?
  • As someone willing to contribute to Debian, do you often find it hard to find stuff you could do?
  • As a maintainer, do you have a lot of bugs that could use such a tag? Would you use it?

Comments are open, please us them ;)

18 thoughts on “Is it hard for new contributors to help Debian? Can we improve things a bit?

  1. After the “here’s a list of starter bugs” page exists for a time, your question will be answered. Let’s answer the question! (I’m guessing you’ll get more contributed bug fixing time out than the time in to put up such a page.)

  2. Sure, but the post is a way to check that I won’t be the only one to tag bugs ;)

    Also, does someone have a cool name for the tag we would use for that?

  3. AFACIT there are some more steps to take for a potential contributor between ‘not contributing’ and ‘actively fixing bugs’: reporting bugs, getting in contact with people (i.e. maintainers, developers), imporoving docs and i18n, etc.

    Effort should be spent to make these steps easier for newbies.

  4. Having something similar to the Gnome Love would definitely be a good thing. I also think we should have a “bts/nmu death squad” that prevents patches from sitting in the BTS forever without being uploaded!

  5. IANADD, but perhaps Debian should offer more prominently the information that is contained in the following links:

    http://people.debian.org/~vorlon/rc-bugsquashing-urls.txt
    http://people.debian.org/~vorlon/rc-bugsquashing.html
    http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&ignpatch=on&new=5

    Also, the idea

    http://master.debian.org/~ajt/oldbugs.html

    seems nice to me. (Of course should one update the list, perhaps every quarter?)

    This information should be on a separate page, which should be linked from 4. of

    http://www.debian.org/intro/help

    The ‘Help Debian’ in the main navigation bar of http://www.debian.org should IMHO be
    moved upwards so that it can be seen without scrolling, e.g. as sublink of ‘About’,
    directly beneath ‘Contact Us’. If this is too illogical, the sublinks of ‘Getting Debian’ (‘CD vendors’…’Pre-installed’) could be moved to that page, so that ‘Help Debian’ would be visible without scrolling.

  6. We have actually talked briefly about this. As one who is not a DD and tries to contribute I think it is a great idea. I only have a couple of questions/concerns.

    Isn’t this something that debian-mentors is kind of doing already? Could it be improved? Or is that strictly packaging related?

    Secondly, and probably most importantly, do you think Debian’s “culture” can handle it? By that, I mean some maintainers are more protective of their packages (and rightly so). Some are not responsive at all (which you alluded to previously). What group is open enough to oversee this? The hardest part of that is if you have an unresponsive maintainer or an orphaned package, who could push the patches through? Is it QA, an NMU, what?

    I ask because of the recent situation with zynaddsubfx. I realize that was my fault for not hitting the maintainer earlier but it shows an example of a good corner case.

    Thanks!

  7. @Barry: debian-mentors is mostly about maintaining packages. I’m not sure that maintaining new packages is the nicest way to start contributing to Debian. Actually, we already have a lot of packages in Debian, and it would make more sense to fix the existing ones, instead of adding new stuff.

    Debian “culture” is indeed a problem. The basic idea is to point new contributors to bugs that will be fixed:
    – RC bugs, because there’s a very lax NMU policy for them
    – bugs for which the maintainer volunteers to spend time reviewing/providing feedback.

    I’m not sure about orphaned packages. It would be great if the QA team would have a policy of using orphaned packages as a playground for new contributors. But it might require more time than the team currently has.

    Note that for all bugs and all packages, you can always follow the normal NMU procedure. But it takes a few weeks to get a package in the archive.

  8. Aye makes sense. This is actually one of my personal issues with Ubuntu (being an MOTU myself). Let’s keep adding more and more packages without regard for the existing stuff.

    That being said, one of the nice things about Ubuntu is the lack of the maintainer concept (Of course it has it’s downfalls as well). But for orphaned packages I can fix and upload without some lengthy not well publicized procedures. The MOTU threshold is pretty low (I know most DDs will say way too low) but it brings in a lot of contributors.

    Anyway, I’ll shut up but I think you are on to something here. :-)

    Thanks.

  9. I already submitted some (a dozen) patches to Debian, for different packages, and it is very disappointing not to get an answer from the submitter, or to see a patch waiting for years in the BTS, in spite of your attempts to contact the maintainer.
    Moreover, there are too many irrelevant or old bug reports, which can discourage the newcomers: many packages seem to be in a state of neglect. I think a huge cleanup of the bug base would be great.
    Nicolas

  10. I think making it easier to contribute to Debian is great, but I’m not sure that it makes sense. I’m not skilled enought at coding to unlesh my meager skills upon the hordes (so to speak) but I’m interested in contributing to Debian. I’m one of the few non-maintainers who’s actually ENJOYED reading the New Maintainers Guide (it generates a healthy respect for the attention given to packages).

    The problem for ME is that I simply can’t offer the level of comittment that I know I’d need to give in order to both help Debian AND keep the level of quality that I expect in Debian.

    Sam Hocevar (sp?) put on his platform the need to have Debian maintained by various teams (i.e. the X Strike Force) which I think is great but I can’t help but think of the adage that the camel is the horse designed by comittee.

  11. I can tell you straight away what I’VE found most difficult in contributing to Debian/Ubuntu, the dpkg-format and build-tool. Actually the difficulty in my still blank staring eyes is that there’s several tools, scripts, helpers here and there, and at least to me it’s not obvious what each of the does.

    For instance, what’s dh-helper and how does it work for me? Exactly how do I apply a new patch, where do I add it, how do I remove an old one, etc? The problem for me so far has been that there is not ONE answer for many of these questions, but several. Different ones for different packaging tools, and for different packages. While the debian makefile-based is extremely versatile and powerful, for me there has been a huge learning threshold, that I still haven’t passed.

    Before being an Ubuntu user, I’ve been hacking around in Gentoo Portage, Arch Linux and various RPM-based distros, currently mostly CentOS. My experience from those packaging systems has, so far, been a lot more straight-forward. Basically, here’s your build-file, it contains meta-data about the various sources, the resulting binary packages, a log, and a couple of quite straight-forward scripts for building. Run it in a prefixed environment, and a regular user-account to avoid accidents, and you’re more or less good to go.

    In Debuntu, well, the experience haven’t been nearly as straight-forward to me.

    I realise this may start the regular RPM/DPKG-format debate all over again, and that’s really not what I want to do. Personally, I think both have some strong merits, and I’m quite pragmatic in my opinion about both of them, but I certainly do consider DPKG the harder one to start building for.

    Personally, I haven’t had a big problem finding bugs in Ubuntu. I haven’t had a problem fixing them, creating a patch or whatever, but when it comes to packaging, I must admit I don’t even try anymore, I usually submit the patch for the source-package, and leave it be. (Sometimes, it can be difficult to create a source-package-patch, since I’ve only been able to apply it live to a system outside DPKG)

    What I would consider necessary is a really good information-base surrounding dpkg. I would need a bunch of _REALLY_ easy tutorials and explanations that explains the basics (from a users point of view, not the architectural basics) of DPKG and all the build tools. I know there’s been MOTU training sessions live on IRC, and I think that’s a great way to build community and such, but for me as a full-time employee, in my precious little free time, I would much rather walk through a short web-tutorial, in my own time, when I have the time, and take a break when my girlfriend yells it’s my time to cook again.

    I think a Wiki would be a good idea for such information base. Perhaps there already is one, but if so either google didn’t find it for me, or it didn’t help me much the last time I pulled my hair.

  12. I would use such a tag. I often see (or file) bugs that would not require a large amount of work to write a patch for, and would not require any more knowledge of the package than someone could easily gain by poking at it a bit. Sometimes I write a patch for these, but sometimes I just file the bug and plan to write a patch later if nobody else does.

  13. As a Debian user I say that’s a great idea. I specially like the “show bugs in packages I’m using” idea. I’ve never contributed to Debian because I couldn’t easily find a bug I was capable of solving with my limited knowledge.

  14. Pingback: fsdaily.com
  15. Ack on the problem identification and reasoning.

    I disagree on the implicit orthogonality you seem to see between “love” bugs (i.e. those you identify as suitable for newcomers) and “help” bugs. The latter are not necessarily hard (though often they are), they can be easy to fix but requiring knowledge that the maintainer does not have. I used to have a quite easy bug tagged +help in a package of mine because fixing it required knowing JavaScript which back then I did not know at all. For a potential newcomer which knew, maybe even a tiny little bit of JavaScript or even only willing to learn the first bit of JavaScript, that bug could have been easy to fix.

    Along the above lines, I think an easy and proper technical “solution” would be adding a “love” tag to the BTS, which maintainers can add to their bugs. A normal tag is even easier to add and less error-prone that a usertag.

    Once we have that and the tag starts to spread we can easily set-up a love.bugs.debian.org page giving due visibility (and related credits!) to the love bugs.

  16. For some time now i have tried to find ways to help out with Debian. I thought that I would start out with packaging but I found it quite hard to grasp how the dpkg packaging works, and how to use the variety of scripts and helpers.

    I very much welcome the HelpDebian(/Start) pages on the wiki. I would also welcome some sort of classification of bugs that are suited for people without strong experiance but with motivation to help out! (For instance the love.b.d.o seems like a really good idea, or maybe now gifts.b.d.o then.)

    Maybe the “dating domain” is a suiting name for this business of tagging bugs etc? Letting newcomers “hookup” with DD or maintainers, handing “gifts” to eachother.

Comments are closed.