Should enhancement requests be allowed in bugzilla?

Sean Kelly sean at f4.ca
Fri Jun 9 11:15:45 PDT 2006


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

I disagree.  Projects that I've worked on in the past tend to use the 
bug tracker more as a "to do" list than specifically for bug reporting. 
  Enhancements and such go in as well, and it provides a central 
location for tracking all activity related to a project.  However, 
enhancement requests and the like typically undergo some discussion 
before they are filed to keep the level of spurious entries relatively 
low.  I do get enhancement requests masquerading as bug reports 
occasionally, and my initial response is always to request a formal 
proposal and offline discussion before going any further.

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

This I very much agree with.  However, the alternative forum we have 
available (d.D) tends to obscure proposals among the chaff, and they are 
often ignored.  I do believe that an initial proposal to bugzilla simply 
to open the discussion, followed by offline conversation may be somewhat 
more rewarding.  The log could later be attached to the entry for 
documentation.  Alternately, perhaps a forums could be created for 
directed language discussion?  The scope of the general forum simply 
seems a bit too broad for this sort of thing.

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

As you're currently the man with the plan, the decision is ultimately 
yours so I don't think the appearance of consensus matters much.  That 
aside, I'm sure a voting system could be integrated if a more formal 
means of drawing consensus could be reached.  Perhaps it would be most 
useful to have an enhancements newsgroup attached to a separate project 
in bugzilla?  This would allow discussion to be integrated with bugzilla 
(useful if enhancements are actually implemented) without diluting the 
content on the bugs group.

A valid historical use case would be the AA changes much discussed on 
the general forum.  When all was said and done, changes were made and 
those who pushed so hard for this stated that the changes weren't those 
they expected.  Ultimately, it became difficult to determine exactly 
what people wanted, what was implemented, and what the rationale was 
behind the decisions.  If this were all archived and structured more 
formally I would like to believe that misunderstandings may have been 
avoided and perhaps a more productive consensus could have been reached 
more quickly.  Or at least there would exist a better paper trail to 
explain the resulting changes.

Perhaps any user-driven feature change should be accompanied by a formal 
proposal delineating what the behavior should be.  It could undergo 
discussion and editing on the forum and then a vote could be taken. 
Then assuming the feature is implemented, the documentation would 
already have been written for the most part, and could be integrated 
into the spec almost directly.  The proposal itself, with edits, would 
be the bugzilla entry, and all discussion could be attached rather than 
included inline in the bug report.

> 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 think Wikis are a useful tool, but I'm not sure that they're ideal for 
enhancement requests as they don't offer an easy means to track changes 
over time.  For example, it's quite possible for one individual to 
change a wiki page completely, regardless of the feelings of the 
community at large.  This is actually a problem with some popular wiki 
pages as people have propaganda wars over topics.  I've heard stories of 
extensive wiki entries spanning multiple pages erased by others out of 
spite, and subtle changes being made that aren't immediately noticed. 
None of this is an issue here quite yet, but it's possible that as D 
grows in popularity it will attract some who aren't interested in 
productive discussion so much as silencing others or pushing their own 
agendas.  And I'm not sure it's terribly easy to moderate Wiki content 
(not to mention the fact that people would have to sign on for the 
task).  Perhaps a more Wiki-oriented person could comment?

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

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?  It would be easy enough to say 
"the DMD project has only 5 bugs, why are you blathering on about the 
enhancements project?"


Sean



More information about the Digitalmars-d-bugs mailing list