The good people of plone.org uses an instance of CMFCollector for keeping taps of all their bugs. The interesting thing is that they call it "Issue Tracker", unlike the Zope.org site where they call it the "Issue Collector". (didn't used to be called just the "Collector"?)
This I find very interesting because I've often thought about the name of my little precious IssueTrackerProduct and how instances of it should be named and titled. At the time of writing, the current default Id is blank but the default Title is "Issue Tracker"; incidentally the same as the plone.org site.
Both the plone.org Issue Tracker and the Real Issue Tracker could be called "bug trackers" because they are heavily used for software development and most things entered are bug reports. I guess, what justifies not calling it a "bug tracker" is the influence all stuff that isn't bugs.
The name does matter. Very few people bother to set things like this correctly unless it's a big part of their internal business. Here at my company we have about 45 of these issue trackers deployed for all various projects that we're involved in or that our partners use. All of our instances are placed on a dedicated server so it feels more natural to for example call them "CAMHSReportage" rather than "CAMHSReportage Issue Tracker". The thing is, if the issue tracker was an integral part of the CAMHSReportage website, it might just be named "Issue Tracker".
This leads to the question: how do most people install their issue trackers?
What's the preferred naming convention?
Can I learn from this when I set a default Id and Title?
What do the real users (not the sys admins) expect to call it?
UPDATE: changed to say that plone.org use CMFCollector
Comments
plone.org runs the very old CMFCollector and *not*
PloneCollectorNG
Oops. Fixed now.
I use various issue tracking products for software development. I alwaysh call them 'Issue Tracker' as bug tracker is not an accurate name in most cases. Of course most submissions are in fact bugs, but some are also feature requests, or support questions e.g 'how do i do x?' Which generally means the support documentation needs to be updated to cover 'x' (assuming the submitter has read the docs first and it's not covered.'