Should enhancement requests be allowed in bugzilla?

[Walter Bright]

Brad Roberts wrote:
> On Fri, 9 Jun 2006, Walter Bright wrote:
>> 5) Appearance
>>
>> Despite the ability to filter out enhancement requests, I have a lot of 
>> experience with people ignoring such and stating that "product X has NNN 
>> bugs outstanding." They'll do this because they're too lazy to dig 
>> deeper, or because it makes a great sound bite on their magazine 
>> article, or because they have an agenda against X. Even if they do 
>> filter out the enhancement requests, the existence of thousands of them 
>> (people post enhancement requests every day to the newsgroups, over time 
>> this does add up to thousands) will lend the impression that D is a 
>> language severely lacking in utility.
> 
> I've never understood how/why 'people' misuse these sorts of stats.

I've seen it enough times to understand the motivations:

1) management made an issue out of the "bug count", so the bug count is 
what gets worked. I've seen places with the "bug count" graphed over 
time prominently displayed on the wall.
2) it's an easy copout way to justify not using a product
3) it's easy to copy/paste the "bug list" into your "review" of the product
4) it's an easy way to discredit a product

I've seen all of these at play in real corporations, mainstream 
programming print magazines, etc.

Since these are all superficial, the people doing such have no interest 
in investigating how to sort out "enhancement" qualifications, presuming 
they even notice the existence of that category. After all, the title of 
the database is BUGzilla, not ACTIONITEMzilla or TODOzilla.


> I've 
> seen one particularly insane person who did do this with respect to 
> mozilla's bugzilla instance, and was well acknowledged by pretty much 
> everyone as a raving lunatic.  Using bug counts as a measure of viability 
> is absurd.  It's a sign of activity, project robustness.  A system with 
> few bug entries is a system that's not being actively used by anyone and 
> has little indicator of the stablity/state of it.

I agree with you it's absurd. But the reality is that people can and do 
use bug counts as a measure of quality or progress towards quality.

> Are you seeing someone who's using bugzilla or the newsgroups in this way 
> already?

I've seen it happen on every single project I've worked on for other 
people. And yes, it is happening with D - people get uncomfortable when 
the bug count rises, or when Dstress shows a lower percentage passing, 
even though that often happens when the quality of the compiler rises.

(For example, it's possible that fixing "templates don't work" may 
result in a dozen new "templates in this odd case don't work". So the 
bug count increased, but the quality had improved.)

> If the project and community can't counter these arguments, 
> placement of the info isn't going to stop them, they'll just change the 
> way they attempt to detract from D.

People are always going to take shortcuts to understanding something. 
When something labeled as a BUG database is filled with enhancement 
suggestions, they will be perceived as bugs - not by you or me, but by 
people taking a quick first look at D. Trying to counter that first 
impression will consume a lot of our energy we can ill afford to expend. 
It's a lot easier to give a correct first impression than to try to 
counter a false one. Listing enhancement requests in a bug database 
gives a bad first impression.