{{languages|How to report bugsUsing the bug tracker}}{{man tip|The bug/issue tracker for Gramps |is located at the following URL: <code>https://www.gramps-project.org/bugs</code>}}

When composing a problem (bug) report for Gramps:* Be '''''precise'''''* Be '''''clear''': '' explain how to reproduce the problem, step by step, so others can reproduce the bug, or understand the request.* Include only '''''one problem per report'''''* Include any relevant links and '''''examples''''' {{man tip|Before you create a "Bug" report...|Composing a bug report can involve a lot of research and writing effort. Save yourself from unnecessary work. * A solution or workaround might already exist in another bug report or in the forums.* If you cannot find anything resembling your issue, ask about it in one of the forums. The community will help you solve or isolate the problem.* If using an [[Previous_releases_of_Gramps|older Gramps version]], please mention that you have also tested with the current Gramps {{version}} version and that the issue is present.}}

To report a bug or raise a feature request, you must have a login account on the '''Gramps bug tracker''' ''([https://www.mantisbt.org/ powered by MantisBT])'':* [https://bugs.gramps-project.org {{man button|Login}} ] to your account at https://gramps-project.org/bugs/login_page.php , or;* Select [https://gramps-project.org/bugs/signup_page.php {{man button|Signup for a new account}} ] or visit the following link to create a new login account: https://gramps-project.org/bugs/signup_page.php . When you create a user account Due to periodic SPAMbot activity, remember New Account requests might require human pre-approval. Be aware that this means that it can might take up to 12 hours before a notification confirmation email is send to yousent when creating a user account. Only after clicking on the link in the confirmation email can you submit bugs. Your email address will be handled confidentially.

===2. Search wiki and existing bugs===

Perhaps Sometimes the behavior being observed might seem odd, yet as-designed. So the first step is to search the wiki to see what the documented behavior is. If you're still not sure, ask the [https://forum.gramps-project.org/ Gramps community on Discourse.] If it still appears to be a bug, perhaps the bug you want to report has been submitted reported before. To check this, click on [https://gramps-project.org/bugs/view_all_bug_page.php {{man button|View Issues}}]. The top of the page is reserved for filters, which you set. Normally the default filters are just fine. Under these filters, there is a {{man label|Search}} box. Enter the terms best describing the bug, and click {{man button|Apply Filter}} to search. If you have an error message, try pasting a part of the error, to see if it is has been reported already.

**If the issue represents a problem with functionality that has been released in a stable release of codeor a problem with functionality that only exists in the master branch, then the issue should be filed under the project that corresponds to the maintenance branch for that release. For example, a bug found in Gramps 5.1.0 should be filed under the '''Gramps 5.1.0''' project.

*If the issue represents a problem with functionality that only exists in the master branchFor bug reports and feature requests relating to Gramps Web, or the problem exists in the master branch, but not any stable releases, then the issue should be filed under the '''see [https://www.grampsweb.org/help/ | Get Help - Gramps Master''' project.Web]

[[File:Enter Issue Details page Gramps bugs.png|thumb|right|450px550px|Enter Issue Details - page]]

Try and complete all the relevant sections as well as you can and be prepared to answer follow up questions if your report needs clarification. Here's a concise guide on '''[[How to create a good bug report]]''' for Gramps which will greatly increase the chances of reproducibility and thus being fixed.

**The For recording issues that '''Gramps Master'only'' project should only be used by developers and testers of the latest code. It is a place for recording issues that only apply to the master branch in Git (see [[Brief_introduction_to_Git#Types_of_branches|Types of Branches]]), use next un-released version e.g. There is only one "Gramps Master" : 6.1.0 as shown on the [https://gramps-project because there is only one master branch .org/bugs/roadmap_page.php| MantisBT Roadmap].* Addon Version** If you are reporting a bug in an third-party addon, use the [[Gramps_{{man version}}_Wiki_Manual_-_Navigation#Using_the_Addon_Manager...|'''Addon Manager''']] or [[Gramps_{{man version}}_Wiki_Manual_-_Plugin_Manager|'''Plugin Manager''']] (or even the [[Addon:Plugin Manager|Enhanced Plugin Manager - addon]]) to find the version of the addon and include it in the Git repositoryreport.

== Resolving bugs Useful MantisBT bug tracker Syntax codes==This information is for the developers following up on the submitted issues.

The [https://gramps-project.org/bugs/roadmap_page.php roadmap page] of the bug tracker lists the bugs currently prioritized for the next releases. If you following are looking for a bug to fix, this is a good place to start. Placement on the roadmap is controlled by the "Target Version" field fo the bug. Special "X.Y.99" phony releases, such as "3.4.99" and "4.0.99", list bugs that we would eventually like to fix for the "X.Y" version, but don't really know the milestone yet. Bugs that really should hold up a releaseshould be on the roadmap with a real release number, and should only be moved after giving a reason or heads up on the devel list [http://sourceforge.net/mailarchive/message.php?msg_id=31870820]. If you fix a bug scheduled for a latermilestone before a previous one is out, '''please manually adjust the target release field before marking the bug resolved,''' otherwise the roadmap display will be inaccurate [http://sourceforge.net/mailarchive/message.php?msg_id=31870821]. In general, when resolving an issue, it is always a good idea to add a note with the hash of the commit that fixed the problem. When resolving issues in a maintenance branch, one should always set the "Fixed in version" field to the version of the next release that will be made from that branch. This is done so that the issue properly appears in the ChangeLog page for that project ( https://gramps-project.org/bugs/changelog_page.php ). Bugs in maintenance branch projects should not be marked as closed until the developer has committed the change into the corresponding maintenance branch. Additionally, it is the developers responsibility to make sure the change has been merged into the master branch. ==Bug triage== Help the Gramps project [[Bug triage]]. ==Syntax== useful [http://www.mantisbt.org/ Mantis MantisBT bug tracker] uses its own syntax code codes you can use:* Using ''<code>#</code>'' before a bug number writes a link to the bug. eg: ''<code>#1</code>'' becomes {{bug|1}}* Use ''<code>@</code>'' before a user name to mention a person(note: user names with embedded spaces are not supported)* Using ''<code>~</code>'' before a comment number writes a link to the comment, same as : ''<code>{url}#c{comment number}</code>''. eg: ''<code>~3</code>'' becomes [https://gramps-project.org/bugs/view.php?id=1#c3]* To link a GitHub Pull Request in the bug tracker, use ''<code>p:gramps:nnnn:</code>'' where ''<code>nnnn</code>'' is the PR number. (This only applies to the main gramps repository, not add-ons.)* To link a GitHub Pull Request in the bug tracker, for Gramps addons-source paste the full Github link.=== Limited HTML tags ===