I've been on both sides of this issue.
As a user, I am often frustrated by the terse, non-informative error messages I get when something goes worng. "Cannot open file" is typical. Which file? In which directory? Why couldn't it be opened? What is the file for? What is supposed to be in it? What part of the program was trying to open the file?
The available on-line help is mostly not helpful in these cases, and FAQ's written by the developers, not the users are useless. Even finding out where the log is kept, much less actually seeing useful information in it? Good luck with that.
How can I as a user file an informative bug report with such scarce information?
So first suggestion: build into your programs meaningful error messages, along with enough information to accurately diagnose the problem. Include options to turn on debug output. When an error is detected, log complete information about it into the log file (the location and format of which should be documented). That way the user has a chance of making a good bug report. And be sure to ask for that information when the bug is filed, with specific directions about how to find and include it. "Append log file" isn't enough, you have to tell them where and how to find the log file.
As a developer, I know the frustration of vague bug reports, that leave out vital information. Simple things like which version of the program was being used, or the configuration settings. You have to make it clear to the reporter that you cannot solve the problem if you don't have enough information. One company I worked for actually had a bug state named "Not Enough Information." The only cure for this is to engage with the end user who reported the bug. And the biggest incentive for that person to engage with you, is the prospect of getting his bug fixed, soon.
So second suggestion: be very reactive to people who report bugs. Get back to them, tell them what's going on, ask questions, and let them test the fix. There is nothing that kills the enthusiasm for bug reporting like going through the process, waiting weeks to get a response, and then be told "Yeah, OK, it'll be fixed in the next version, due out in about 9 months. Thanksbye." And don't underestimate the effect of some user saying to his peers "I reported this bug, and they fixed it for me" to encourage others to report bugs, and make good bug reports.
Of course, there will always be lame bug reports, no matter how you do it. But you can at least encourage good ones, raising the signal to noise ratio.