How to verify a bug exists:

• The first step when reviewing a bug ticket is to verify that the bug does actually exist
• To verify if the bug exists, create a simple test using the latest code from the master branch
• If the bug is not reproducible in master, run the test against the tag matching the version listed in the ticket
• If the bug is not reproducible in either version, the ticket should be closed as worksforme
• If the bug is reproducible in the reported version, but not from HEAD, it should be closed as fixed. If you can track down the specific commit that fixed the bug, you should leave a comment in the ticket when closing it.  However, if you can't track it down, it is okay to just close the ticket with a note that says this has already been fixed.

How to log a new issue:

In order to create new issues, you need to first register a Trac account.

When creating a ticket in Trac, you must fill in the summary, description, type, component and version.

• The description should provide enough detail to clearly explain the problem and steps to reproduce the behavior.
• You may fill in additional keywords to help others find the ticket
• You may add yourself to the cc list if you would like to be notified when the ticket is updated.
• The development leads are responsible for triaging issues and setting the priority and milestone.
• The assign to field should never be set by the reporter unless they are explicitly told to do so.
• By default, members do not have the rights to edit tickets so if you make a mistake when creating a ticket, you will need to enter corrections as a comment to the ticket.
• Tickets should have a descriptive summary and description.

Keep in mind that when viewing a list of tickets the summary will be the only field that provides insight into what the ticket deals with.  If the issue was originally mentioned in a thread, the ticket should contain a link to the thread so it can be referenced later.