Should enhancement requests be allowed in bugzilla?

[Sean Kelly]

Walter Bright wrote:
> Brad Roberts wrote:
> 
>> 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.

Very true.  In fact, rewards are sometimes even given to those who close 
the greatest number of "bug" entries per release.  Oddly, this seems to 
encourage developers to produce a shoddy product so they have a 
never-ending stream of bugs assigned to them.  It also makes no 
differentiation between implementing new features (difficult and 
productive work) vs. trivial bug fixes (easy and non-productive work), 
but I suppose that's what you get when non-technical people are the ones 
structuring the work environment.

>> 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.)

One aspect of bug tracking I like is marking whether a bug is 
theoretical or is the result of an actual use case.  The latter sort of 
bugs tend to be the most important, while the former are the sort that 
often crop up while working on other bugs.

>> 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.

People tend to see what they want to see.  If they're excited about D 
they'll see the bug list as a productive thing.  If they're critical, 
they'll see it as a laundry list of why the language will never succeed. 
  That said, I do think a reasonable compromise would be what you stated 
earlier--to track enhancements in a separate project.  It makes for 
somewhat more difficult change tracking and such, but perhaps it's worth 
it if it offers less ammunition to the uninformed.


Sean