Yesterday, I got the following email (quoted with permission):

Hi Gerv,

I have been reading Gerv.net. Actually I read more than I should have (I am a
bit squeamish). Anyway, I am writting to see if it would be possible to
purchase a link on your links page for $200 US which would be as follows:

PR-Tracker: Bug tracking software for Windows and the Web

The word PR-Tracker would link to www.prtracker.com.

We would require the link to be there for a year. If you decide to put the link
on just do it and let us know. We will send you a check right away.

Randy Stimpson

Wow… easy money ;-) Of course, I declined (amicably), having never used the product, and not being a money-motivated person. “No servant can serve two masters. Either he will hate the one and love the other, or he will be devoted to the one and despise the other. You cannot serve both God and Money.” – Luke 16:13.

However, in the follow-up discussion, Randy pointed me at http://Bug-Tracking-Guidelines.com, which are some general rules he has written for a good bug-tracking experience.
Most of them I knew and agreed with, but a couple are new insights to me. Specifically, number 5 (Don’t triage bug reports in meetings) and number 8 (Record how bugs are detected). I’m sure quite a few closed-source companies should take note of number 5.

Bugzilla doesn’t currently really offer a field to record how bugs are detected. This may be because that, in free software projects (where its roots are), the divisions between the different possible sources are more blurred, with “Customer Report” being the largest category. And free software projects don’t have many “testing dollars” to spend ;-)

I don’t actually agree with number 6 – there’s no need to track feature requests separately (as in, not in the bug system) because any statistics gathering you do should be intelligent enough to disregard them. Tracking them in the bug system is wise, because it leverages all of the facilities it offers for triage, assignment, etc.