Bug triage - Revision history

Patsyblefebre: Gramps

2013-01-17T08:32:48Z

Gramps

Daleathan: /* How */ http://en.wikipedia.org/wiki/End-of-life_%28product%29

2011-09-30T00:00:59Z

‎How: http://en.wikipedia.org/wiki/End-of-life_%28product%29

Daleathan: /* How */

2011-06-20T13:01:07Z

‎How

Daleathan at 12:56, 20 June 2011

2011-06-20T12:56:12Z

Daleathan at 12:53, 20 June 2011

2011-06-20T12:53:32Z

Daleathan: /* How */

2011-06-20T10:37:36Z

‎How

Daleathan at 10:36, 20 June 2011

2011-06-20T10:36:11Z

Daleathan at 10:31, 20 June 2011

2011-06-20T10:31:15Z

Daleathan: based on gramps dev list discusions and various website / benny's request:Perhaps we can combine this with a wiki page?

2011-06-20T10:30:27Z

based on gramps dev list discusions and various website / benny's request:Perhaps we can combine this with a wiki page?

New page

How can I help the GRAMPS project with bug triage?

==Goals of Bug Triage==
===What===

The goal of bug triage is to make it easier for developers to do development by organizing the bug list for them. This means the developers are able to spend less time asking bug reporters what the problem is, confirming if it is still an issue in the latest GRAMPS trunk in SVN.

Bug triage includes the reduction of open tickets, removal of stale/out of date tickets, and grouping of feature requests.

===How===

Make sure you're using the latest release of GRAMPS, using trunk SVN is usually best. From a clean install of GRAMPS attempt to reproduce the bug that is being reported. If you cannot reproduce the bug, post a comment as such - explaining the steps you took to reproduce the bug. If you encounter a different bug, file a new bug report for that problem if one has not been filed already.

0. Make sure you have GRAMPS installed so you can test bugs and problems. Create a family tree and import the example.gramps file.
It would be beneficial to also run the trunk version of GRAMPS so as to test bugs that are in trunk only.

1. Read a bit the documentation of mantisbt so you know what is possible, [http://www.mantisbt.org/documentation.php mantisbt documentation]

2. At the moment only project gramps 3.4 and gramps trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
* resolved in the meantime
* does not apply anymore
* version no longer supported, try with new version
* bug/problem still present, move the bug to the correct project eg it is a feature request
* too little information given, feedback wanted from reporter
* several issues in one bug, close it asking users to submit a ticket per issue (or rename the bug for one issue, and ask to create new ones for the other)
* other issues...

;ALWAYS be polite when responding to a bug ticket.

3. For the supported projects, the bugs must be triaged: Duplicate bugs closed, set a better bug title so it is more clear for a developer what the bug is about, add extra information. Most important here is to try to duplicate the bug with the example.gramps file, as that is what the developer will spend a lot of time trying to do. Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage. Once a developer sees a bug in front of him, fixing it is often fast.

5. Then there is the feature request project. These must be organised somehow. It is best you look at some of those tickets and make a suggestion on how to organize it so that the feature requests remain useful. Also giving better titles is important here, closing duplicates. Don't be afraid to close something saying users must give a better worked out request (but be polite!).

===MantisBT permissions==

If you don't have MantisBT permissions (the ability to change bugs' status from Unconfirmed to New, Fixed, or Invalid), then feel free to ask on the Gramps-dev List for someone to set the status for you (eg: "Could someone set bug #1 to invalid please?) Once you do this enough, feel free to ask for MantisBT permissions.

[[Category:Quality Assurance]]

@@ Line 1: / Line 1: @@
-Help the GRAMPS project with bug triaging.
+Help the Gramps project with bug triaging.
 ==Goals of Bug Triage==
 ==What==
-The goal of bug triage is to make it easier for developers to do development by organizing the bug list for them. This means the developers are able to spend less time asking bug reporters what the problem is, confirming if it is still an issue in the latest GRAMPS trunk in SVN.
+The goal of bug triage is to make it easier for developers to do development by organizing the bug list for them. This means the developers are able to spend less time asking bug reporters what the problem is, confirming if it is still an issue in the latest Gramps trunk in SVN.
 Bug triage includes the reduction of open tickets, removal of stale/out of date tickets, and grouping of feature requests.
@@ Line 10: / Line 10: @@
 ==How==
-Make sure you're using the latest release of GRAMPS, using trunk SVN is usually best. From a clean install of GRAMPS attempt to reproduce the bug that is being reported. If you cannot reproduce the bug, post a comment as such - explaining the steps you took to reproduce the bug. If you encounter a different bug, file a new bug report for that problem if one has not been filed already.
+Make sure you're using the latest release of Gramps, using trunk SVN is usually best. From a clean install of Gramps attempt to reproduce the bug that is being reported. If you cannot reproduce the bug, post a comment as such - explaining the steps you took to reproduce the bug. If you encounter a different bug, file a new bug report for that problem if one has not been filed already.
 * Read a bit of the [http://www.mantisbt.org/documentation.php documentation of mantisbt] so you know what is possible.
-* Make sure you have GRAMPS installed so you can test bugs and problems. Create a family tree and import the example.gramps file.
+* Make sure you have Gramps installed so you can test bugs and problems. Create a family tree and import the example.gramps file.
-It would be beneficial to also run the trunk version of GRAMPS so as to test bugs that are in trunk only.
+It would be beneficial to also run the trunk version of Gramps so as to test bugs that are in trunk only.
-* At the moment only project GRAMPS 3.4 and GRAMPS trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
+* At the moment only project Gramps 3.4 and Gramps trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
 ** resolved in the meantime
 ** does not apply anymore

@@ Line 20: / Line 20: @@
 ** resolved in the meantime
 ** does not apply anymore
-** version no longer supported (EOL versions), try with new version
+** version no longer supported ([http://en.wikipedia.org/wiki/End-of-life_%28product%29 EOL] versions), try with new version
 ** bug/problem still present, move the bug to the correct project eg it is a feature request
 ** too little information given, feedback wanted from reporter

@@ Line 20: / Line 20: @@
 ** resolved in the meantime
 ** does not apply anymore
-** version no longer supported, try with new version
+** version no longer supported (EOL versions), try with new version
 ** bug/problem still present, move the bug to the correct project eg it is a feature request
 ** too little information given, feedback wanted from reporter

@@ Line 1: / Line 1: @@
 Help the GRAMPS project with bug triaging.
@@ Line 19: / Line 17: @@
 It would be beneficial to also run the trunk version of GRAMPS so as to test bugs that are in trunk only.
-* At the moment only project gramps 3.4 and gramps trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
+* At the moment only project GRAMPS 3.4 and GRAMPS trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
 ** resolved in the meantime
 ** does not apply anymore

← Older revision		Revision as of 10:36, 20 June 2011
Line 39:		Line 39:


−	[[Category:Quality Assurance]]	+	[[Category:Developers/Quality Assurance]]
		+	[[Category:Developers/General]]

@@ Line 17: / Line 17: @@
 It would be beneficial to also run the trunk version of GRAMPS so as to test bugs that are in trunk only.
-. Read a bit the documentation of mantisbt so you know what is possible, [http://www.mantisbt.org/documentation.php mantisbt documentation]
+. Read a bit the [http://www.mantisbt.org/documentation.php documentation of mantisbt] so you know what is possible.
 . At the moment only project gramps 3.4 and gramps trunk are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
- * resolved in the meantime
+* resolved in the meantime
- * does not apply anymore
+* does not apply anymore
- * version no longer supported, try with new version
+* version no longer supported, try with new version
- * bug/problem still present, move the bug to the correct project eg it is a feature request
+* bug/problem still present, move the bug to the correct project eg it is a feature request
- * too little information given, feedback wanted from reporter
+* too little information given, feedback wanted from reporter
- * several issues in one bug, close it asking users to submit a ticket per issue (or rename the bug for one issue, and ask to create new ones for the other)
+* several issues in one bug, close it asking users to submit a ticket per issue (or rename the bug for one issue, and ask to create new ones for the other)
- * other issues...
+* other issues...
 ;ALWAYS be polite when responding to a bug ticket.
@@ Line 32: / Line 32: @@
 . For the supported projects, the bugs must be triaged: Duplicate bugs closed, set a better bug title so it is more clear for a developer what the bug is about, add extra information. Most important here is to try to duplicate the bug with the example.gramps file, as that is what the developer will spend a lot of time trying to do. Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage. Once a developer sees a bug in front of him, fixing it is often fast.
 . Then there is the feature request project. These must be organised somehow. It is best you look at some of those tickets and make a suggestion on how to organize it so that the feature requests remain useful. Also giving better titles is important here, closing duplicates. Don't be afraid to close something saying users must give a better worked out request (but be polite!).
 ===MantisBT permissions===