Ticket Writing Best Practices

We are a very small development team, please help us manage bugs and issues, and in turn help you:

  • Only check in a ticket if it meets the guidelines for when and when not to create a ticket.
  • Always search first to see if a ticket already captures this issue.
  • Add as much detail as possible including a detailed set of instructions for reproducing issues.
  • Double check to make sure that the information you are including is public
  • Attach public scripts and data files required to duplicate the issue
  • If you have small related issues in specific area, please do not check in many small tickets, use a single issue. 
  • If items are really a minor To Do list in a common work area, use a single ticket or Idea Page, or manage them outside of the ticket system.

Submitting a Ticket

Note:  CCB sees all tickets classified as bugs.  For CCB to see a Task, Improvement, or New Feature request, you must use the Label "CCB".

1. Getting Started

Go to http://bugs.gmatcentral.org and log into JIRA using your GMAT account or create an account if you don’t already have one.

2. Search First

Always search JIRA first, to see if your issue has already been reported. (JIRA provides a powerful issue search facility. You can search for issues across projects, versions, and components, using a range of search criteria. For more details, refer to the JIRA Document: Searching for Issues.

3. Create an Issue 

Click Create Issue at the top of the screen to choose Project and Issue Type

  • Project. A JIRA project is a collection of issues, and, in most cases, it represents a software development project in GMAT.
  • Issue Type. Issue type is used to track different types of issues. For example, an issue could represent a software bug or a project task.  Here is how to select the issue type:
    • Bug: A defect in a release version of the GMAT application.  If it is a defect in a feature under development, document the issue on the feature ticket.
    • Improvement: An enhancement to an existing feature.
    • New Feature: A brand-new feature that doesn't currently exist
    • Task: A project-related task that needs to be done (i.e. an action item or a testing task), or a defect in non-software components

4. Add as Many Details as Possible

Fill in detailed information of your issue in Enter the details of the issue screen.

After your select Project and proper Issue Type, click Create.   Enter the details of the issue filling in detailed information of your issue.  Fields with a red asterisk (*) are required and cannot be left as blank.

  • Summary. A brief summary of the issue.  This appears in ticket role up lists.
  • Component/s.  A high level breakdown of modules and components.
  • Affects Version/s. The version(s) of the software that the issue is detected or applies for.
  • Environment. Platform and information on HW environment and SW environment, such as the device name and configuration, the build name, package version, etc.
  • Description. A detailed description of the bug or idea. For bugs, the description section must include detailed steps to reproduce, as well as the bug's impact to users.  For a feature change, the description section must document at a high level the new feature request.
  • Attachment.  Script files, comparison data etc. that are publicly releasable and help people understand or resolve the issue.
  • Labels. Labeling allows you to categorize an issue(s) in a more informal way than assigning it to a version or component. People could create a new label by editing in the label field, or reuse labels created by others by selecting from the drop-down list.  To send to CCB, use “CCB”, must be upper case.

Fill in the fields displayed in your issue reporting page with proper information, and click Create button at the bottom of the Enter the details of the issue screen. Congratulations, you are done reporting your bug!

Reference: Some of the text was taken straight from the approach used by Tizen.

  • No labels