www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Should enhancement requests be allowed in bugzilla?

reply Walter Bright <newshound digitalmars.com> writes:
 On Fri, 9 Jun 2006, d-bugmail puremagic.com wrote:


 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.
Jun 09 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 On Fri, 9 Jun 2006, d-bugmail puremagic.com wrote:




 -------

 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
Jun 09 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Jun 09 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
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
Jun 10 2006
next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 11 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Jun 11 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jun 11 2006
parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 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.


I did see one corporation reward engineers for minimizing the bug count. 
What was the result? Long, knock-down drag-out fights over what was and 
was not a bug. Long, knock-down drag-out fights over whether bug A was 
one bug or really 2 bugs, or 3 bugs. And worst of all, engineers were 
motivated to at all costs avoid entering bugs in the database at all.

It worked for about a week until the engineers figured out how to game 
the system. About a month later, management realized it was a disaster 
and pulled it.
Jun 11 2006
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jun 11 2006
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Sun, 11 Jun 2006, Lars Ivar Igesund wrote:


 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.


I've worked on both opened and (more often) closed source commercial 
projects.  In every one of them, the same system was used for tracking 
bugs and issues, so I'm biased by experience.  The only place I've seen 
two systems used for tracking issues is where one was used for operational 
problems (auto-cut tickets be it hardware failures, unexpected system 
latencies, manifestations of bugs,etc) and another used for longer term 
bug tracking and feature management.  Even in that environemnt, the main 
reason for not moving the auto-cuts into the same system as used for issue 
tracking was more due to legacy and pain of re-configuring hundreds of 
systems than anything else (both on the ticket creation side as well as 
the reporting and messaging of the events associated with the tickets).


 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.


Well said. :)

The only real comment I have is that D isn't different in that it's open 
vs closed source, since in some important ways it still is closed source, 
but more that it's controlled by a single person at least from a primary 
compiler and language definition standpoint.  That does change the game a 
bit in comparison to most other projects.


 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.


Only is too strong a word, there are definitly others.  Bugzilla is the 
one I have the most experience with and debatably is one of the best known 
systems so it's what I setup.  Some other notable examples: trac, jira, 
gnats, fogbugz, eventum.

As an experiment, I took 15 minutes or so to find and change the 
bugzilla templates to use 'issue' throughout a high percentage of the 
instances (there's a simple config variable for it).  Additionally, I've 
added a symlink so that it can be accessed as:

   http://d.puremagic.com/issues/ as well as
   http://d.puremagic.com/bugzilla/

Obviously this isn't a 100% obliteration of the term 'bug' from any usage 
all over.  There's cgi's that would need to be renamed, form parameters 
passed in url's, etc.  It's still a useful experiment, I think.

Later,
Brad
Jun 11 2006
parent Walter Bright <newshound digitalmars.com> writes:
Brad Roberts wrote:

 As an experiment, I took 15 minutes or so to find and change the 
 bugzilla templates to use 'issue' throughout a high percentage of the 
 instances (there's a simple config variable for it).  Additionally, I've 
 added a symlink so that it can be accessed as:
 
    http://d.puremagic.com/issues/ as well as
    http://d.puremagic.com/bugzilla/
 
 Obviously this isn't a 100% obliteration of the term 'bug' from any usage 
 all over.  There's cgi's that would need to be renamed, form parameters 
 passed in url's, etc.  It's still a useful experiment, I think.


Yes, and I think it's a reasonable fix. Let's see how it goes.
Jun 14 2006
prev sibling parent BCS <BCS_member pathlink.com> writes:
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.




While the incorrect first impression is bad, what I would be most worried about
is someone who is willing to fabricate sudo-facts to make D look bad for some
reason. Listing bugs with enhancement just gives them something to misquote.

In article <e6i3nf$j7l$1 digitaldaemon.com>, Lars Ivar Igesund says...

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.


Is their any what to make it impossible to get a listing of bugs and enhancement
in the same page? If the system were tweaked so the filters won't pass both at
the same time (ever, even for a "all issues" count), that would make it clear
that they aren't the same thing.
Jun 11 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 On Fri, 9 Jun 2006, d-bugmail puremagic.com wrote:




 -------

 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
Jun 11 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
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
Jun 11 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 14 2006
prev sibling parent "Derek Parnell" <derek psych.ward> writes:
Yes.

(1) Its the best issue tracking system we have got working for us. It is a  
stable product. It can cope with the sort of functionality needed by  
Walter to manage issues.
(2) There are a number of things that need to be managed when developing a  
software product. And as it happens, the type of data and management  
processes are nearly identical for errors (a.k.a. bugs), enhancements, and  
requests for information, so a single tool that handles all these is more  
efficient. It takes lees time and energy to manage a single tool than  
multiple tools.

One can't prevent stupidity but one can demonstrate honesty. So if people  
use the data in an issue tracking system to make stupid conclusions there  
is nothing you can really do to prevent that. At best you can moderate the  
damage by highlighing your integrity by admitting the existance of  
problems and demonstating attention to them, and also showing direction  
with respect to requests from your clientele.

Walter, like all developers, needs tools to manage large number of issues  
with their products. We can see the obvious need when it comes to reported  
errors, but the need with requests is just as great. It is too easy to  
misplace adhoc requests and too easy to forget to provide feedback. A  
tracking system, like bugzilla, can be a useful two-way communication  
tool, even though it is not the one to use for discussions. We have other  
tools for that function - wikis and forums, for example.

-- 
Derek Parnell
Melbourne, Australia
Jun 11 2006