Talk:Objective:One place to track feedback - Revision history

qgil at 19:53, 25 July 2008

2008-07-25T19:53:51Z

← Older revision		Revision as of 19:53, 25 July 2008
Line 5:		Line 5:
	:There is one (important?) detail in the way new features are introduced in the Maemo SW official products. Small enhancements, really small ones going down to the code and not touching much the UI, can be implemented directly by lead developers without much internal negotiation. You have example with Marius with the Application Manager or timeless with the browser. However, anything bigger than that e.g. a new feature that introduces an API change, a visual change or a new entry in a menu, will easily involve the development team and very likely the related product manager. In this case timings and processes are different, and the developer alone can't just go and hack. The ''worst'' is to fall in between, something too big for a developer alone to hack in an afternoon but too small to fall in the priorities of the team and product management.		:There is one (important?) detail in the way new features are introduced in the Maemo SW official products. Small enhancements, really small ones going down to the code and not touching much the UI, can be implemented directly by lead developers without much internal negotiation. You have example with Marius with the Application Manager or timeless with the browser. However, anything bigger than that e.g. a new feature that introduces an API change, a visual change or a new entry in a menu, will easily involve the development team and very likely the related product manager. In this case timings and processes are different, and the developer alone can't just go and hack. The ''worst'' is to fall in between, something too big for a developer alone to hack in an afternoon but too small to fall in the priorities of the team and product management.
	:I see that IdeaStorm might work well to drive the attention of product managers on those well formulated features that are clearly pushed by the community. Better than bugzilla supported by plans in wiki pages, I still don't know. This has a lot to do with users voting and the information being well organized. If IdeaStorm is seen as more attractove by users and they participate more and better than in bugzilla, then fine. But we have one tool more to feed and maintain, and this is why I prefer that we are totally sure that it's going to be used and useful. What I don't see is this workflow you describe from IdeaStorm to bugzilla, as I don't see bugzilla as a tool to organize tasks (others do, certainly).--[[User:qgil\|qgil]] 19:10, 24 July 2008 (UTC)		:I see that IdeaStorm might work well to drive the attention of product managers on those well formulated features that are clearly pushed by the community. Better than bugzilla supported by plans in wiki pages, I still don't know. This has a lot to do with users voting and the information being well organized. If IdeaStorm is seen as more attractove by users and they participate more and better than in bugzilla, then fine. But we have one tool more to feed and maintain, and this is why I prefer that we are totally sure that it's going to be used and useful. What I don't see is this workflow you describe from IdeaStorm to bugzilla, as I don't see bugzilla as a tool to organize tasks (others do, certainly).--[[User:qgil\|qgil]] 19:10, 24 July 2008 (UTC)
		+
		+	== Increase End-User Involvement ==
		+	''Moved from [[2010 Agenda]]''.
		+
		+	Allowances need to be made to elicit and encourage feedback from non-technical users. User complaints and ideas need an outlet if maemo is to stay relevant as anything other than an obscure hacker's project. Quality Assurance needs to center on the users' needs, not the developers'. This type of QA is vital, but thankless. It should be determined what resources Nokia is willing to contribute to such an effort, given the difficulty in getting developers to voluntarily see such an effort as a high priority.

qgil: /* Bugzilla vs. IdeaStorm */

2008-07-24T19:10:06Z

Bugzilla vs. IdeaStorm

← Older revision		Revision as of 19:10, 24 July 2008
Line 3:		Line 3:

	One complements the other, IdeaStorm makes Bugzilla more effective by allowing it to focus on smaller pieces, while Bugzilla makes IdeaStorm more effective by giving developers more numerous, smaller, and clearer targets to sink their teeth into. —[[User:generalantilles\|GeneralAntilles]] 11:40, 24 July 2008 (UTC)		One complements the other, IdeaStorm makes Bugzilla more effective by allowing it to focus on smaller pieces, while Bugzilla makes IdeaStorm more effective by giving developers more numerous, smaller, and clearer targets to sink their teeth into. —[[User:generalantilles\|GeneralAntilles]] 11:40, 24 July 2008 (UTC)
		+	:There is one (important?) detail in the way new features are introduced in the Maemo SW official products. Small enhancements, really small ones going down to the code and not touching much the UI, can be implemented directly by lead developers without much internal negotiation. You have example with Marius with the Application Manager or timeless with the browser. However, anything bigger than that e.g. a new feature that introduces an API change, a visual change or a new entry in a menu, will easily involve the development team and very likely the related product manager. In this case timings and processes are different, and the developer alone can't just go and hack. The ''worst'' is to fall in between, something too big for a developer alone to hack in an afternoon but too small to fall in the priorities of the team and product management.
		+	:I see that IdeaStorm might work well to drive the attention of product managers on those well formulated features that are clearly pushed by the community. Better than bugzilla supported by plans in wiki pages, I still don't know. This has a lot to do with users voting and the information being well organized. If IdeaStorm is seen as more attractove by users and they participate more and better than in bugzilla, then fine. But we have one tool more to feed and maintain, and this is why I prefer that we are totally sure that it's going to be used and useful. What I don't see is this workflow you describe from IdeaStorm to bugzilla, as I don't see bugzilla as a tool to organize tasks (others do, certainly).--[[User:qgil\|qgil]] 19:10, 24 July 2008 (UTC)

generalantilles: /* Bugzilla vs. IdeaStorm */

2008-07-24T11:43:23Z

Bugzilla vs. IdeaStorm

← Older revision		Revision as of 11:43, 24 July 2008
Line 1:		Line 1:
	== Bugzilla vs. IdeaStorm ==		== Bugzilla vs. IdeaStorm ==
-	On this, my view was always that IdeaStorm would be the place to develop and enhance ideas, which would lead to a mature idea being broken up and fed into Bugzilla as individual enhancement requests. So, take for example, [[User:GeneralAntilles/Improving the Application manager\|my page on the Application manager]], once the idea is matured enough, it can start being parceled out into smaller enhancement requests. Things like, "Add these buttons to the main view", or "Switch to finger-friendly scrollbars", etc. This gives developers clearer, smaller goals to work with and ensures some degree of certainty with the request before it's filed. —[[User:generalantilles\|GeneralAntilles]] 11:40, 24 July 2008 (UTC)	+	On this, my view was always that IdeaStorm would be the place to develop and enhance ideas, which would lead to a mature idea being broken up and fed into Bugzilla as individual enhancement requests. So, take for example, [[User:GeneralAntilles/Improving the Application manager\|my page on the Application manager]], once the idea is matured enough, it can start being parceled out into smaller enhancement requests. Things like, "Add these buttons to the main view", or "Switch to finger-friendly scrollbars", etc. This gives developers clearer, smaller goals to work with and ensures some degree of certainty with the request before it's filed.
		+
		+	One complements the other, IdeaStorm makes Bugzilla more effective by allowing it to focus on smaller pieces, while Bugzilla makes IdeaStorm more effective by giving developers more numerous, smaller, and clearer targets to sink their teeth into. —[[User:generalantilles\|GeneralAntilles]] 11:40, 24 July 2008 (UTC)

generalantilles: New page: == Bugzilla vs. IdeaStorm == On this, my view was always that IdeaStorm would be the place to develop and enhance ideas, which would lead to a mature idea being broken up and fed into Bugz...

2008-07-24T11:40:54Z

New page: == Bugzilla vs. IdeaStorm == On this, my view was always that IdeaStorm would be the place to develop and enhance ideas, which would lead to a mature idea being broken up and fed into Bugz...

New page

== Bugzilla vs. IdeaStorm ==
On this, my view was always that IdeaStorm would be the place to develop and enhance ideas, which would lead to a mature idea being broken up and fed into Bugzilla as individual enhancement requests. So, take for example, [[User:GeneralAntilles/Improving the Application manager|my page on the Application manager]], once the idea is matured enough, it can start being parceled out into smaller enhancement requests. Things like, "Add these buttons to the main view", or "Switch to finger-friendly scrollbars", etc. This gives developers clearer, smaller goals to work with and ensures some degree of certainty with the request before it's filed. —[[User:generalantilles|GeneralAntilles]] 11:40, 24 July 2008 (UTC)