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