Overview

We use a self-hosted instance of Atlassian JIRA to track all kinds of project-related issues.

The different issue types are defined as follows:

• Bug: A defect in the GMAT application
• Improvement: An enhancement to an existing feature
• New Feature: A brand-new feature that doesn't already 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

Best Practices

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

• If it is not a software defect, don't classify it as a Bug.   See the above list for classifications. Classify work on docs, infrastructure, etc. as Task.
•   If you find similar or related issues, please do not check in many small issues, use a single issue.  Here is an example, suppose the following two disallowed lines are not being caught, Sat.ECC = 1 or Sat.ECC = -3. Please put these items in a single ticket.  These are not separate tickets.
•   If separate items  are closely related and are really a To Do list in a common work area, use a single ticket.
•   Provide a complete bulletted list of instructions to duplicate the issue and attach scripts and data files when necessary.

Workflow

Each issue type can have its own custom workflow. Currently we have two operational workflows:

Bug

When a bug is opened, it starts in the Openstate.

1. Open Here the bug gets triaged and assigned to the person who will fix it. The assignee changes the state to In Progress.
2. In Progress The assignee works on the bug, makes comments as appropriate, and tracks time using the Time Tracking feature. When finished, the assignee marks the bug as Resolved. If the Resolution is Fixed or Cannot Reproduce, the assignee assigns it to the reporter or Default, whichever is more appropriate. The Default assignee is the feature lead. If the Resolution is anything else, the assignee immediately marks the bug as Closed.
3. Resolved At this point the bug has been fixed, but needs to be verified independently. The assignee should either verify the fix, or assign it to another someone else for verification. When the fix has been verified, the assignee marks the bug as Verified.
4. Verified If more work needs to be done (such as regression testing or documentation), it should be assigned to the appropriate person, and discussion should happen in the comments section. When all extra work is done, the bug should be marked as Closed.
5. Closed All work is done on this bug.

Other issue types

The workflow for the other issue types (New Feature, Task, and Improvement) are identical to the Bug workflow, except they don't have the Verified step. When the assignee resolves the bug, he or she should immediately mark it as Closed.

Triage

Steve is working on a plan for this.