Changes

Jump to: navigation, search

Bug triage

8 bytes added, 00:37, 3 February 2016
add wikilink
* 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.
It would be beneficial to also run the master branch version of Gramps so as to test bugs that are in the master branch only.
{{man note|ALWAYS|be polite when responding to a bug ticket.}}
* For the supported projects, the bugs must be triaged: Duplicate bugs "'''<span style="background:grey">closed</span>'''", 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!).
22
edits

Navigation menu