If you are involved in the development or in the packaging of a program, sooner or later you'll get bug reports. Every bug report is unique, but most of them fall into one category. Based on my Debian or upstream experience, here are the most common families of bug submitters I had to deal with.

And remember, we are all bug submitters ... think of the kittens !

The enthusiast

He just discovered your application and he loooves it. Great, but there is always something that can be improved. Or bugs. Willing to help you, the enthusiast will report any bug he finds. Any. That is, even little minor aesthetic glitches, like a missing dot at the end of the title bar or a better way to do $foo. This will end up in 10 bugs a day for a week. After that, the enthusiast will probably switch to another cool application. The enthusiast would definitively be of inestimable help ... if only he knew how to fix the bugs he has submitted!

The anonymous clueless submitter

He knows that bug reports are invaluable for the developers, but he has definitively no clue on what to do and more important, which part of your application failed. Usually, he will contact developers by private mail and ask for clues on how to submit a bug. Often, their contribution is useful, but developers will take time to explain how to proceed to submit a report. Against the anonymous clueless submitter, one solution, Read The Fine FAQ !

The rigorous

For a minor bug, he will spend two hours writing a perfect bug report, well written, passed through a spell corrector, with a complete system call trace up to the kernel and with a all versions for all components of his system, from kernel version to the mouse's brand. Rigorous are good bug submitters, even if developers have to sort useful and useless informations. Motivated, they can even become good patch or bug managers.

The clever submitter

Related to the former. He is more clever than you and found the solution for his problem before you. He attaches no log to his bug report, but instead pages of analysis about where the problem comes from. Unfortunately, he is wrong and what failed in your program is not what he thought. Be sure to recognize clever submitters or you'll have hard time trying to guess what is true or what is wrong. Don't even TRUST them, ask them for logs, traces, etc. or you will spend days trying to reproduce an unreproducible bug.

The battler

The battler has just found a bug in your application. He is angry and he lets other people know it! You will probably receive hate mails from such submitters or even worse, very aggressive bug reports that insist upon an immediate solution ... but that lacks half of the useful informations you need to fix the bug! Needless to say, the battler doesn't understand why the developer has tagged his mail as spam.

The badger

This one won't let you breath until you fix his bug, even if there is NO bug. Usually, the badger submit bugs about aesthetic issues (that he is the only one to care about) or about missing features that might lack to one out of a million users. He doesn't care about workarounds because he finds them anaesthetic and he doesn't understand why you wouldn't spend days on implementing his meta solution that has drawbacks too. The badger often threaten to fork but never does.

The Taiwanese

A variation of the former. If your application contains a country list, there is great chance that you'll regularly get bug reports from some residents of Taiwan asking you to remove any occurrence of province of China in your application. No matter you explain them that you are following the http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html - ISO 3166 country list and that there is no political message in your application, they will find it more convenient to bug you than the ISO consortium. Hopefully, not all Taiwanese are that stubborn.

The patcher

Very scarce. The patcher is the perfect bug submitter that thinks of the kitten. He found a bug and before submitting, he tried to understand it and eventually sent you a corrective patch. Great! There are great chances that the patcher will end up in joining the development team ... just bug him until he does! ;-)