Re: help

[Justin Pryzby <justinpryzby@users.sourceforge.net>]

On Thu, Mar 23, 2006 at 09:44:08PM -0600, John Morgan wrote:

>  I am interested in volunteering some time to help out with debian. I
> don't have much expirence so to speak in programming or anything but I
> am a quick learner and have some time to give. I was a system
> administrator on a linux network a few years ago. I have a working
> knowledge of c++ and some expirence with perl a few years ago. I have
> just returned from Iraq and am injured with time to spare and I have
> always prefered debian over any other distro. I'm even willing to help
> with man pages or something. Just let me know if you have any use for
> me.
Debian periodically gets requests from people looking for "stuff to
do" where they can be useful, and the typical response is that there's
never any lack of stuff to be done, but its often difficult to come up
with specific suggetions which are still sufficiently useful to bother
suggesting :)

After all, if there were a procedural recipe for doing the stuff, it
would already have been done.

So, the most that I can contribute are some suggestions on how to help
you immerse yourself, with hopes that you'll find some projects that
interest you.

  Subscribe to packages
    http://packages.qa.debian.org/
    Find a package where the maintainer hasn't been active recently,
    or where there's just too much bug traffic for them to deal with;
    this is how I found myself subscribed to firefox, bash, and ssh.

  Subscribe to bugs
    echo |mail NNNNNN-subscribe@bugs.debian.org
    I'm subscribed to all the bugs I interact with, using procmail:
    http://bugs.debian.org/cgi-bin/bugreport.cgi/.procmailrc?bug=37078;msg=58;att=1

  Bug triage
    Good candidates for bug maintenance are packages against which you
    have submitted multiple bugs.  Other people have probably done the
    same, and the maintainer probably gets multiple bugs submitted per
    day, which is difficult to keep following up on all of them.
    .
    It is often useful for maintainers to know about relevant bugs in
    other packages, or for bugs to get manipulated for
    classification/organization, etc.  If you want a challege, go
    tackle the x11 bugs; many of these probably just need someone to
    try to reproduce the problem, update the "found" version if they
    are successful, and email the submitter with "Can you still
    reproduce this?" +moreinfo tags if not.  But many of them require
    spending ~10 minutes each reading the bug log, and actively trying
    to reproduce the problem.
    http://bugs.debian.org/

  Read lists
    There are tons to choose from; choose wisely; you wont be able to
    read them all.  If you like your bugs, there is -bugs-rc or even
    -bugs-all (!) if you're planning on devoting 48 hours per day :)
    http://lists.debian.org/

  Read changelogs;
    apt-listchanges exists for this purpose; "testing" is very usuable
    most of the time (except in the middle of library transitions),
    and dist-upgrading daily to current testing can help catch
    problems.  For example, conffile prompts in sid do happen, as
    everywhere, and are bugs, but are apparently not often reported.
    OTOH it is argued that conffile prompts from stable=>stable are
    RC, and a stable=>testing or testing=>testing upgrade which
    triggers them are certainly worth reporting (this is not to imply
    that such a prompt in sid isn't worth reporting, or isn't RC,
    since it would make sense to prevent it from reaching testing).

  Review peoples packaging; or even upstream sources.  Report bugs,
  (/me hides), make suggestions for enhancements.  Supply patches.
  Packaging bugs should always get fixed, no matter how small;
  upstream fixes are outide the realm of what some maintainers are
  willing to include.  You'll want to read the policy document, so you
  know what things are supposed to be guaranteed, so you know when
  things are broken :)
    http://debian.org/devel/

  Other useful references are:
    http://packages.qa.debian.org/
    http://buildd.debian.org/
    http://qa.debian.org/developer.php

You can write manpages, there is a list of binaries missing manpages
at http://qa.debian.org/, and probably other bugs for the same thing,
and you can do a search of the Contents file to find even more.  But
the good manpages are probably going to be written not by random
people who don't actively care about the package, and just want to do
something useful, but by people who actually use the package.  Case in
point, I wrote the glade-2 manpage when I was about to submit a
please-provide-a-commandline-interface-to-noninteractively-write-the-
output-files bug, and decided to look at the source code to see if it
would be difficult to implement, then realized that it *was*
implemented, but not documented.  So I wrote a manpage, which was
about 50% of what a good manpage would have been, got it included, and
then someone else patched it, so now its 60% .. huzzah.

There's actually a TODO list at http://www.us.debian.org/devel/todo/,
which has a couple of interesting projects, some documentation ones,
and some programming ones.

This is a meritocracy; (another reason why your inquiry is difficult
to answer).  You get to work on stuff that interests or annoys you,
the premise being that this encourages good work by people who care,
and that if you have working code implementing a good idea, then
nobody [interesting] will stand in your way.

"Happy hacking"
Justin