Here are a few hints if you want your reports to be treated more promptly.
When testing fails, try unstable
If you are running testing, not all bug reports are interesting. More specifically, the relevant ones are about insufficient dependencies that let slip into testing a non-working combination of packages. Think of the “I upgraded foo, then bar broke” category.
Otherwise, the reason why reportbug looks for newer versions of a package in unstable is that, in most cases, the bug is fixed in unstable. If you can, always try the unstable version before reporting the bug.
Report bugs against the failing package
“This is related to printing in a GNOME program, so I report this against libgnomeprint.”
Always file reports against the failing program. If there is a library involved, reportbug will include the necessary information so that the maintainer can easily reassign. If you’re not sure of the affected package, use a metapackage (for example, gnome for GNOME-related packages).
Do not second-guess the origin of the bug
“After upgrading libfoo, bar starts crashing, so I’m reporting it against libfoo.”
Unless you can tell which function is at fault and how this is ABI breakage, you should report the bug against the program that crashes. The program’s maintainer will reassign if needed, and will hit the library’s maintainer with a hammer if needed.
Don’t forget to explain what’s wrong
“The frobniz in libfrob is broken, you should change /usr/share/libfrob/blah line 13 to something else. I don’t know what libfrob is about, but I have some problems that look frobniz-related.”
Do not second-guess, always start explaining what bug you are seeing first. Your attempts at investigating it can be interesting, but don’t forget to explain what bug lead you on investigating.
What is the use case we should cover?
“I’m trying to do that with your package and it looks extremely complicated/doesn’t work as expected/fails miserably. Your package is clearly broken!”
If your attempts to do something that should be trivial, given the purpose of the package, fail, then you are probably looking at the problem at the wrong angle. There may be a much simpler, though radically different, way to do what you are trying to achieve.
In these situations, always include in your report what you are trying to do and why you want to do it.
strace is not a general-purpose debugging tool
Whether you observe a crash, a deadlock or a livelock, strace is not the tool that will give us information. The only thing you do by adding a strace log to the bug report is making it unreadable with its thousands of lines of output.
For the specific cases that require strace for debugging, these traces are welcome but if you’re not sure, don’t attach them. The developers will ask them for you. Otherwise, the general-purpose debugging tool is gdb.
There is a good reason why some packages include bug control files and scripts. Use a reporting tool that takes them into account. Unless you are requesting an enhancement, always use reportbug. Please avoid reportbug-ng since it only provides parts of the required information.