* Sort of common way to deal with growing number of issues: [http://www.jwz.org/doc/cadt.html Cascade of Attention-Deficit Teenagers] - e.g. don't close one by one after proper evaluation, rather close all of them in a batch once per year. Needless to say I prefer the one by one evaluation and see it more honest.

* Sort of common way to deal with growing number of issues: [http://www.jwz.org/doc/cadt.html Cascade of Attention-Deficit Teenagers] - e.g. don't close one by one after proper evaluation, rather close all of them in a batch once per year. Needless to say I prefer the one by one evaluation and see it more honest.

* This essay was linked from [http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/ Hacker News]. I guess that helps (maybe together with the article title). I have not yet seen such amount of traffic on this website...

* This essay was linked from [http://news.ycombinator.com/item?id=1668780 Hacker News]. I guess that helps (maybe together with the article title). I have not yet seen such amount of traffic on this website...

<comments/>

<comments/>

* Sort of common way to deal with growing number of issues: [http://www.jwz.org/doc/cadt.html Cascade of Attention-Deficit Teenagers] - e.g. don't close one by one after proper evaluation, rather close all of them in a batch once per year. Needless to say I prefer the one by one evaluation and see it more honest.

* Sort of common way to deal with growing number of issues: [http://www.jwz.org/doc/cadt.html Cascade of Attention-Deficit Teenagers] - e.g. don't close one by one after proper evaluation, rather close all of them in a batch once per year. Needless to say I prefer the one by one evaluation and see it more honest.

* This essay was linked from [http://news.ycombinator.com/ Hacker News]. I guess that helps (maybe together with the article title). I have not yet seen such amount of traffic on this website...

* This essay was linked from [http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/ Hacker News]. I guess that helps (maybe together with the article title). I have not yet seen such amount of traffic on this website...

<comments/>

<comments/>

* Sort of common way to deal with growing number of issues: [http://www.jwz.org/doc/cadt.html Cascade of Attention-Deficit Teenagers] - e.g. don't close one by one after proper evaluation, rather close all of them in a batch once per year. Needless to say I prefer the one by one evaluation and see it more honest.

* Sort of common way to deal with growing number of issues: [http://www.jwz.org/doc/cadt.html Cascade of Attention-Deficit Teenagers] - e.g. don't close one by one after proper evaluation, rather close all of them in a batch once per year. Needless to say I prefer the one by one evaluation and see it more honest.

<comments/>

<comments/>

This is exactly the feedback every [[open source]] project needs! Clearly there is a wish and clearly nobody wants to sponsor its development. What else this issue deserves than ''won'tfix'' status and ''donation-required'' remark?

This is exactly the feedback every [[open source]] project needs! Clearly there is a wish and clearly nobody wants to sponsor its development. What else this issue deserves than ''won'tfix'' status and ''donation-required'' remark?

<comments/>

<comments/>

Some users however believe that their inquiries should be treated as bugs while they are more a feature requests. If reports of this kind are left open, then there can be tons of issues that represent user wishes, but are generally left ignored. Unless issues have sponsor, some project owner willing to accept them as an work item, they are useless. As argued in the ''throw away'' essay, such situation needs to be prevented.

Some users however believe that their inquiries should be treated as bugs while they are more a feature requests. If reports of this kind are left open, then there can be tons of issues that represent user wishes, but are generally left ignored. Unless issues have sponsor, some project owner willing to accept them as an work item, they are useless. As argued in the ''throw away'' essay, such situation needs to be prevented.

Still there are users that would likely pay for their issues to be resolved, within their financial possibilities, if that would get them a higher quality product. They care about the issues and contribute to the project ecosystem by reporting the issues. They don't care whether there is a ''project owner'' to treat their issues right. In the end, software is made for its users. Users mostly don't write the specifications. If something violates common user expectations, or has some other usability flaw, it is a defect of the software no matter what. If it doesn't violate the specification, then it is a specification bug or omission.

From time to time there are users willing pay for their issues to be resolved, within their financial possibilities, if that would get them a higher quality product. They care about the issues and contribute to the project ecosystem by reporting the issues. They don't care whether there is a ''project owner'' to treat their issues right. In the end, software is made for its users. Users mostly don't write the specifications. If something violates common user expectations, or has some other usability flaw, it is a defect of the software no matter what. If it doesn't violate the specification, then it is a specification bug or omission.

Tracking such feature requests (which are not seen as bugs by any active ''Project Owner'') will result in thousands of valid enhancements reports. However that goes directly about the approach of ''throwing them away''. What can be done about that? Maybe we need two bug trackers, one for bugs against the specification, and another one for specification bugs?

However tracking such feature requests (which are not seen as bugs by any active ''Project Owner'') will result in thousands of valid enhancements reports. That goes directly about the approach of ''throwing them away''. What can be done about that? Maybe we need two bug trackers, one for bugs against the specification, and another one for specification bugs?

== Bounty System ==

== Bounty System ==

The basic difference between ''throwing away bugzilla'' and keeping all user wishes in a database is in the purpose of the bug tracking system. The ''agile'' teams either don't need it at all, or need it only for short time issues. In case of [[open source]] teams that like to be ''agile'', the [[bugzilla]] is perfect for communication with users, commenting, attaching, tracking status of ''obvious bugs'' (segmentation faults, NPEs, other exceptions) which clearly need to be fixed.

The basic difference between ''throwing away bugzilla'' and keeping all user wishes in a database is in the purpose of the bug tracking system. The ''agile'' teams either don't need it at all, or need it only for short time issues. In case of [[open source]] teams that like to be ''agile'', the [[bugzilla]] is perfect for communication with users, commenting, attaching, tracking status of ''obvious bugs'' (segmentation faults, NPEs, other exceptions) which clearly need to be fixed.

But some users believe that their feature requests should be treated as bugs too. Sometimes we disagree. If such reports are left open, there can be tons of issues that represent user wishes, but are left ignored. As argued in the ''throw away'' essay, this is useless situation. Unless issues don't have a sponsor, or some project owner to accept them as an work item, they are useless.

Some users however believe that their inquiries should be treated as bugs while they are more a feature requests. If reports of this kind are left open, then there can be tons of issues that represent user wishes, but are generally left ignored. Unless issues have sponsor, some project owner willing to accept them as an work item, they are useless. As argued in the ''throw away'' essay, such situation needs to be prevented.

Still there are users that would likely pay for their issues to be resolved, within their financial possibilities, if that would get them a higher quality product. They care about the issues and contribute to the project ecosystem by reporting the issues. They don't care whether there is a ''project owner'' to treat their issues right. In the end, software is made for its users. Users mostly don't write the specifications. If something violates common user expectations, or has some other usability flaw, it is a defect of the software no matter what. If it doesn't violate the specification, then it is a specification bug or omission.

Still there are users that would likely pay for their issues to be resolved, within their financial possibilities, if that would get them a higher quality product. They care about the issues and contribute to the project ecosystem by reporting the issues. They don't care whether there is a ''project owner'' to treat their issues right. In the end, software is made for its users. Users mostly don't write the specifications. If something violates common user expectations, or has some other usability flaw, it is a defect of the software no matter what. If it doesn't violate the specification, then it is a specification bug or omission.

== Two Issue Trackers ==

== Two Issue Trackers ==

The basic difference between ''throwing away bugzilla'' and keeping all user wishes in a database is in the purpose of the bug tracking system. The ''agile'' teams either don't need it at all, or need it only for short time issues. In case of [[open source]] teams that like to be ''agile'', the [[bugzilla]] is perfect for communication with users, commenting, attaching, tracking status. These bugs (segmentation faults, NPEs, other exceptions) clearly need to be fixed.

The basic difference between ''throwing away bugzilla'' and keeping all user wishes in a database is in the purpose of the bug tracking system. The ''agile'' teams either don't need it at all, or need it only for short time issues. In case of [[open source]] teams that like to be ''agile'', the [[bugzilla]] is perfect for communication with users, commenting, attaching, tracking status of ''obvious bugs'' (segmentation faults, NPEs, other exceptions) which clearly need to be fixed.

But some users believe that their feature requests should be treated as bugs too. Sometimes we disagree. If such reports are left open, there can be tons of issues that represent user wishes, but are left ignored. As argued in the ''throw away'' essay, this is useless situation. Unless issues don't have a sponsor, or some project owner to accept them as an work item, they are useless.

But some users believe that their feature requests should be treated as bugs too. Sometimes we disagree. If such reports are left open, there can be tons of issues that represent user wishes, but are left ignored. As argued in the ''throw away'' essay, this is useless situation. Unless issues don't have a sponsor, or some project owner to accept them as an work item, they are useless.

== Two Issue Trackers ==

== Two Issue Trackers ==

The basic difference between ''throwing away bugzilla'' and keeping all user wishes in a database is in the purpose of the bug tracking system. The ''agile'' teams either don't need it at all, or need it only for short time issues. In case of [[open source]] teams that like to be ''agile'', the [[bugzilla]] is perfect for communication with users, commenting, attaching, tracking status.

The basic difference between ''throwing away bugzilla'' and keeping all user wishes in a database is in the purpose of the bug tracking system. The ''agile'' teams either don't need it at all, or need it only for short time issues. In case of [[open source]] teams that like to be ''agile'', the [[bugzilla]] is perfect for communication with users, commenting, attaching, tracking status. These bugs (segmentation faults, NPEs, other exceptions) clearly need to be fixed.

It can also contains tons of issues that represent user wishes, but as argued in the ''throw away'' essay, this is almost useless. Why? Because these don't have a sponsor, no project owner decided to accept them.

But some users believe that their feature requests should be treated as bugs too. Sometimes we disagree. If such reports are left open, there can be tons of issues that represent user wishes, but are left ignored. As argued in the ''throw away'' essay, this is useless situation. Unless issues don't have a sponsor, or some project owner to accept them as an work item, they are useless.

Still there are users that would likely pay for their issues to be resolved, within their financial possibilities, if that would get them a higher quality product. They care about the issues and contribute to the project ecosystem by reporting the issues. They don't care whether there is a ''project owner'' to treat their issues right. In the end, software is made for its users. Users mostly don't write the specifications. If something violates common user expectations, or has some other usability flaw, it is a defect of the software no matter what. If it doesn't violate the specification, then it is a specification bug or omission.

Still there are users that would likely pay for their issues to be resolved, within their financial possibilities, if that would get them a higher quality product. They care about the issues and contribute to the project ecosystem by reporting the issues. They don't care whether there is a ''project owner'' to treat their issues right. In the end, software is made for its users. Users mostly don't write the specifications. If something violates common user expectations, or has some other usability flaw, it is a defect of the software no matter what. If it doesn't violate the specification, then it is a specification bug or omission.

the problem myself and donate to the product. But nothing. Just a silence for

the problem myself and donate to the product. But nothing. Just a silence for

months. Then they close the bug with ''worksforme'' or ''incomplete'' status.

months. Then they close the bug with ''worksforme'' or ''incomplete'' status.

== Two Issue Trackers ==

== Two Issue Trackers ==

Of course, users of [[open source]] products may feel differently. By rejecting

Of course, users of [[open source]] products may feel differently. By rejecting

to track enhancements and honestly closing them (as there is no project owner that would

to track enhancements and honestly closing them (as there is no project owner that would

be willing to sponsor the work), one risk loosing the community. The previous

be willing to sponsor the work), one risks losing the community. The previous

section mentioned that ''code is the only thing that counts''. That was

section mentioned that ''code is the only thing that counts''. That was

exaggeration. Community counts as well. Thus the ''throw away your bugzilla''

exaggeration. Community counts as well. Thus the ''Throw away your [[Bugzilla]]''

position balances on the edge of making community more proactive, and loosing it.

position balances on the edge of making community more proactive, and losing it.

Certainly, with IDEs, users are mostly software developers themselves, and therefore are more likely to have the skills to contribute to the development. As opposed to, say, [[KDE]] users. However this does not make much difference. We even tried to exploit the development power in our users. But so far (e.g. after ten years of [[NetBeans]] IDE existence) no luck. Time to give up. From this perspective a bug reported by a random [[KDE]] user is no different than a bug reported by random [[NetBeans]] IDE user.

Certainly, with IDEs, users are mostly software developers themselves, and therefore are more likely to have the skills to contribute to the development. As opposed to, say, [[KDE]] users. However this does not make much difference. We even tried to exploit the development power in our users. But so far (e.g. after ten years of [[NetBeans]] IDE existence) no luck. Time to give up. From this perspective a bug reported by a random [[KDE]] user is no different than a bug reported by random [[NetBeans]] IDE user.