Most free and open source projects these days have plenty of documentation for producing a good bug report. This is really helpful, and we should continue improving our reporting tools and documentation. There's a special warm feeling following the submission of a bug report with exact version numbers (of course the most recent stable), idiot-proof steps to reproduce, anything relevant from /etc, /proc and env and maybe even a core dump. Many projects will answer these quickly and either repair the defect or explain where you went wrong in assuming how the program should work. FOSS at its finest, and respect all round.

There is a different sort of warm feeling when you slowly realize that the hours you spent figuring out how to reproduce, collecting all the relevant data, and writing the bug report were wasted. Because nobody is ever going to fix it except by accident, and you are left with the choice between a) spending days, weeks or months accumulating enough context to fix it yourself, b) spending days, weeks or months replacing it with something different which has other, unknown, trade-offs or c) give up and do something else.

It's important that we as a community come up with ways around this. Respect needs to go both ways - if you expect your users to follow procedure, don't waste their time when they do. If bug reports are left unanswered, please let users know why before they waste time.

Nobody is interested in the printing subsystem? Ask for someone to take over, and let people know when reporting that such and such issues are unlikely to be solved any time soon. You've moved on and don't actually want to work on the project anymore? Mark it as abandoned. You're overworked? Recruit some help. Or if none of these sound attractive, you could charge for support or simply close the reporting system. Really. A strong community will find a way, but having a communications black hole is a recipe for a lot of bad blood and unnecessary negativity to enter into it.

Other than this, what can we do? Some automation might help. Bug reporting tools can easily produce statistics about the mean time before getting an answer, for example. Some tools encourage feedback about whether the answer was useful. How about displaying a summary of the responses? In what other ways could we save everybody time when handling bug reports?