Should enhancement requests be allowed in bugzilla?

[Brad Roberts]

On Fri, 9 Jun 2006, Walter Bright wrote:

> Sean Kelly wrote:
> > This is very true, and it is why I originally figured you were against the
> > idea.  But if enhancements were given their own project and forum, perhaps
> > this confusion could be avoided?
> 
> You have a number of good points. I think the best way to resolve this is to
> set up a separate "featurezilla" with a different url.

Well, Sean took a lot of the wind out of my sails by making my arguments 
for me.  I'm probably going to restate a lot of what he said, some of it 
is worth saying twice. :)

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

What is the value in separating one type of issue from the others?  I 
haven't seen a project yet that does that (be it commercial or open 
source).  Issues form a spectrum be they implementation bugs, design 
defects, unclear docs, unclear specs, missing features, desired features, 
etc.  There's not a clear dividing line.  What to one person is a missing 
feature, another considers a bug.  Why even have the debate when there's 
one place to file the issue?  With bugzilla and its ilk it's very easy to 
change priority, etc to clarify.  If a bug is filed in the 'wrong' system, 
you've got to go through considerably more effort to move the bug.  Then 
what if, after discussion, your mind is changed back?  A lot of hassle, 
imho.

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

I agree that the bugzilla issue/comment list isn't ideal, but neither is 
the news group.  Nothing is, so let's look at where strengths lie:

Newsgroups:
  -- more flexible posting/reading mechanisms

Bugzilla
  -- issue state tracking, nothing gets lost
  -- (re-)prioritization or (re-)categorization, no problem with 
     'misfiled' issues.

I'm sure more can be come up with on both sides, but it's not really the 
focus of this topic, so I'll leave it alone unless someone feels the need 
to continue to debate this point.

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

I have to disagree here too based on the track record of the last several 
months of newsgroup (sorry, I lack the history of others here).  People 
post to the ng a proposal and firmly expect it to be accepted and 
implemented.  You can see evidence of this both in the ng and in some of 
the wiki's where people have tried to keep wishlists.

No issue tracked anywhere has any implied concensus to me, be it wiki, the 
newsgroup, or bugzilla.

I think, personally, one of the bigger issues with concensus is the lack 
of clear followup about what is being implemented from a discussion until 
after a new release appears with it.

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

I agree that the wiki(s) around have been filling this role.  Until 
recently they've been the only option so people have used what's 
available.  However, that doesn't mean they're _good_ at the role.  
They're good at many editor style collaberative documentation and 
referencing other bits of documentation.  They're not good at tracking 
state, categorization, prioritization, or capturing a thread of comments.

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

Are you seeing someone who's using bugzilla or the newsgroups in this way 
already?  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.


So, to bring this to some sort of conclusion.. the last point of 
contention indicated by your response above is where the bugs should be 
housed.  I'm willing to add products and components to help segregate 
feature requests if the 'enhancement' priority is insufficient 
segregation, but I am not eager to get rid of the entire concept from the 
system as I strongly believe it's the wrong thing to do.


Later,
Brad