> On Fri, 9 Jun 2006, d-bugmail@puremagic.com wrote:
>> > ------- Comment #1 from bugzilla@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.

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

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.

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.

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.

Walter Bright wrote:
>> On Fri, 9 Jun 2006, d-bugmail@puremagic.com wrote:
>>> > ------- Comment #1 from bugzilla@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

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

You have a number of good points. I think the best way to resolve this is to set up a separate "featurezilla" with a different url.

On Fri, 9 Jun 2006, Walter Bright wrote:

> Sean Kelly wrote:
> > 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?
> 
> You have a number of good points. I think the best way to resolve this is to set up a separate "featurezilla" with a different url.

Well, Sean took a lot of the wind out of my sails by making my arguments for me.  I'm probably going to restate a lot of what he said, some of it is worth saying twice. :)

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

What is the value in separating one type of issue from the others?  I haven't seen a project yet that does that (be it commercial or open source).  Issues form a spectrum be they implementation bugs, design defects, unclear docs, unclear specs, missing features, desired features, etc.  There's not a clear dividing line.  What to one person is a missing feature, another considers a bug.  Why even have the debate when there's one place to file the issue?  With bugzilla and its ilk it's very easy to change priority, etc to clarify.  If a bug is filed in the 'wrong' system, you've got to go through considerably more effort to move the bug.  Then what if, after discussion, your mind is changed back?  A lot of hassle, imho.

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

I agree that the bugzilla issue/comment list isn't ideal, but neither is the news group.  Nothing is, so let's look at where strengths lie:

Newsgroups:
  -- more flexible posting/reading mechanisms

Bugzilla
  -- issue state tracking, nothing gets lost
  -- (re-)prioritization or (re-)categorization, no problem with
     'misfiled' issues.

I'm sure more can be come up with on both sides, but it's not really the focus of this topic, so I'll leave it alone unless someone feels the need to continue to debate this point.

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

I have to disagree here too based on the track record of the last several months of newsgroup (sorry, I lack the history of others here).  People post to the ng a proposal and firmly expect it to be accepted and implemented.  You can see evidence of this both in the ng and in some of the wiki's where people have tried to keep wishlists.

No issue tracked anywhere has any implied concensus to me, be it wiki, the newsgroup, or bugzilla.

I think, personally, one of the bigger issues with concensus is the lack of clear followup about what is being implemented from a discussion until after a new release appears with it.

> 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 agree that the wiki(s) around have been filling this role.  Until recently they've been the only option so people have used what's available.  However, that doesn't mean they're _good_ at the role. They're good at many editor style collaberative documentation and referencing other bits of documentation.  They're not good at tracking state, categorization, prioritization, or capturing a thread of comments.

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

I've never understood how/why 'people' misuse these sorts of stats.  I've seen one particularly insane person who did do this with respect to mozilla's bugzilla instance, and was well acknowledged by pretty much everyone as a raving lunatic.  Using bug counts as a measure of viability is absurd.  It's a sign of activity, project robustness.  A system with few bug entries is a system that's not being actively used by anyone and has little indicator of the stablity/state of it.

Are you seeing someone who's using bugzilla or the newsgroups in this way already?  If the project and community can't counter these arguments, placement of the info isn't going to stop them, they'll just change the way they attempt to detract from D.


So, to bring this to some sort of conclusion.. the last point of contention indicated by your response above is where the bugs should be housed.  I'm willing to add products and components to help segregate feature requests if the 'enhancement' priority is insufficient segregation, but I am not eager to get rid of the entire concept from the system as I strongly believe it's the wrong thing to do.


Later,
Brad

Sean Kelly wrote:
> Walter Bright wrote:
>>> On Fri, 9 Jun 2006, d-bugmail@puremagic.com wrote:
>>>> > ------- Comment #1 from bugzilla@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

Brad Roberts wrote:
>> 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.)
> 
> I agree that the bugzilla issue/comment list isn't ideal, but neither is the news group.  Nothing is, so let's look at where strengths lie:
> 
> Newsgroups:
>   -- more flexible posting/reading mechanisms
> 
> Bugzilla
>   -- issue state tracking, nothing gets lost
>   -- (re-)prioritization or (re-)categorization, no problem with      'misfiled' issues.
> 
> I'm sure more can be come up with on both sides, but it's not really the focus of this topic, so I'll leave it alone unless someone feels the need to continue to debate this point.
> 

The Newsgroup is much better than the bugzilla for this purpose. See OP with reply to Sean Kelly. I also disagree on the supposed disadvantages "issue state tracking, nothing gets lost" and "(re-)prioritization or (re-)categorization", see below.

>> 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 agree that the wiki(s) around have been filling this role.  Until recently they've been the only option so people have used what's available.  However, that doesn't mean they're _good_ at the role.  They're good at many editor style collaberative documentation and referencing other bits of documentation.  They're not good at tracking state, categorization, prioritization, or capturing a thread of comments.
> 

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 numericaly (like voting), making a text-editing tool like Wiki more adequate.


categorization:
I disagree, the Wiki is just as good at that as Bugzilla, perhaps even better.

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.

capturing a thread of comments:
True the Wiki is not good at this, but neither is Bugzilla.


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

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

Brad Roberts wrote:
> On Fri, 9 Jun 2006, Walter Bright wrote:
>> 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.
> 
> I've never understood how/why 'people' misuse these sorts of stats.

I've seen it enough times to understand the motivations:

1) management made an issue out of the "bug count", so the bug count is what gets worked. I've seen places with the "bug count" graphed over time prominently displayed on the wall.
2) it's an easy copout way to justify not using a product
3) it's easy to copy/paste the "bug list" into your "review" of the product
4) it's an easy way to discredit a product

I've seen all of these at play in real corporations, mainstream programming print magazines, etc.

Since these are all superficial, the people doing such have no interest in investigating how to sort out "enhancement" qualifications, presuming they even notice the existence of that category. After all, the title of the database is BUGzilla, not ACTIONITEMzilla or TODOzilla.


> I've seen one particularly insane person who did do this with respect to mozilla's bugzilla instance, and was well acknowledged by pretty much everyone as a raving lunatic.  Using bug counts as a measure of viability is absurd.  It's a sign of activity, project robustness.  A system with few bug entries is a system that's not being actively used by anyone and has little indicator of the stablity/state of it.

I agree with you it's absurd. But the reality is that people can and do use bug counts as a measure of quality or progress towards quality.

> Are you seeing someone who's using bugzilla or the newsgroups in this way already?

I've seen it happen on every single project I've worked on for other people. And yes, it is happening with D - people get uncomfortable when the bug count rises, or when Dstress shows a lower percentage passing, even though that often happens when the quality of the compiler rises.

(For example, it's possible that fixing "templates don't work" may result in a dozen new "templates in this odd case don't work". So the bug count increased, but the quality had improved.)

> If the project and community can't counter these arguments, placement of the info isn't going to stop them, they'll just change the way they attempt to detract from D.

People are always going to take shortcuts to understanding something. When something labeled as a BUG database is filled with enhancement suggestions, they will be perceived as bugs - not by you or me, but by people taking a quick first look at D. Trying to counter that first impression will consume a lot of our energy we can ill afford to expend. It's a lot easier to give a correct first impression than to try to counter a false one. Listing enhancement requests in a bug database gives a bad first impression.

Walter Bright wrote:
> Brad Roberts wrote:
> 
>> I've seen one particularly insane person who did do this with respect to mozilla's bugzilla instance, and was well acknowledged by pretty much everyone as a raving lunatic.  Using bug counts as a measure of viability is absurd.  It's a sign of activity, project robustness.  A system with few bug entries is a system that's not being actively used by anyone and has little indicator of the stablity/state of it.
> 
> I agree with you it's absurd. But the reality is that people can and do use bug counts as a measure of quality or progress towards quality.

Very true.  In fact, rewards are sometimes even given to those who close the greatest number of "bug" entries per release.  Oddly, this seems to encourage developers to produce a shoddy product so they have a never-ending stream of bugs assigned to them.  It also makes no differentiation between implementing new features (difficult and productive work) vs. trivial bug fixes (easy and non-productive work), but I suppose that's what you get when non-technical people are the ones structuring the work environment.

>> Are you seeing someone who's using bugzilla or the newsgroups in this way already?
> 
> I've seen it happen on every single project I've worked on for other people. And yes, it is happening with D - people get uncomfortable when the bug count rises, or when Dstress shows a lower percentage passing, even though that often happens when the quality of the compiler rises.
> 
> (For example, it's possible that fixing "templates don't work" may result in a dozen new "templates in this odd case don't work". So the bug count increased, but the quality had improved.)

One aspect of bug tracking I like is marking whether a bug is theoretical or is the result of an actual use case.  The latter sort of bugs tend to be the most important, while the former are the sort that often crop up while working on other bugs.

>> If the project and community can't counter these arguments, placement of the info isn't going to stop them, they'll just change the way they attempt to detract from D.
> 
> People are always going to take shortcuts to understanding something. When something labeled as a BUG database is filled with enhancement suggestions, they will be perceived as bugs - not by you or me, but by people taking a quick first look at D. Trying to counter that first impression will consume a lot of our energy we can ill afford to expend. It's a lot easier to give a correct first impression than to try to counter a false one. Listing enhancement requests in a bug database gives a bad first impression.

People tend to see what they want to see.  If they're excited about D they'll see the bug list as a productive thing.  If they're critical, they'll see it as a laundry list of why the language will never succeed.  That said, I do think a reasonable compromise would be what you stated earlier--to track enhancements in a separate project.  It makes for somewhat more difficult change tracking and such, but perhaps it's worth it if it offers less ammunition to the uninformed.


Sean

Walter Bright wrote:

> People are always going to take shortcuts to understanding something. When something labeled as a BUG database is filled with enhancement suggestions, they will be perceived as bugs - not by you or me, but by people taking a quick first look at D. Trying to counter that first impression will consume a lot of our energy we can ill afford to expend. It's a lot easier to give a correct first impression than to try to counter a false one. Listing enhancement requests in a bug database gives a bad first impression.

You have previously worked on commercial projects, where any sort of public information on the quality of the product might have been difficult to get by.

D is very much unlike these projects, and is per your own wishes an open project. And all commercial corporation today need to take into themselves that a large number of viable and important software projects are open, and they support them, even if they like KDE have 12000 open bug reports and 10000 open wishes, numbers posted and commented on weekly, with bug closing stats, and new bugs stats.

In the open source software world, bugzilla is known for holding both bugs and enhancements request, and if some commercial entity decides not to use D, it is because it is an open project (because someone still thinks that is a sign of low quality). If they are open to open projects, they already know that a bugzilla also usually contains enhancements.

We need the right tool to track what happens, and currently bugzilla is the only alternative (and considering other projects, seriously successful at that!) Several enhancements posts to the bugzilla shows that people expect it to handle such. And as OpenOffice.org call their bugzilla IssueZilla, I suspect that a similar change would be possible here.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi