Updating tracker items - Revision history

Marko: + languages

2012-05-07T15:31:29Z

+ languages

← Older revision		Revision as of 15:31, 7 May 2012
Line 1:		Line 1:
			{{Other languages\|en=Updating tracker items}}

	We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:		We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:
	[https://bugs.launchpad.net/inkscape Launchpad Bug Tracker summary]</b>. We can use help in testing bug reports, trying to reproduce them and add more information that might help solve the problem. For example, sometimes a bug might already be fixed, and the issue can be closed. This would help the developers a lot in concentrating on the bugs that still exist.		[https://bugs.launchpad.net/inkscape Launchpad Bug Tracker summary]</b>. We can use help in testing bug reports, trying to reproduce them and add more information that might help solve the problem. For example, sometimes a bug might already be fixed, and the issue can be closed. This would help the developers a lot in concentrating on the bugs that still exist.

User8192: moved UpdatingTrackerItems to Updating tracker items: This is a Mediawiki wiki. Run-together words don't create wikilinks and article names are allowed to use spaces.

2011-12-13T18:32:36Z

moved UpdatingTrackerItems to Updating tracker items: This is a Mediawiki wiki. Run-together words don't create wikilinks and article names are allowed to use spaces.

← Older revision	Revision as of 18:32, 13 December 2011
(No difference)

Johanengelen: fix link to go to Launchpad

2007-11-29T20:55:35Z

fix link to go to Launchpad

← Older revision		Revision as of 20:55, 29 November 2007
Line 1:		Line 1:
	We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:		We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:
	[~~http~~://~~sourceforge~~.net/~~tracker/?group_id=93438 SF~~ Tracker summary]</b>. We can use help in testing bug reports, trying to reproduce them and add more information that might help solve the problem. For example, sometimes a bug might already be fixed, and the issue can be closed. This would help the developers a lot in concentrating on the bugs that still exist.		[https://bugs.launchpad.net/inkscape Launchpad Bug Tracker summary]</b>. We can use help in testing bug reports, trying to reproduce them and add more information that might help solve the problem. For example, sometimes a bug might already be fixed, and the issue can be closed. This would help the developers a lot in concentrating on the bugs that still exist.

	=== Updating Tracker Items ===		=== Updating Tracker Items ===

Johanengelen at 22:07, 23 October 2007

2007-10-23T22:07:39Z

← Older revision		Revision as of 22:07, 23 October 2007
Line 1:		Line 1:
	We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:		We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:
	[http://sourceforge.net/tracker/?group_id=93438 SF Tracker summary]</b>		[http://sourceforge.net/tracker/?group_id=93438 SF Tracker summary]</b>. We can use help in testing bug reports, trying to reproduce them and add more information that might help solve the problem. For example, sometimes a bug might already be fixed, and the issue can be closed. This would help the developers a lot in concentrating on the bugs that still exist.

	=== Updating Tracker Items ===		=== Updating Tracker Items ===

Johanengelen: add link to SF tracker

2007-10-23T21:33:11Z

add link to SF tracker

← Older revision		Revision as of 21:33, 23 October 2007
Line 1:		Line 1:
			We very much appreciate the feedback we get from users. <b>They usually report their findings (bugs, feature requests or patches) here:
			[http://sourceforge.net/tracker/?group_id=93438 SF Tracker summary]</b>

	=== Updating Tracker Items ===		=== Updating Tracker Items ===

AlanHorkan: /* Duplicates */

2007-02-12T17:43:19Z

Duplicates

← Older revision		Revision as of 17:43, 12 February 2007
Line 17:		Line 17:

	Always search for similar or Duplicate requests before filing new reports.		Always search for similar or Duplicate requests before filing new reports.
	When choosing which duplicate to close older reports should be given priority over newer reports. Exceptions can be made if one report has signficantly better information provided. When closing a report as a duplicate make sure to include a full hyperlink to the report being left open and ~~where~~ appropriate copy and paste across any relevant extra information.		When choosing which duplicate to close older reports should be given priority over newer reports. Exceptions can be made if one report has signficantly better information provided, and some priority should be given to non-Anonymous reports since there is a better chance of getting followup information from users. When closing a report as a duplicate make sure to include a full hyperlink to the report being left open and preferably the bug title/summary. Where appropriate copy and paste across any relevant extra information to the bug report being left open.

	[[Category:Help Wanted]]		[[Category:Help Wanted]]

AlanHorkan: /* Updating Tracker Items */

2007-02-12T17:34:30Z

Updating Tracker Items

← Older revision		Revision as of 17:34, 12 February 2007
Line 7:		Line 7:
	# Clarify. If it took you some time to guess what it's about, take another second to reword the title or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it).		# Clarify. If it took you some time to guess what it's about, take another second to reword the title or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it).
	# Document your solution. When closing a bug as fixed, add a comment about how you did it (especially what files changed and what to look for in these files).		# Document your solution. When closing a bug as fixed, add a comment about how you did it (especially what files changed and what to look for in these files).
	# Prioritization: even though SF permits 10 levels of priority per bug, there doesn't seem to be much need for more than four levels: high(9), med(6), low(3), and unprioritized(5). ~~We use~~ the ~~prioritization for~~ 'criticality' rather than ~~implementation order (which is unpredictable)~~.		# Prioritization: even though SF permits 10 levels of priority per bug, there doesn't seem to be much need for more than four levels: high(9), med(6), low(3), and unprioritized(5). There is no way to predict what features developers will want to work on so prioritization is used to indicate the importance or 'criticality' of an issue rather than when it might be implemented or even how difficult it migth be to do.

	## Crash bugs are generally always high(9), as are bugs related to file open/save problems, file corruption, loss of backup, or other things that could cause data loss for users or prevent them from being able to use the application.		## Crash bugs are generally always high(9), as are bugs related to file open/save problems, file corruption, loss of backup, or other things that could cause data loss for users or prevent them from being able to use the application.

	## Bugs which affect usability, functionality, behavior, etc. are generally medium(6), although important ones are bumped up to high and unimportant ones are dropped to low.		## Bugs which affect usability, functionality, behavior, etc. are generally medium(6), although important ones are bumped up to high and unimportant ones are dropped to low.

	## Quirks, really obscure things, and minor nit picky things would be low(3).		## Quirks, really obscure things, and minor nit picky things would be low(3).

AlanHorkan: closing duplicate reports

2007-02-12T17:30:00Z

closing duplicate reports

← Older revision		Revision as of 17:30, 12 February 2007
Line 16:		Line 16:

	:The prioritization level isn't used to indicate when the bug will be fixed. Bugs seem to get fixed whenever their time has come. That said, we do try to make an extra effort to address all the critical bugs prior to a release.		:The prioritization level isn't used to indicate when the bug will be fixed. Bugs seem to get fixed whenever their time has come. That said, we do try to make an extra effort to address all the critical bugs prior to a release.

			=== Duplicates ===

			Always search for similar or Duplicate requests before filing new reports.
			When choosing which duplicate to close older reports should be given priority over newer reports. Exceptions can be made if one report has signficantly better information provided. When closing a report as a duplicate make sure to include a full hyperlink to the report being left open and where appropriate copy and paste across any relevant extra information.

	[[Category:Help Wanted]]		[[Category:Help Wanted]]

GigaClon: Categorization

2006-06-20T19:38:56Z

Categorization

← Older revision		Revision as of 19:38, 20 June 2006
Line 9:		Line 9:
	# Prioritization: even though SF permits 10 levels of priority per bug, there doesn't seem to be much need for more than four levels: high(9), med(6), low(3), and unprioritized(5). We use the prioritization for 'criticality' rather than implementation order (which is unpredictable).		# Prioritization: even though SF permits 10 levels of priority per bug, there doesn't seem to be much need for more than four levels: high(9), med(6), low(3), and unprioritized(5). We use the prioritization for 'criticality' rather than implementation order (which is unpredictable).

	** Crash bugs are generally always high(9), as are bugs related to file open/save problems, file corruption, loss of backup, or other things that could cause data loss for users or prevent them from being able to use the application.		## Crash bugs are generally always high(9), as are bugs related to file open/save problems, file corruption, loss of backup, or other things that could cause data loss for users or prevent them from being able to use the application.

	** Bugs which affect usability, functionality, behavior, etc. are generally medium(6), although important ones are bumped up to high and unimportant ones are dropped to low.		## Bugs which affect usability, functionality, behavior, etc. are generally medium(6), although important ones are bumped up to high and unimportant ones are dropped to low.

	** Quirks, really obscure things, and minor nit picky things would be low(3).		## Quirks, really obscure things, and minor nit picky things would be low(3).

	:The prioritization level isn't used to indicate when the bug will be fixed. Bugs seem to get fixed whenever their time has come. That said, we do try to make an extra effort to address all the critical bugs prior to a release.		:The prioritization level isn't used to indicate when the bug will be fixed. Bugs seem to get fixed whenever their time has come. That said, we do try to make an extra effort to address all the critical bugs prior to a release.

			[[Category:Help Wanted]]

Conversion script: link fix

2006-01-22T02:33:51Z

link fix

← Older revision		Revision as of 02:33, 22 January 2006
Line 1:		Line 1:
	=== Updating Tracker Items ===		=== Updating Tracker Items ===

	This is the general methodology for dealing with SourceForge Bug, Feature, and Patch Tracker items:		This is the general methodology for dealing with [[SourceForge]] Bug, Feature, and Patch Tracker items:

	# Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.		# Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.