digitalmars.D.bugs - Should enhancement requests be allowed in bugzilla?
- Walter Bright (38/62) Jun 09 2006 My objections are:
- Sean Kelly (64/136) Jun 09 2006 I disagree. Projects that I've worked on in the past tend to use the
- Walter Bright (3/6) Jun 09 2006 You have a number of good points. I think the best way to resolve this
- Brad Roberts (61/106) Jun 10 2006 Well, Sean took a lot of the wind out of my sails by making my arguments...
- Bruno Medeiros (24/63) Jun 11 2006 The Newsgroup is much better than the bugzilla for this purpose. See OP
- Walter Bright (31/57) Jun 11 2006 I've seen it enough times to understand the motivations:
- Sean Kelly (21/55) Jun 11 2006 Very true. In fact, rewards are sometimes even given to those who close...
- Walter Bright (9/20) Jun 11 2006 I did see one corporation reward engineers for minimizing the bug count....
- Lars Ivar Igesund (24/32) Jun 11 2006 You have previously worked on commercial projects, where any sort of pub...
- Brad Roberts (33/64) Jun 11 2006 I've worked on both opened and (more often) closed source commercial
- Walter Bright (2/13) Jun 14 2006 Yes, and I think it's a reasonable fix. Let's see how it goes.
- BCS (8/22) Jun 11 2006 While the incorrect first impression is bad, what I would be most worrie...
- Bruno Medeiros (46/178) Jun 11 2006 I have to say I mostly disagree .
- Brad Roberts (64/110) Jun 11 2006 I generally avoid being this blunt, but you're totally wrong on this
- Bruno Medeiros (73/201) Jun 14 2006 I'm not comparing that task/"homework" because that measures bugzilla's
- Derek Parnell (26/26) Jun 11 2006 Yes.
On Fri, 9 Jun 2006, d-bugmail puremagic.com wrote: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.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.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
Jun 09 2006
Walter Bright wrote: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.On Fri, 9 Jun 2006, d-bugmail puremagic.com wrote: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.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.-------The bug list is not a very good discussion forum about the meritsor demeritsof proposed enhancements.system forIf Brad (or anyone else) wants to set up a separate bugzillaenhancement requests, that would be fine and likely useful. Butthis one shouldbe for bugs only.Bugs are arbitrarily defined as:1) doesn't work as documented 2) contradictory, missing, or obviously wrong documentation2) 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
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
On Fri, 9 Jun 2006, Walter Bright wrote:Sean Kelly wrote: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. :)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.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
Brad Roberts wrote: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.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.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#D4) 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.
Jun 11 2006
Brad Roberts wrote:On Fri, 9 Jun 2006, Walter Bright wrote: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.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.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
Walter Bright wrote:Brad Roberts wrote: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'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.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.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.)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. SeanIf 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
Sean Kelly wrote:Walter Bright wrote: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.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.
Jun 11 2006
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
On Sun, 11 Jun 2006, Lars Ivar Igesund wrote:Walter Bright wrote: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).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.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
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
Walter Bright wrote: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...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.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
Sean Kelly wrote:Walter Bright wrote: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: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.On Fri, 9 Jun 2006, d-bugmail puremagic.com wrote: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.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.-------The bug list is not a very good discussion forum about the meritsor demeritsof proposed enhancements.system forIf Brad (or anyone else) wants to set up a separate bugzillaenhancement requests, that would be fine and likely useful. Butthis one shouldbe for bugs only.Bugs are arbitrarily defined as:1) doesn't work as documented 2) contradictory, missing, or obviously wrong documentation2) 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?"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
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
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'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.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."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.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.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 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.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)Back to the same, tracking state and priority is not that really that important for design issues.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.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#Dprioritization: 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 14 2006
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