Should enhancement requests be allowed in bugzilla?

[Bruno Medeiros]

Don't worry about being blunt, it doesn't bother me, only lack of logic.

Brad Roberts wrote:
> On Sun, 11 Jun 2006, Bruno Medeiros wrote:
> 
>> 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.
> 
> I generally avoid being this blunt, but you're totally wrong on this 
> point.  Newsgroups and wiki are horrible at tracking open, closed, 
> dropped, duplicate, etc state and are one of the primary reasons that 
> issue tracking systems were invented.  Homework:  Pick a random bug report 
> in the bugs newsgroup.  How do you determine if it's fixed.  Compare this 
> to bugzilla.
> 

I'm not comparing that task/"homework" because that measures bugzilla's 
adequateness at tracking *bugs*, and not language design issues. 
Obviously bugzilla is great at tracking bugs, but language issues (aka 
language change requests) are of a quite different nature, which 
bugzilla is not adequate for.


>> 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) .
> 
> So, you're going to keep track of every open issue on that page?  Good 
> luck.  You're not?  Ok, what about the ones that you don't track?  Someone 
> else might do the same?  Ok, so how do we find out about all these 
> disparate places that are tracking their own favorite issues?  See, this 
> just doesn't work at any sort of scale.  How about when issues are 
> resolved, are you going to update your list?  How about the duplicate 
> problem entries on the other however many people track the same issue?  It 
> makes the problem worse not better.  Sorry.
> 

"So, you're going to keep track of every open issue on that page?"
No, I'm just keeping track of my "favorite" issues (those I thought of 
and discussed).

"Ok, what about the ones that you don't track?  Someone else might do 
the same?  Ok, so how do we find out about all these disparate places 
that are tracking their own favorite issues?"
We list all of them in a common page, on something similar to this 
http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

"See, this just doesn't work at any sort of scale."
Yes it does. Because language issues are much less frequent than 
implementation bugs, likely one *degree of magnitude* less frequent.

"How about when issues are resolved, are you going to update your list? 
  How about the duplicate problem entries on the other however many 
people track the same issue? "
Yes, it's quite manageable to do this manually, once again because they 
are many less. Do you think an issue of the likes of "reflection", 
"array literals" is solved every month? How many changes/enhancements 
did we have in D in the last year? Compare that to the number of bugs 
fixed...

Once again, the nature of language issues is much different than that of 
bugs, and the issue of tracking "open, closed, dropped, duplicate; 
priority" is nowhere near as important as in bugs.

I'll give some examples at the end of the post.

>> 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.
>> "
> 
> I do agree with the use of the ng and various wiki's as forums for 
> discussing enhancements, but not for tracking them.  Those discussions 
> should point to bugzilla and vice versa.  Use whatever medium suits the 
> people in the discussion best, but as a step toward maturing towards 
> production, an entry in bugzilla would make it a whole lot easier to 
> prioritize and later find information about when it comes time to ask why 
> questions.
> 

Prioritizing is not important for language issues, it may not even make 
much sense. And as for finding information, that would be just as easier 
to do in a Wiki or Web page.

> I encourage people interested in this topic to look outside the D project 
> at other projects to see how they deal with these very issues.  
> Specifically I suggest gnome, kde, mozilla, bugzilla itself, trac...
> 
> I'd actually like to see _any_ project that anyone knows about that uses a 
> bug tracking system but doesn't use it to track new features / enhancement 
> requests.
> 

That comparison (with other projects) is biased from the start because 
most other projects have much less design issues than developing a 
language, and much more straightforward feature requests (i.e. features 
that don't require much thinking/discussion about).
Even so, I will give an example in one such "biased project".
Back in the days where I cared about using Linux, I was watchful of the 
Gnome project (around Gnome 1.2 - 1.4, I think). Someone had an idea for 
an "enhancement" which consisted of reversing the order of dialog 
buttons ( "Ok"-"Cancel", "Yes"-"No", etc.) making them like MacOS, and 
the reverse of Windows. Do you think that came up in the bugzilla? No, 
it was much argued and discussed (OT: and I fought against it) in the 
gnome mailing list, but there it stayed. It made no sense to be a 
bugzilla entry for that. (not that there couldn't be, it just wouldn't 
add any usefulness)


>> tracking state:
>> The only state Bugzilla can track is whether the enhancement was 
>> implemented or not. It has no way to track, for each enhancement/issue, 
>> what is the overall opinion of the D users, how extensively was an 
>> issue discussed, the rating of each possible alternatives etc. I don't 
>> think that it is even possible to do this numerically (like voting), 
>> making a text-editing tool like Wiki more adequate.
> 
> Bugzilla can also track duplicate entries, changes over time in priority 
> and category.  I'd argue that neither wiki nor the newsgroups can track 
> the subjective points you suggest they can.  They both can contain the 
> text that humans can use to re-read and come to a personal opinion about 
> those subjective points and even record it as another opinion.  The same 
> recording can be done in bugzilla, though keeping that sort of info in 
> wiki and/or ng's is entirely appropriate.  Let the tools do what they're 
> good at.  Bugzilla is good at making sure issues don't get lost due to 
> lack of current activity.
> 

Back to the same, tracking state and priority is not that really that 
important for design issues.

>> categorization:
>> I disagree, the Wiki is just as good at that as Bugzilla, perhaps even 
>> better.
> 
> Maybe.. this is a rather subjective area.
> 

>> prioritization:
>> Prioritization is not an important feature for a design issue tracking.  
>> In fact prioritization doesn't even make sense if there is no consensus, 
>> which will be the most common case.
> 
> So, there's a pile of issues and no way to tell which are more important 
> and going to be done first, second, ... last?  Work is inherently going to 
> be done in some order.  People working with a project want to know what 
> expectations are reasonable to have.  Prioritization and publishing of 
> that is a rather key aspect of a mature development process.  At some 
> point D will grow up enough to have these needs.  I personally hope that 
> it's there now or will get there very soon.
> 
> ================
> 
> Granted, some of this is less relevant when there's a single developer 
> actually implementing parts, but there _are_ others that are growing in 
> their comfort with the frontends and if D is ever going to grow to the 
> level that other popular languages have, it's going to have to expand that 
> base a bit.  Walter does a stellar job keeping us happy, but look at the 
> list of peeves, wish lists, and bugs and consider where it could be with 2 
> or 3 other people?  David does his best to keep dgcc / gdc in sync with 
> dmd, though it's obvious over the last 6 months that more people would be 
> valuable on that front too.
> 
> As a parting note, let me plant these seeds:  Is D and it's community of
> developers expecting / hoping that the project(s) will grow up to
> something as large as python, ruby, java, c++?  Can it continue to survive
> with the hand tracking, scattered, random systems that are in place today?
> Is it better to establish proven development practices while still
> relatively small or after things break down?  Have they already broken
> down?  Has the lack of solid development practices held D back?
> 
> Later,
> Brad

It's good you mentioned other languages. If my arguments haven't 
convinced you so far, I'll give you now some proper examples (and not 
"biased" projects):

http://dev.perl.org/perl6/rfc/
What do we see here? This is perl's list of language issues (each called 
Request For Change). Does it look like bugzilla or any bug tracking 
system (they use perlbug)? No. It is just a HTML listing of issues, and 
it's a manual system (if you have a RFC, you email it, the webmaster 
posts it).

And also:
http://www.python.org/dev/peps/
This is Python's list of language issues (called Enhancement Proposals). 
Again, it's quite not a bug tracking system, it is just a web page 
listing. (Ok, in Python's case they are also under version control)

Why? Once again, because the nature of bugs and design issues is very 
different from each other. You don't even have priority rating because 
it doesn't makes sense.

My idea is basically to do something similar (but more lightweight) to 
what these language projects do for their change proposals, in the Wiki.
(Anyone interested, check http://www.python.org/dev/peps/pep-0001/ for 
one such process)


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