I was going to post this over on the fogbugz support forum, but halfway through I realized it might not be a great feature request and could probably use some debate, so I thought I would post it up here instead.... cause this is where I post my crazy half thought out ideas. Feel free to skip if you're not interested in software development or bug tracking systems.
Here is something I've noticed about software development in general that I would like to address. Hopefully Fogbugz can help.
First some background:
Typically when new bugs are entered into a bug tracking system, a priority is assigned. The priority is typically based on the "severity" of the bug, for example, a bug that causes data loss would be categorized as a 1. A bug that stops the user from accessing a part of the application but has a simple work around might be a 2. etc... etc...
Typically the prioritization of a bug takes into account the characteristics of the bug itself. What has happened in our fogbugz system is that all the open bugz are in one list, "undecided". Some of these are of high priority, we fix all of those issues before each release. There are many other bugs below the top that we don't always have time to fix. Prioritizing within those cases can be difficult. If we increase the granularity of the severities, then it becomes more difficult to enter bugs, if we use a more course listing of severities, then we loss some of the subtelies of prioritization.
Now onto the meat:
Most development shops would say that the source of a bug report matters. A bug coming from your biggest customer usually carries more weight than the bug entered by a small shop.
Here's what's interesting, in most organizations, bugs entered by internal QA get more attention than bugs entered by your customers. This makes sense during the early stages of development, when a customer hasn't seen the new features (fix bugs as close to their introduction as possible) but makes less sense as the product matures. During the beta period, bugs encountered by the customers should typically be given higher priority than the ones entered internally, as they are more likely to reflect issues that the customer base at large will experience.
The feature request basically boils down to an ability to keep track of the source of a fogbugz case. Before migrating to fogbugz we used a home grown bug tracking system that allowed us to associate a particular customer with a case. This way, when the bug was resovled, the original customer could be notified. This might require too much of fogbugz (it would need to interface with, or support buiding a customer list) but I'll admit that is probably the one feature I miss most since upgrading to fogbugz.