Should enhancement requests be allowed in bugzilla?

[Brad Roberts]

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.

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

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

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.


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

> 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