APIDesign - Recent changes [en]

Bugzilla

JaroslavTulach — Wed, 08 Sep 2010 08:02:51 GMT

Undo revision 4078 by JaroslavTulach (Talk)

←Older revision		Revision as of 08:02, 8 September 2010
(8 intermediate revisions not shown.)
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 ==

-	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 of ''obvious bugs'' (segmentation faults, NPEs, other exceptions) which 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~~.	+	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 ==
Line 91:		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.
		+	* 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/>

Bugzilla

72.99.218.33 — Tue, 07 Sep 2010 17:10:21 GMT

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.

Bugzilla

JaroslavTulach — Tue, 07 Sep 2010 16:33:40 GMT

←Older revision		Revision as of 16:33, 7 September 2010
Line 90:		Line 90:
	niklas: And given a donation system, there are more important issues I'd want to be addressed first.		niklas: And given a donation system, there are more important issues I'd want to be addressed first.
	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/>

Talk:LiveDB

72.158.188.130 — Tue, 07 Sep 2010 14:05:17 GMT

I am using nb 6.10.m1: new section

←Older revision		Revision as of 14:05, 7 September 2010
Line 62:		Line 62:

	--[[User:JaroslavTulach\|JaroslavTulach]] 05:46, 6 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 05:46, 6 September 2010 (UTC)
		+
		+	== I am using nb 6.10.m1 ==
		+
		+	The project that has the annotation and processor is separate from the example project. I use it as a library in the example. I still only get the completions when writing test source code.
		+
		+	I am pretty sure that is not the desired behavior. I will try a nightly build.
		+
		+	Thanks for the pointers.

Blogs:JaroslavTulach:Daily Life

JaroslavTulach — Tue, 07 Sep 2010 09:40:01 GMT

←Older revision		Revision as of 09:40, 7 September 2010
Line 2:		Line 2:

	<startFeed />		<startFeed />
		+
		+	==== Throw Away Your Bug Tracking System ====
		+
		+	Time to close our [[Bugzilla]]! Dear members of NetBeans community, I'd like to announce that I plan to close all open issues in our [[bugzilla]] (that I don't like) as won'tfix for serious reasons. Are you OK and ready for [[bugzilla\|that]]?
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 09:40, 7 September 2010 (UTC)

	==== The Differences Make the Difference! ====		==== The Differences Make the Difference! ====

Bugzilla

JaroslavTulach — Tue, 07 Sep 2010 09:32:22 GMT

Bounty System:

JavaOne2010

JaroslavTulach — Tue, 07 Sep 2010 09:13:14 GMT

←Older revision		Revision as of 09:13, 7 September 2010
Line 18:		Line 18:
	Title: Patterns for Modularity		Title: Patterns for Modularity
	Track: Core Java Platform		Track: Core Java Platform
-	Date: 22-SEP-10	+	Date: 21-SEP-10
-	Time: 14:15 - 15:00	+	Time: 18:00-18:45
	Venue: Parc 55		Venue: Parc 55
-	Room: ~~Cyril Magnin II~~	+	Room: Market Street

	ID#: S313005		ID#: S313005

KDE

JaroslavTulach — Mon, 06 Sep 2010 23:04:52 GMT

←Older revision		Revision as of 23:04, 6 September 2010
Line 1:		Line 1:
	[[wikipedia:KDE\|KDE]] is nice desktop environment especially for [[Linux]].		[[wikipedia:KDE\|KDE]] is nice desktop environment especially for [[Linux]].

-	TBD: Complain about ''yet another failed big bang rewrite''!	+	[[TBD]]: Complain about ''yet another failed big bang rewrite''!

Bugzilla

JaroslavTulach — Mon, 06 Sep 2010 17:04:43 GMT

Throw Away Your Bugtracking System:

←Older revision		Revision as of 17:04, 6 September 2010
(21 intermediate revisions not shown.)
Line 3:		Line 3:
	== Throw Away Your Bugtracking System ==		== Throw Away Your Bugtracking System ==

-	I've noticed very nice and inspiring [http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/ article] few months ago. It somehow captures ~~something~~ I always ~~had somewhere~~ deep inside me: ''Leaving tons of bugs open is useless''.	+	I've noticed very nice and inspiring [http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/ article] few months ago. It somehow captures what I always felt deep inside of me: ''Leaving tons of bugs open is useless''.

-	In March 2010 I started to practise it by announcing that I will close every issue I find that does not match the ''project owner'' expectations. I started with 300 bugs in modules of my ~~reponsibility~~ back then. Now, half a year ago I have 15 open issues. I think the [http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/ article] was right. It does not make any sense to keep issues open.	+	In March 2010 I started to practise this new bug fixing life style by announcing that I will close every issue I find that does not match the ''project owner'' expectations. I started with 300 bugs in modules of my responsibility back then. Now, half a year ago I have 15 open issues. I did what I could with issues laying around for ages. Some of them came back to me, so I needed to try once again, but overall I think the [http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/ article] was right: It does not make any sense to keep issues open.

-	Either fix them, if they are ~~producible~~. Or enhance logging and close as ''worksforme'' and wait. Or give up and honestly say that you don't care (e.g. close as ''won'tfix'').	+	Either fix them, if they are reproducible (don't forget to write a test to prevent your application [[amoeba]] from shaking). Or enhance logging and close as ''worksforme'' and wait. Or give up and honestly say that you don't care (e.g. close as ''won'tfix''). One question however remains: who's the ''project owner'' on an [[open source]] project like [[NetBeans]]?

-	~~The question however is who's the ''project owner'' on an [[open source]] project like [[NetBeans]]?~~	+	== [[Open source]] Project Owners ==
-		+
-	== [[Open ~~Source~~]] Project Owners ==	+

	The [[NetBeans]] [[bugzilla]] is full of issues that nobody addresses. The team is		The [[NetBeans]] [[bugzilla]] is full of issues that nobody addresses. The team is
Line 37:		Line 35:
	But who can be a ''product owner'' in a [[open source]] project like [[NetBeans]]?		But who can be a ''product owner'' in a [[open source]] project like [[NetBeans]]?

-	In a open community, probably everyone can ask to be seen as a ''product owner''. However,	+	In an open community, probably everyone can ask to be seen as a ''product owner''. However,
	as product owner has to be able to make decisions, it is proper to		as product owner has to be able to make decisions, it is proper to
	ask what kind of decisions a community member can make? Well, a community		ask what kind of decisions a community member can make? Well, a community
	member can decide and choose level of its own participation in the project.		member can decide and choose level of its own participation in the project.
	In particular, every [[open source]] contributor can decided how much help		In particular, every [[open source]] contributor can decided how much help
-	~~one can~~ donate to eliminate the violation ~~that one perceives~~.	+	to donate to eliminate the perceived violation of the behaviour.

	In order to keep [[open source]] open, it is important to		In order to keep [[open source]] open, it is important to
Line 50:		Line 48:
	play role of "product owner".		play role of "product owner".

		+	== User Point of View ==
		+
		+	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
		+	be willing to sponsor the work), one risk loosing the community. The previous
		+	section mentioned that ''code is the only thing that counts''. That was
		+	exaggeration. Community counts as well. Thus the ''throw away your bugzilla''
		+	position balances on the edge of making community more proactive, and loosing 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 difference than a bug reported by random [[NetBeans]] IDE user.
		+
		+	On the other hand, what is different is the attitude, honesty. My experience with mega sized [[open source]] projects like [[KDE]] is that when I report a bug for [[Amarok]], [[Kopete]], [[Xine]] or other related projects, people don't say "fix it". Rather than that people say nothing. There is just a uniform: silence! That experience leads me to conclusion: most of the
		+	open source projects just ignore requests that don't fit into their plans. I'd say, this is wrong. I'd rather see a honest response: ''we don't care''. Few basic hints (for example I don't know how to debug various libxine.so
		+	libraries) would help too. If there was a buddy to help me with initial steps, I could solve
		+	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.
		+
		+	== 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.
		+
		+	It can also contains tons of issues that represent user wishes, but as argued in the ''throw away'' essay, this almost useless. Why? Because these don't have a sponsor, no project owner decided to accept them.
		+
		+	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 for 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?

		+	== Bounty System ==

-	~~I am responsible for the module in question (e.g. issues in that module are~~	+	For [[open source]] project it makes sense to create a system where people willing to become ''Project Owners'' (or at least a feature owner) can meet those who want to do the work for them. This is slightly different bug tracking system than [[bugzilla]]. We tried to implement it few times under the name of ''NbBounty'' (but never finished it; we are not the right drives we get monthly wage by our employer).
-	~~assigned~~ to ~~me and I have~~ to ~~deal with them, otherwise there will be no next~~	+
-	~~NetBeans release). That is why I feel like~~ a ~~default "product~~ owner~~". I~~	+
-	~~believe I have the right to act according~~ to the ~~"throw away your~~ bugzilla"	+
-	~~article: e~~.~~g. unless there is a real contribution from the community, I am~~	+
-	~~going~~ to ~~decide whether something violates behavior in~~ the ~~"Done" story~~.	+

-	~~In case of #175616~~, ~~I am strongly convinced that everything behaves as was~~	+	The system is not complex. From one side the ''feature owners'' can throw in their coins in to motivate someone else
-	~~specified~~. As a ~~result I am plan~~ to ~~close~~ the ~~issue and let it in such state~~,	+	to implement features they would like to see. Bugs still belong to [[bugzilla]], but feature requests need to be supported by bucks. In
-	~~until there is someone who donates~~ the ~~work and thus qualifies for~~ a ~~"product~~	+	current society money are common indicator of engagement. [[Open source]] projects need a way to find perils among the dust. By sorting the feature requests by amount of available donations, the developers can make a qualified judgement and choose those that are worth to implement (worth in terms of usefulness as well as available reward).
-	~~owner" status with respect~~ to ~~#175616~~.	+

-	~~In case you disagree with my evaluation,~~ we can ~~bring~~ the ~~issue~~ to ~~NetBeans~~	+	Maybe we don't need special ''bounty'' system. Let's just close issues without ''project owner'' as ''wontfix'' and add a white board status '''donation-required'''. Users can then add a comment describing the amount of $ they are willing to donate if the issue is implemented. This requires a bit of trust, but for begging it might be enough. Of course we need to change the way we think about meaning of ''won'tfix''. It does not predict the future, it does not mean "the issue does not and will not ever deserve to get fixed." For such bugs [[bugzilla]] is using ''invalid'' status. Issue marked "won't fix" means a valid problem, but one that ''nobody currently doing work on the software cares about''.
-	~~Board, which~~ is ~~2/3 independent on Oracle~~. ~~I'd~~ be ~~curious~~ to ~~find out whether~~	+
-	~~they would agree with my~~ "~~product owner is~~ the ~~one who is willing~~ to ~~donate~~	+
-	~~the work~~" ~~philosophy~~.	+

-	[[~~TBD~~]]	+	Actually I have a little illustrate story showing potential success of such donation system. Niklas, who made me wrote this whole essay just replied:
		+	me: Anyway get ready for your issue to be closed unless you promise to donate a buck.
		+	niklas: I'm ready for it to be closed. :)
		+	niklas: And given a donation system, there are more important issues I'd want to be addressed first.
		+	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?

Open source

JaroslavTulach — Mon, 06 Sep 2010 11:59:50 GMT

←Older revision		Revision as of 11:59, 6 September 2010
Line 1:		Line 1:
-	[[[wikipedia:Open source\|Open source]] project gives you many freedoms with respect to the program. The most essential is a right to '''fork'''. E.g. change, re-use and distribute your own modifications to original program. [[Open source]] movement as a whole is in opposition against closed source - e.g. programs distributed with some kind of restrictions on end users or re-distributors.	+	[[wikipedia:Open source\|Open source]] project gives you many freedoms with respect to the program. The most essential is a right to '''fork'''. E.g. change, re-use and distribute your own modifications to original program. [[Open source]] movement as a whole is in opposition against closed source - e.g. programs distributed with some kind of restrictions on end users or re-distributors.

	There seem to be two main streams inside [[Open source]]:		There seem to be two main streams inside [[Open source]]:

Bugzilla

JaroslavTulach — Mon, 06 Sep 2010 11:59:22 GMT

←Older revision		Revision as of 11:59, 6 September 2010
Line 10:		Line 10:

	The question however is who's the ''project owner'' on an [[open source]] project like [[NetBeans]]?		The question however is who's the ''project owner'' on an [[open source]] project like [[NetBeans]]?
		+
		+	== [[Open Source]] Project Owners ==
		+
		+	The [[NetBeans]] [[bugzilla]] is full of issues that nobody addresses. The team is
		+	always unsure what to do with them. On one side, there is a desire is to
		+	resolve them - our release dashboard looks bad with few thousands of P3 or P4
		+	bugs (which are usually enhancements anyway). On the other side, we are
		+	tempted to believe that one day someone will take over the bug and thus we
		+	shall leave it open.
		+
		+	As far as my experience says, nobody ever took a bug just because it was open.
		+	Those issues just annoy all of us for ages. From time to time, there is a
		+	business need (e.g. someone is willing to pay) to solve some of them, but that
		+	happens with issues resolved as ''won'tfix'' as well. It is easy to reopen them in
		+	such situation. There does not seem to be a value in keeping issues nobody plans to work on
		+	open.
		+
		+	The ''throw away your bug tracking system'' article is really inspiring.
		+	I understand [[NetBeans]] is not real agile project, but never the less, we
		+	apply some agile principles. Does an enhancement violate expectations of
		+	''product owner''? Who can decide that?
		+
		+	First of all, we need to seek ''product owner''. ''Product owner'' is the one who can
		+	make decisions about the product. Certainly my employer can tell me what to do.
		+	If my company thought some behaviour violates expectations, I'd had to fix it. This is clear.
		+	But who can be a ''product owner'' in a [[open source]] project like [[NetBeans]]?
		+
		+	In a open community, probably everyone can ask to be seen as a ''product owner''. However,
		+	as product owner has to be able to make decisions, it is proper to
		+	ask what kind of decisions a community member can make? Well, a community
		+	member can decide and choose level of its own participation in the project.
		+	In particular, every [[open source]] contributor can decided how much help
		+	one can donate to eliminate the violation that one perceives.
		+
		+	In order to keep [[open source]] open, it is important to
		+	respect everyone's right to eliminate such violations. However one has to
		+	act, not just talk. In [[open source]], it is the code that counts. If one is
		+	not able to contribute that, then we need to question whether such person can
		+	play role of "product owner".
		+
		+
		+
		+	I am responsible for the module in question (e.g. issues in that module are
		+	assigned to me and I have to deal with them, otherwise there will be no next
		+	NetBeans release). That is why I feel like a default "product owner". I
		+	believe I have the right to act according to the "throw away your bugzilla"
		+	article: e.g. unless there is a real contribution from the community, I am
		+	going to decide whether something violates behavior in the "Done" story.
		+
		+	In case of #175616, I am strongly convinced that everything behaves as was
		+	specified. As a result I am plan to close the issue and let it in such state,
		+	until there is someone who donates the work and thus qualifies for a "product
		+	owner" status with respect to #175616.
		+
		+	In case you disagree with my evaluation, we can bring the issue to NetBeans
		+	Board, which is 2/3 independent on Oracle. I'd be curious to find out whether
		+	they would agree with my "product owner is the one who is willing to donate
		+	the work" philosophy.

	[[TBD]]		[[TBD]]

Talk:SQL

213.180.34.38 — Mon, 06 Sep 2010 10:45:13 GMT

Comment provided by Jiri Tulach - via ArticleComments extension

←Older revision		Revision as of 10:45, 6 September 2010
Line 71:		Line 71:

	--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 19:37, 3 September 2010 (UTC)
		+	== Jiri Tulach said ... ==
		+
		+	<div class='commentBlock'>
		+	As a Oracle employee you should know what is the best solution ;-).
		+
		+	--Jiri Tulach 12:45, 6 September 2010 (CEST)
		+	</div>

Talk:LiveDB

JaroslavTulach — Mon, 06 Sep 2010 05:46:07 GMT

←Older revision		Revision as of 05:46, 6 September 2010
Line 57:		Line 57:
	--Russ White 23:30, 4 September 2010 (CEST)		--Russ White 23:30, 4 September 2010 (CEST)
	</div>		</div>
		+
		+
		+	Hello Russ. You need to have latest development build of NetBeans 6.10 to make proper use of getCompletion method. Moreover the [[AnnotationProcessor]] needs to be compiled before you start to use the [[annotation]]. Preferably you should have your processor in one [[JAR]] file and use it from another project. That is supposed to work OK. The ''Test Packages'' are separate source root (compiled after project sources) and thus are quite similar to the previous example of packaging a [[JAR]] and using it from different project (except the [[JAR]] does not need to be created to work with the test classes). But definitely you can't use the [[AnnotationProcessor]] from among the same sources that define the processor. That would require some kind of incremental parsing and processing and I think that the [[NetBeans]] [[Java]] editor guys are not willing to bother with that.
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 05:46, 6 September 2010 (UTC)

Talk:LiveDB

68.52.64.40 — Sat, 04 Sep 2010 22:10:17 GMT

←Older revision		Revision as of 22:10, 4 September 2010
Line 38:		Line 38:
	Completions questions.		Completions questions.

-	If you put a package-info.java such as the one in the test source package into the regular source package of a project which ~~want~~ to make use of the processor (and it's static and dynamic completions), the getCompletions method is never called. Can you explain why this happens?	+	If you put a package-info.java such as the one in the test source package into the regular source package of a new project which wants to make use of the processor (and it's static and dynamic completions), the getCompletions method on the processor is never called. The processor still works at compile time, but the use of the annotation in the editor seems to be limited to the test packages. Can you explain why this happens?

	Here is what I implemented to test:		Here is what I implemented to test:
Line 50:		Line 50:
	It gets called and works fine when editing a package-info.java that is in "Test Packages"		It gets called and works fine when editing a package-info.java that is in "Test Packages"

-	~~But~~ does not get called at all while editing a copy of the same file in "Source Packages"	+	The method does not get called at all while editing a copy of the same file in "Source Packages"

-	I have to admit I am stumped. Any ideas?	+	I have to admit I am stumped. Any ideas? Is this just a NetBeans bug?


	--Russ White 23:30, 4 September 2010 (CEST)		--Russ White 23:30, 4 September 2010 (CEST)
	</div>		</div>

←Older revision		Revision as of 09:32, 7 September 2010
(7 intermediate revisions not shown.)
Line 38:		Line 38:
	as product owner has to be able to make decisions, it is proper to		as product owner has to be able to make decisions, it is proper to
	ask what kind of decisions a community member can make? Well, a community		ask what kind of decisions a community member can make? Well, a community
-	member can decide and choose level of ~~its~~ own participation in the project.	+	member can decide and choose level of own participation in the project.
-	In particular, every [[open source]] contributor can ~~decided~~ how much help	+	In particular, every [[open source]] contributor can decide how much help
	to donate to eliminate the perceived violation of the behaviour.		to donate to eliminate the perceived violation of the behaviour.

Line 46:		Line 46:
	act, not just talk. In [[open source]], it is the code that counts. If one is		act, not just talk. In [[open source]], it is the code that counts. If one is
	not able to contribute that, then we need to question whether such person can		not able to contribute that, then we need to question whether such person can
-	play role of "product owner".	+	play role of a ''product owner''.

	== User Point of View ==		== User Point of View ==
Line 57:		Line 57:
	position balances on the edge of making community more proactive, and loosing it.		position balances on the edge of making community more proactive, and loosing 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 ~~difference~~ 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.

	On the other hand, what is different is the attitude, honesty. My experience with mega sized [[open source]] projects like [[KDE]] is that when I report a bug for [[Amarok]], [[Kopete]], [[Xine]] or other related projects, people don't say "fix it". Rather than that people say nothing. There is just a uniform: silence! That experience leads me to conclusion: most of the		On the other hand, what is different is the attitude, honesty. My experience with mega sized [[open source]] projects like [[KDE]] is that when I report a bug for [[Amarok]], [[Kopete]], [[Xine]] or other related projects, people don't say "fix it". Rather than that people say nothing. There is just a uniform: silence! That experience leads me to conclusion: most of the
Line 69:		Line 69:
	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.

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

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

	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?		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?
Line 77:		Line 77:
	== Bounty System ==		== Bounty System ==

-	For [[open source]] project it makes sense to create a system where people willing to become ''Project Owners'' (or at least a feature owner) can meet those who want to do the work for them. This is slightly different bug tracking system than [[bugzilla]]. We tried to implement it few times under the name of ''NbBounty'' (but never finished it; we are not the right ~~drives~~ we get monthly wage by our employer).	+	For [[open source]] project it makes sense to create a system where people willing to become ''Project Owners'' (or at least a feature owner) can meet those who want to do the work for them. This is slightly different bug tracking system than [[bugzilla]]. We tried to implement it few times under the name of ''NbBounty'' (but never finished it; we are not the right drivers; we get monthly wage by our employer).

	The system is not complex. From one side the ''feature owners'' can throw in their coins in to motivate someone else		The system is not complex. From one side the ''feature owners'' can throw in their coins in to motivate someone else
Line 83:		Line 83:
	current society money are common indicator of engagement. [[Open source]] projects need a way to find perils among the dust. By sorting the feature requests by amount of available donations, the developers can make a qualified judgement and choose those that are worth to implement (worth in terms of usefulness as well as available reward).		current society money are common indicator of engagement. [[Open source]] projects need a way to find perils among the dust. By sorting the feature requests by amount of available donations, the developers can make a qualified judgement and choose those that are worth to implement (worth in terms of usefulness as well as available reward).

-	Maybe we don't need special ''bounty'' system. Let's just close issues without ''project owner'' as ''wontfix'' and add a white board status '''donation-required'''. Users can then add a comment describing the amount of $ they are willing to donate if the issue is implemented. This requires a bit of trust, but for ~~begging~~ it might be enough. Of course we need to change the way we think about meaning of ''won'tfix''. It does not predict the future, it does not mean "the issue does not and will not ever deserve to get fixed." For such bugs [[bugzilla]] is using ''invalid'' status. Issue marked "won't fix" means a valid problem, but one that ''nobody currently doing work on the software cares about''.	+	Maybe we don't need special ''bounty'' system. Let's just close issues without ''project owner'' as ''wontfix'' and add a white board status '''donation-required'''. Users can then add a comment describing the amount of $ they are willing to donate if the issue is implemented. This requires a bit of trust, but for beginning it might be enough. Of course we need to change the way we think about meaning of ''won'tfix''. It does not predict the future, it does not mean "the issue does not and will not ever deserve to get fixed." For such bugs [[bugzilla]] is using ''invalid'' status. Issue marked "won't fix" means a valid problem, but one that ''nobody currently doing work on the software cares about''.

	Actually I have a little illustrate story showing potential success of such donation system. Niklas, who made me wrote this whole essay just replied:		Actually I have a little illustrate story showing potential success of such donation system. Niklas, who made me wrote this whole essay just replied: