On Sat, Apr 12, 2003 at 11:36:15AM +0300, Jarno Elonen wrote: > This advice is quite usual on this list. I think there are a few reasons why > it's not as common thing for non-DDs to do as it maybe could be: > > + There are so many packages and so many bugs that it's really hard to > say where to start. > > There should be some way to priorize the packages as well as bugs: > it's clear that fixing grave bugs is more valuable than whishlist > items but should I pick "axyftp-doc" or "mhc-utils"? It's clear that > most bugs will be fixed by package's maintainer but if the goal is a > solid release, wouldn't it be a good idea to direct "extra pairs of > hands" to the most important tasks?
You've got the release-critical bug list, which is a good place to start. Or, pick something you're interested in and hack on it: I did lots of work on lintian before I became a developer, and the maintainer at the time was very grateful for it (http://lists.debian.org/debian-newmaint-discuss-0102/msg00019.html). > + The bug tracking system is a less clear and more difficult to use > than in many other open projects. You mean that you find it less clear and more difficult to use. I find it much clearer and easier to use than most. > + You often get cranky response for suggesting fixes. > > The classics are "RTF-doc-behind-the-door-with-beware-of-the-leopard-sign", > "do you really think we haven't considered this already?" and the synthesis > of those two, the "this was already discussed a month an a half ago in > #importantstuffnotforusers-italian". No good suggestions here - I'm afraid > it's human nature to be annoyed by ignorance. :-/ > However: an NM is a *New* M - please remember to cut us some slack.. Oh, sure thing. On the flip side, though, NMs do need to make an effort to show interest in the project as a whole, I think: remember that the developers who are prominent and doing a lot of work now were also typically doing a lot of similar work before they became developers. IMO, and from experience, it's better to hang around the fringes of the project for a while looking for somewhere where you can really make a difference rather than jumping straight in the first time you find something packageable. I think the right answer nowadays is to help other developers with their work for a while and then ask them if they're willing to advocate. If somebody had been sending me lots of more-or-less-working patches for things I hadn't had time to fix and then sent me a quiet mail asking me if I'd advocate their NM application, I'd almost certainly say yes. I'm much less likely to say yes when people pop up out of the blue. -- Colin Watson [EMAIL PROTECTED]