Guidelines For New Debian Contributors

Disclaimer: This page reflects my ideas (maybe shared by other) but does not represent any format statement from the Debian project.

pacakging or non packaging?

non-packaing

- bug triaging
- i18n (translation)
- wiki maintenance
- doc writing

packaging

- orphaned packages
- help big packages
- join a team and help maintainer their packages
- propose your help in fields you like to work on (science, python, web apps, etc)
- pacakge a RFP
- itp a new pacakge
pet packages, but we are a distrivution, not just a collection of packages: first we have to consolidate the packages we already have in teh archive, becuase we hvae users using them - new packages are a plus.

They could, of course, be invited (if publicized more conspicuously, as
I put in my original message) to join/help an existing team as a first
step to learn the packaging issues.

The current approach has some drawbacks (a obviously non-exhaustive list):

 * More existing packages means more need for QA, but we have
   limited resources available. ("Too many packages, none working
   correctly" or "abandon-ware", as some would say).

 * The existing teams need help from trivial things to complex
   tasks. New contributors should be encouraged first to work with them
   as "apprentices" and to, of course, raise the quality of the
   existing software that we already have.

   In other words, let's get what we already have in a good shape before
   embarking in a new ship.

   We usually don't eat something if that is still not prepared. Why
   should software (or any other thing, for that matter) be different?

 * Working with existing people teams helps:

   + Understand the modus operandi of collaborative software production.

   + Foster the mentoring process that the distribution needs to
     keep a steady flux of good maintainers to assure the long-term
     health of the project per se.

     This is good both for the maintainer (explaining skills involve
     what I will call here a mental organization of the tasks to
     clearly see the distilled, main points of the process) and for the
     apprentice, as practical knowledge is gained.

     "(...) true wealth is measured not by what you accumulate, but by
      what you pass on to others." --- Larry Wall, 1999.

Instead your first step should be running wnpp-alert and helping maintain a
package you already have installed.  If you are lucky enough to have nothing
reported by wnpp-alert or just can't help there, rc-alert is also a good
place to start.  Both of these tools should be better publicized.

New packages are fine, but there seems to be a constant need for more
maintainers of the packages that already exist.

I just think we also have to keep in mind that the proverbial "itch"
that new contributors are trying to "scratch", i.e. why they want to
help in Debian in the first place, is that they are missing a piece
of software they use or would like to use. Therefor an approach as
(silly example) "You can only get a new package sponsored after
fixing 10 existing ones." might demotivate potential new
contributors.

,----
| Attn Debian/Ubuntu/whatever developers and maintainers:
|
| It is with sadness that I see many NEW packages uploaded to the Debian
| repository and little thought about some packages that are already in
| the distribution, but that are bit-rotting.
|
| Please, if an existing package has not been updated for some time, just
| publicize this fact more conspicuously. Let us engage the existing (and
| prospective) maintainers in taking care of aging, but still useful
| packages.
|
| If, OTOH, the packages are not useful, or no one is willing to maintain
| it in Debian, I would propose to remove it as soon as possible from the
| archives, since they present problems (two of the first that come to
| mind are: users installing packages that won't work/might break their
| systems, and the burden of having to worry about security updates).
|
| In a certain sense, more *MAINTAINANCE* of programs should be expected
| from Debian Developers/Maintainers (and not only of packages, but also
| regarding the ports).
|
| Let us take a moment of reflextion regarding the archive as a whole and
| not just fire up/accept new ITP's and RFS's without taking into
| consideration the current state (and the Release Critical bug counts) of
| the existent packages.
|
| This is not meant to say that new packages should be unnacepted: just
| that a second (and third, fourth, etc) thought should be given if you
| can help improve the Distribution, so that we don't end up with a lot of
| half-working packages where all but a few are actually usable.
`----


Regards, Rogério Brito.

It is never pointed out enough that the core packaging teams are
seriously understaffed. Please, before uploading your pet package to the
archive, consider joining one of the packaging teams looking for more
maintainers: eglibc, Mozilla, KDE, GNOME, Xfce, Utopia, Apache, Kernel…
we all need help from more maintainers, and you don’t necessarily have
to be an experienced developer to help.

--
 .''`.      Josselin Mouette

http://wiki.debian.org/Teams

As said at DebConf: we don't need more crap in the archive, we need
more people to help raise the quality of what we have. Working on the
core teams is a great way to do that.

--
Steve McIntyre,

If anyone is interested, I'd like to offer my perspective here as
someone who was, and still is, really quite enthusiastic about helping
Debian, but hasn't really found a way to do so yet.

Sorry, but it turned into a bit of an essay when I wasn't looking.

Let me just disclaim, too: I'm trying to outline what I see as things
that might discourage a newcomer, something which is by its nature is
going to come off as sounding negative. They haven't put *me* off, so
don't take this as a whinge. I can still make these observations, and
maybe people will find them useful.

(Yes, some of them have been answered on this thread already. Some of
them have answers buried in the wiki. But they're what I saw as the
biggest sticking points.)

--------

1. If you want new contributors to join a team, you should tell them
to join a team when they're most eager. There is an extra level of
indirection underneath the Debian Mentors' list, but it's implicit and
invisible — I'm talking about the fact that the acceptance of a new
package depends on what team your new package will fall under. The
acceptance or ignorance of RFSs might seem very arbitrary to a
newcomer, not at all related to quality of work, and this can be more
discouraging than people might think. It's human nature to be put off
when someone doesn't tell you all the rules, and people do just give
up.

This could be fixed without any infrastructure changes whatsoever,
just by making this layer more visible. In other words, if someone
posts a good looking RFS, and it falls within the domain of an
understaffed team, reply with a stock-standard email along the lines
of: "Hi, thanks for your RFS, it looks like your contribution would be
within the area of the [whatever] team. We'd really rather have more
help with many packages already in the archives, please consider
joining the team and helping out."

Also: make it the *first sentence* in every document pitched at
newcomers, rather than the harsh response given when they ask why
their RFS was ignored after several weeks ;)

2. You have the NM guide saying that new users should post an RFS on
the list and wait patiently, but then you have DDs saying "I never
take an RFS off the list, I always go via IRC." You have the
mentors.d.n which seems quite useful, but some DDs say no-one really
uses it, so why have it? Except that other DDs say they only sponsor
packages uploaded to mentors.d.n. This conflates #1. Your potential
new helpers just get ignored instead of directed into more useful
avenues.

3. So say I still want to help out. I love the neurotic pedantry of
packaging, so I found a smallish package that is a release or two
behind upstream. This takes more than a patch to fix, so I get in
touch with the maintainer (there are no signs it is O or UFA). No
response. I go to the trouble of packaging the new upstream while I
wait, which incidentally fixes some bugs. I put the results up
somewhere and contact the maintainer again. No response. Is he on
holiday? Would an email to the Debian GNOME team be overzealous or
inflammatory? Do I wait two or three weeks? There's an MIA
procedure... somewhere... but is that for this kind of thing? Yet?

I bring this up because it's a bit of a circle: you want people to
help out with existing packages, but just like making a new package,
they're liable to be ignored under certain all-too-common
circumstances; in fact, under the very circumstances you're talking
about being a problem. It's a paradox. Chaos wins again.

4. What exactly, do you mean by "join a team"?

--------

Anyway, just my $20.50.

Regards,
Jason Heeris