Talk:Task:Getting Nokia involved in bugs.maemo.org - Revision history

imported_>sixwheeledbeast: Reverted edits by 5.135.165.126 (Talk) to last revision by sixwheeledbeast

2013-04-30T17:36:21Z

Reverted edits by 5.135.165.126 (Talk) to last revision by sixwheeledbeast

Show changes

5.135.165.126 at 17:17, 30 April 2013

2013-04-30T17:17:55Z

Show changes

imported_>sixwheeledbeast: Undo revision 51424 by 5.135.165.126 SPAM (Talk)

2013-04-26T21:17:31Z

Undo revision 51424 by 5.135.165.126 SPAM (Talk)

Show changes

5.135.165.126 at 14:27, 26 April 2013

2013-04-26T14:27:00Z

Show changes

imported_>andre: added more explanations on today's reorg

2008-12-06T20:29:48Z

added more explanations on today's reorg

← Older revision		Revision as of 20:29, 6 December 2008
Line 145:		Line 145:
	** Connectivity		** Connectivity
	*** Bluetooth		*** Bluetooth
	*** DUN ~~('''???''' - I miss understanding...)~~		*** DUN
	*** ICD ~~('''???''' - I miss understanding...)~~		*** ICD
	*** Networking		*** Networking
	*** Operator Setup Wizard ''(was: System management/Operator Setup Wizard)''		*** Operator Setup Wizard ''(was: System management/Operator Setup Wizard)''
Line 211:		Line 211:
	Removed ancient Games/Startscreen subcomponent (only 2 bugs), Removed Desktop/PC connection (1 wrong bug), Desktop/Tableteer Info (0 bugs), Desktop/Desktop Info applet (0 bugs). Removed Communication/Accounts (3 bugs, 2 wrong). Removed System software/libcommon-error (0 bugs).		Removed ancient Games/Startscreen subcomponent (only 2 bugs), Removed Desktop/PC connection (1 wrong bug), Desktop/Tableteer Info (0 bugs), Desktop/Desktop Info applet (0 bugs). Removed Communication/Accounts (3 bugs, 2 wrong). Removed System software/libcommon-error (0 bugs).
	Removed System management/Teach handwriting (0 bugs). Removed Web shortcut (0 bugs, development stalled since Diablo).		Removed System management/Teach handwriting (0 bugs). Removed Web shortcut (0 bugs, development stalled since Diablo).
			Several additions done on Dec 06th 2008 (metalayer-crawler, HAL, OHM, Software Updater, Maps, gvfs, pango, Internationalization, meta tracker, SQLite, Pulseaudio, GStreamer, Real, etc). Removed iconf (moved into Internationalization), removed User Interaction (cleaned up and moved into other components).

	=== Draft implementation ===		=== Draft implementation ===

imported_>andre: Updating status and TODOs after today's reorg

2008-12-06T20:25:22Z

Updating status and TODOs after today's reorg

Show changes

imported_>andre: set desktop general QA; got rid of hafqa ML

2008-11-26T14:15:44Z

set desktop general QA; got rid of hafqa ML

← Older revision		Revision as of 14:15, 26 November 2008
Line 125:		Line 125:
	*** Fonts ''(was: System software/Fonts)''		*** Fonts ''(was: System software/Fonts)''
	*** gconf ''(was: System software/gconf)''		*** gconf ''(was: System software/gconf)''
	*** general ''(was: System software/general)'' ~~'''SETNEWQA''': desktop-platform-bugs@maemo.bugs ('''TODO''': kill hafqa{at}maemo.org ML)~~		*** general ''(was: System software/general)''
	*** glib ''(was: System software/glib)''		*** glib ''(was: System software/glib)''
	*** gnome-vfs ''(was: System software/gnome-vfs)''		*** gnome-vfs ''(was: System software/gnome-vfs)''

imported_>qgil: /* How often and where? */

2008-11-20T12:10:11Z

How often and where?

← Older revision		Revision as of 12:10, 20 November 2008
Line 32:		Line 32:

	:How often should the report be updated? Weekly? Monthly? Quarterly? Obviously a wiki page should be maintained for reference, but where should the reports go to? maemo-developers? A blog for this purpose?		:How often should the report be updated? Weekly? Monthly? Quarterly? Obviously a wiki page should be maintained for reference, but where should the reports go to? maemo-developers? A blog for this purpose?
			:: I'd say monthly. I was tempted to say quarterly since all teams might have some months specially stressful, but the longer the period the lesser your memory is reliable and the more you need to sustain perceptions with actual numbers.--[[User:qgil\|qgil]] 12:10, 20 November 2008 (UTC)

	:Can we start now? :D —[[User:generalantilles\|GeneralAntilles]] 08:25, 19 November 2008 (UTC)		:Can we start now? :D —[[User:generalantilles\|GeneralAntilles]] 08:25, 19 November 2008 (UTC)
	::OK, here's a really rough draft outline [[Task:Bugzilla report card]]. —[[User:generalantilles\|GeneralAntilles]] 09:07, 19 November 2008 (UTC)		::OK, here's a really rough draft outline [[Task:Bugzilla report card]]. —[[User:generalantilles\|GeneralAntilles]] 09:07, 19 November 2008 (UTC)
			:::Hum, I'd start with something more minimalistic: x=months / y=products / content of cell: bad (red background) / meh (yellow) / good (green) / star .--[[User:qgil\|qgil]] 12:10, 20 November 2008 (UTC)

	== Improvements in the weekly reports ==		== Improvements in the weekly reports ==

imported_>qgil: /* What metrics? */

2008-11-20T11:56:12Z

What metrics?

← Older revision		Revision as of 11:56, 20 November 2008
Line 27:		Line 27:

	:Should be pretty easy to implement, but what are our metrics? Initial response time? Total fix turnaround time? Probably too complicated (the more complicated it is, the easier it is to be unfair) A simple two-part response rate and fix rate combination? Should the metrics be based entirely on hard-data, or would it be appropriate to factor in perception from, say, the Bugsquad ("Yes, this team's numbers look good, but the responses were largely unhelpful and slow to arrive, and the fixes sub-par."). If the goal is simply to pin-point teams that need to improve their participation, than a perception-based grade with some statistical number crunching sounds best. —[[User:generalantilles\|GeneralAntilles]] 08:25, 19 November 2008 (UTC)		:Should be pretty easy to implement, but what are our metrics? Initial response time? Total fix turnaround time? Probably too complicated (the more complicated it is, the easier it is to be unfair) A simple two-part response rate and fix rate combination? Should the metrics be based entirely on hard-data, or would it be appropriate to factor in perception from, say, the Bugsquad ("Yes, this team's numbers look good, but the responses were largely unhelpful and slow to arrive, and the fixes sub-par."). If the goal is simply to pin-point teams that need to improve their participation, than a perception-based grade with some statistical number crunching sounds best. —[[User:generalantilles\|GeneralAntilles]] 08:25, 19 November 2008 (UTC)
			::Perception is more than enough, I think. Red = too bad. Yellow = Well, ok. Green = Good!. Star = You're amazing, thanks!. The guys are getting plenty of robotic metrics in their jobs and at the end the objective is "perceived quality". If you want to add numbers I'm sure they will be useful, but I think those 4 states (or even 2: good/bad) are good enough to chase the specific problems of the affected teams and congratulate publicly those doing a good work. --[[User:qgil\|qgil]] 11:56, 20 November 2008 (UTC)

	==== How often and where? ====		==== How often and where? ====

imported_>generalantilles: /* Draft implementation */ Cleaning up the list

2008-11-19T18:25:58Z

Draft implementation: Cleaning up the list

← Older revision		Revision as of 18:25, 19 November 2008
Line 213:		Line 213:
	=== Draft implementation ===		=== Draft implementation ===
	[http://blogs.gnome.org/aklapper/2008/11/07/bugsmaemoorg-reorganization Original plan]:		[http://blogs.gnome.org/aklapper/2008/11/07/bugsmaemoorg-reorganization Original plan]:
	# Create new default QA virtual accounts for new products/components in advance ('''done''')		<ol>
	# Define a good day/time (Sunday?)		<li>Create new default QA virtual accounts for new products/components in advance ('''done''')</li>
			<li>Define a good day/time (Sunday?)</li>
	Friday night's or holiday weekends are better [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)		</ol>
			::Friday night's or holiday weekends are better [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)
	# Display info message about reorg one week in advance in /template/en/default/global/banner.html.tmpl		<ol start="3">
	# Create dummy products (X-DoNotUse1 etc) in advance with their TMs and versions to save time (as number of planned products > current number of products)		<li>Display info message about reorg one week in advance in /template/en/default/global/banner.html.tmpl</li>
	## Create products with correct names but which have a group access restriction to the admin group. They won't show up to anyone else. [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)		<li>Create dummy products (X-DoNotUse1 etc) in advance with their TMs and versions to save time (as number of planned products > current number of products)</li>
	## Use the "shutdownhtml" param to keep everyone else out (you need a feature which we need to upstream, contact moznet#bmo for it if we haven't posted a bug+patch) [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)		</ol>
	# Disable mail notification		:: Create products with correct names but which have a group access restriction to the admin group. They won't show up to anyone else. [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)
	# Implement changes		:: Use the "shutdownhtml" param to keep everyone else out (you need a feature which we need to upstream, contact moznet#bmo for it if we haven't posted a bug+patch) [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)
	# Correct some other inconsistent QA Contact settings in some bugs that I have on a list		<ol start="5">
	## TODO: Check whether adding a disabled virtual QA Contact to watchlist really provides receiving mail - I doubt with the current settings --[[User:Andre\|Andre]])		<li>Disable mail notification</li>
	## disabling an account doesn't prevent it from getting mail, you need to disable mail in editprefs, there's a cheap url to doing this, it's something like https://bugzilla/userprefs.cgi?tab=email&dosave=1 you can use impersonation to flop in and out of each user fairly quickly. [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)		<li>Implement changes</li>
	# Enable mail notification		<li>Correct some other inconsistent QA Contact settings in some bugs that I have on a list</li>
	# Remove banner		</ol>
			::TODO: Check whether adding a disabled virtual QA Contact to watchlist really provides receiving mail - I doubt with the current settings --[[User:Andre\|Andre]])
			::disabling an account doesn't prevent it from getting mail, you need to disable mail in editprefs, there's a cheap url to doing this, it's something like https://bugzilla/userprefs.cgi?tab=email&dosave=1 you can use impersonation to flop in and out of each user fairly quickly. [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)
			<ol start="8">
			<li>Enable mail notification</li>
			<li>Remove banner</li>
			</ol>
	[[User:timeless\|timeless]] prefers to keep mail notification enabled while doing this, see [http://blogs.gnome.org/aklapper/2008/11/07/bugsmaemoorg-reorganization/#comment-325 discussion]. So far, I disagree. :) --[[User:Andre\|Andre]] 12:06, 11 November 2008 (UTC)		[[User:timeless\|timeless]] prefers to keep mail notification enabled while doing this, see [http://blogs.gnome.org/aklapper/2008/11/07/bugsmaemoorg-reorganization/#comment-325 discussion]. So far, I disagree. :) --[[User:Andre\|Andre]] 12:06, 11 November 2008 (UTC)

	the other thing i messed up in the bmo reorg basically destroyed date state about a set of bugs, the only way i had of finding them was searching through my mail [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)		the other thing i messed up in the bmo reorg basically destroyed date state about a set of bugs, the only way i had of finding them was searching through my mail [[User:timeless\|timeless]] 17:37, 19 November 2008 (UTC)