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