Hi,

some of you might already know our bug tracking system at http://bugzilla.gnome.org/browse.cgi?product=GIMP - maybe because you have filed a bug yourself, did search for one or were pointed to a report in a reply to a list post.

But besides being a useful tracker for bugs and features for the GIMP developers, Bugzilla is also a nice way to start contributing to GIMP - without any coding experience. As you might still have a few questions about this, I'm going to answer at least some of them:

What is NEEDINFO?

Bugs are categorized by a couple of their attributes - one of them is their status, which can be set to "NEEDINFO". This indicates that a report has been looked at by at least one developer - but it is either missing some information to understand it at all, or it needs some more input from the reporter, or is awaiting feedback because a solution has been suggested. Unless this is provided, the report won't get much attention.

What's the problem with this bug category?

It has some rather long-lived bugs in it - mostly because the original reporter seems to have abandoned the report and doesn't care about it anymore. Usually, the problems described in such bugs are either isolated to a few systems or somewhat obscure, otherwise they wouldn't be NEEDINFO for such a long time. So far, the final resolution for most of them is INCOMPLETE.

How can I help?

Have a look at the following bug list and check if there are some that you recognize:
http://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=NEEDINFO

The good thing is that most of them contain a comment describing what is missing or what's needed.

Should I add a comment?

This depends on the comment you're planning to write. Keep in mind that the bug has been looked at by people who know GIMP fairly well, and they couldn't figure out what it was about or need more information. Just adding "Me too!" isn't going to help - be at least prepared to answer (or at least to try it) any question that might follow such comments. Try to provide the missing information, or something else that might give us a clue how to handle the report. For example, exact steps how to reproduce a bug are really useful. Or do some research about a possible crash - e.g. if files are involved, try to recreate this on your system using the original description, etc...

What will I gain from this?

Fewer bugs in future releases of your favorite image manipulation program :) More features, too, because less (maybe non-existent) bugs means more time for adding new stuff, as no one has to bother with weird reports. Reputation. Rather important if you plan to extend your contribution to coding. This can now be measured in numbers, even - ever noticed the user's "points" in Bugzilla comments? They indicate a user's participation using a logarithmic scale by weighting the number of opened bugs, closed bugs and comments.

And, last but not least, you will make the author of this mail happy.

Regards, Michael