Should enhancement requests be allowed in bugzilla?

[Bruno Medeiros]

Sean Kelly wrote:
> 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?
> 

I have to say I mostly disagree .

First of all, DMD is different from most other products out there in 
that the bulk of enhancements are for the D language itself, and they 
are much more subjective, non-consensual and thus discussion-prone 
(because they are complicated design decisions). This bulk of 
"enhancements" won't be stuff like "dmd should fold in the functionality 
of rdmd" which is something simple and could fit well in the bugzilla 
enhancements.

Second:
 > "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."

What? What else is the general forum other than for the discussion of 
the D language? It makes no sense to create an enhancements NG.

I do agree that the NG has some disadvantages, as you pointed out, like 
a bit of losing track of proposals, but I doubt using bugzilla would 
help us much there.
I think the best way is a combination of NG discussion + wiki tracking. 
A wiki is susceptible to vandalism, but I'm sure there ways to deal with 
that (not even a problem right now), and other than that, I think it's a 
quite adequate tool.

Issue tracking is what I've been doing, albeit in an initially not very 
sophisticated way, with my wiki entry 
(http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D) .
I also did recently mention interest in improving the current proposal 
tracking situation (in 
news://news.digitalmars.com:119/e3ae4v$2o1t$1@digitaldaemon.com ). 
Reposting the relevant part:

"
Thinking even further, the wiki could be used as a repository for 
summaries of the current "discussion state" of design 
features/peeves/issues. A standardized method and/or page for doing so 
would even be better. For instance a wiki page lists the common existing 
design issues, and for each one of those, another wiki entry exists 
listing a summary/abstract, background(optional), issue description, 
points and threads argued, community feedback (both negative and 
positive). Even if Walter doesn't pay attention to it (which is 
expected) it helps a bit to the community to know what is the current 
status, and the opinion of the rest of the community members.

I know that there very standardized and very formalized processes for 
languages changes in some other languages, and someone with knowledge of 
these (I haven't) could contribute some good well-based ideas. We don't 
need nor should have anything that complicated though, just something 
simple, which is useful enough already.
"

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D