NM's to fix bugs? (Was: Asking for an advocate (gURLChecker))
> 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
Reply to: