> unless they can give some demonstration that they're into more than just > making packages. Fixing bugs, for instance.
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? + The bug tracking system is a less clear and more difficult to use than in many other open projects. I, for instance, find it a lot easier to work with KDE's or even OOo's bug trackers than Debian's. Being email based (an thus not quite realtime) plays a big role in this inconvenience of use, IMO. I've been playing around with an idea of making a nice local frontend for BTS by adding a procmail filter that would intercept incoming mail. But: I'm not sure which one would be wiser, making such layers on top of current system or taking bugzilla or something and customizing it for Debian. + 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.. - Jarno
