Bugzilla - Revision history

JaroslavTulach: Undo revision 4078 by JaroslavTulach (Talk)

2010-09-08T08:02:51Z

Undo revision 4078 by JaroslavTulach (Talk)

←Older revision		Revision as of 08:02, 8 September 2010
Line 96:		Line 96:

	* 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/>

JaroslavTulach: /* External Links */

2010-09-08T04:31:14Z

External Links

←Older revision		Revision as of 04:31, 8 September 2010
Line 96:		Line 96:

	* 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/>

JaroslavTulach: /* External Links */

2010-09-07T20:40:49Z

External Links

←Older revision		Revision as of 20:40, 7 September 2010
Line 96:		Line 96:

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

	<comments/>		<comments/>

JaroslavTulach at 19:20, 7 September 2010

2010-09-07T19:20:49Z

←Older revision		Revision as of 19:20, 7 September 2010
Line 93:		Line 93:
	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?

		+	== External Links ==
		+
		+	* 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/>

JaroslavTulach: /* Two Issue Trackers */

2010-09-07T19:09:52Z

Two Issue Trackers

←Older revision		Revision as of 19:09, 7 September 2010
Line 73:		Line 73:
	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 ==

JaroslavTulach: /* Two Issue Trackers */

2010-09-07T19:08:16Z

Two Issue Trackers

←Older revision		Revision as of 19:08, 7 September 2010
Line 71:		Line 71:
	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.

JaroslavTulach: /* Two Issue Trackers */

2010-09-07T19:06:25Z

Two Issue Trackers

←Older revision		Revision as of 19:06, 7 September 2010
Line 69:		Line 69:
	== 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.

JaroslavTulach: /* Two Issue Trackers */

2010-09-07T18:22:15Z

Two Issue Trackers

←Older revision		Revision as of 18:22, 7 September 2010
Line 69:		Line 69:
	== 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.

JaroslavTulach: /* User Point of View */

2010-09-07T18:15:52Z

User Point of View

←Older revision		Revision as of 18:15, 7 September 2010
Line 64:		Line 64:
	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.
		+
		+	The above however applies for bugs which are not real bugs, more feature requests. It is enough to report problems in a way that gets attention of ''project owner''. For example once my bug ''X server does not work on Xvnc under vserver'' (which has been ignored for ages) have been renamed to ''Segmentation fault in X server color setup routines''. Immediately my report got appropriate attention and was fixed almost instantly. Why? Because every developer could suddenly understand that crash of the application is something that requires ''project owner'' attention (without necessity to even understand who's the project owner).

	== Two Issue Trackers ==		== Two Issue Trackers ==

72.99.218.33: /* User Point of View */

2010-09-07T17:10:21Z

User Point of View

←Older revision		Revision as of 17:10, 7 September 2010
Line 52:		Line 52:
	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.