Should enhancement requests be allowed in bugzilla?

[Walter Bright]

> On Fri, 9 Jun 2006, d-bugmail at puremagic.com wrote:
>> > ------- Comment #1 from bugzilla at digitalmars.com  2006-06-09 04:16 -------
>> > The bug list is not a very good discussion forum about the merits or demerits
>> > of proposed enhancements.
>> > 
>> > If Brad (or anyone else) wants to set up a separate bugzilla system for
>> > enhancement requests, that would be fine and likely useful. But this one should
>> > be for bugs only.
>> > 
>> > Bugs are arbitrarily defined as:
>> > 1) doesn't work as documented
>> > 2) contradictory, missing, or obviously wrong documentation
> 
> This is one thing I disagree with.  The priority 'enhancement' makes it 
> very easy to filter search results to hide those.  If even more separation 
> is desired I could setup another component or even another product to 
> house them.  Many many projects use bugzilla rather successfully for 
> tracking enhancement requests and the resulting discussions.
> 
> What's your reason for objecting to enhancements being in this bugzilla 
> instance?  Is it ease of data inspection?  If so, I suspect your issues 
> would be easy to work out with a little help understanding how to use it's 
> search features.  If it's something else, let's discuss how to make it 
> work out best for everyone.

My objections are:

1) Focus

By its very name and nature, bugzilla is focused on bugs. One goes to 
bugzilla expecting to read about bugs. It's a great central clearing 
house for organizing/reporting/anaylzing/fixing bugs. If it starts 
becoming a catch-all forum for discussions about enhancements or other 
issues, it starts losing utility. Once a few enhancements are put in the 
bug list, people will reasonably infer that's the right place to put in 
enhancement requests, and it'll fill up with them.

2) Discussion

Bugzilla is not well suited to discussion and debate on the merits and 
demerits of a proposed feature. It has no threading ability. The emails 
it generates for each addition will become noise, making the email 
feature fairly unusable. The newsgroups are the right tool for 
discussion. (Digital Mars has a signup for a mailing list. The only 
people who ever signed up for it were spammers, which cements my opinion 
that mailing lists are the wrong format for discussion.)

3) Consensus

Feature requests rarely enjoy a consensus on whether or not they should 
be done, so they don't belong in a todo list. Posting an enhancement 
request to bugzilla lends it the appearance of consensus, even though 
only the poster may think it's a good idea. Bugs, however, everyone 
agrees should be fixed or at least tracked.

4) Wikis

The wikis have done a good job of organizing, summarizing and 
prioritizing enhancement requests. It takes extra effort to add 
something to the wiki, which serves to filter out enhancement requests 
that don't have at least some strong positive feeling about them.

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.