To create a Ticket is a simple process but one that should include all available information. It is much better to add a little more information than required than to leave vital data out of the Ticket.

From Joel Spolsky, Every good bug report needs exactly three things.

1. Steps to reproduce,
2. What you expected to see, and
3. What you saw instead.

Sometimes you may not be able to reproduce the behaviour every time but by adding extra information a Developer may still see the problem. At the end of the day they’ll thank you for it and your Ticket may be closed faster.

A Ticket is comprised of a few key pieces of information. The following properties are available when you first create a Ticket,

• Ticket Title(required) - a brief summary of what this Ticket is about. e.g. “Logon form does not submit” or “Incorrect branding in marketing section”.
• Description(required) - the much more detailed description of what the problem or request is about. What you think is wrong, what you’d expect to see, perhaps some suggestions on potential resolutions.
• Project(required) - what was the product or project that you experienced the problem in? Once you have entered this a few of the other fields are populated with choices.
• Version - the version of the product or project that you are using. Sometimes the bug/request may have already been resolved in a later version of the product. If you have already selected the project then the appropriate versions should be shown to you.
• Component - where in the software did you have the problem? Was it in the messaging section or the video component, etc? This will help narrow the focus of the developer trying to resolve this bug or investigate your request.
• Type - as tickets are created for different reasons this is what defines them. If you have experienced a problem or failure in the product, then you’d probably create the ticket as a bug. Maybe you have a design suggestion or issue around security or need to assign a task to a developer?
• Severity - give the ticket a rating on how severe the problem is. Just a typo or layout issue then it’s probably fairly minor. No one can logon or the product fails completely, then it’s probably major or critical.
• Developer - if you know who should be assigned to investigate or triage this issue, select their name.

• Related - a list of related tickets to this one. Typically used to highlight similar problems or link duplicate tickets together.
• Cc - other user’s email addresses can be added to notify them of this new ticket. By default the project leader and the ticket creator will also be notified (depending on user preferences and system settings).
• Tags - to help search for tickets and group tickets together, you can add tags to categorise them. Tags become clickable links in tickets.