-
Notifications
You must be signed in to change notification settings - Fork 1
Ticket Workflow
This page defines how the Github ticket labels work together and fit into an overall workflow.
When creating a new ticket, one of the following labels should be applied to distinguish the source and purpose of the ticket:
- bug
-
Used to indicate that the ticket represents a misbehavior of the ANMS or the inability to achieve a specific goal that is a system requirement. Any behavior that results in loss of user-input data, including lack of user acknowledgement, can be considered a bug. A behavior which is unexpected but correct is considered an enhancement.
- enhancement
-
Used to indicate that the ticket represents a desired improvement of the ANMS, or a behavior which violates the Principle of least surprise and is confusing.
- sustainment
-
Used to indicate that the ticket represents a sustainment activity, such as updating external library versions or operating system base images. These are different than
enhancementtickets because they are typically related to infrastructure and not user-visible changes. - documentation
-
Used to indicate that the ticket represents a deviation of actual behavior from internally-documented behavior. This applies to software source comments only, issues in the ANMS Product Guide or User Guide are managed in a separate repository anms-docs.
Once a ticket has been added, it must be examined and have triage labels applied to it to enable later filtering. Different labels are used for different triage and filtering aspects, as described below.
The severity labels are taken from the NASA MGSS Implementation and Maintenance Task Requirements (MIMTaR) document with names and detailed definitions as follows:
- CRIT-1 Critical
-
Defect makes the software unusable for mission operations.
- CRIT-2 Major
-
Defect has significant impact on usability of delivered software for mission operations. User experience is difficult and/or cumbersome. Workaround available is arduous.
- CRIT-3 Moderate
-
Defect has moderate to mild impact on usability of delivered software for mission operations. User experience is degraded but workable.
- CRIT-4 Minor
-
Defect means software does not work as originally intended, but the defect has little impact on the usability of the delivered software.
For tickets which are not assigned to a release milestone, or when tickets need additional reporter feedback, the following labels can be applied:
- question
-
Used to indicate that the reporter needs to answer a question in the ticket comment before more work can be done on the issue.
- help wanted
-
Used to indicate that the developer attention is needed to analyze some detail in the ticket before more work can be done on the issue.
One of the following labels are applied when the ticket is closed:
- duplicate
-
This means the ticket is reporting an identical behavior or misbehavior to another ticket. Higher-numbered tickets are always the duplicate of the lower-numbered original ticket. The original ticket is linked-to for reference in a comment on the duplicate.
- invalid
-
This means that the reported misbehavior was not due to a software problem, but possibly an environmental or configuration issue.
- wontfix
-
This means that the reported misbehavior is a valid bug, but that a decision has been made to not address the issue. The ticket may be reopened at a later time or left closed.
The following other fields of a ticket indicate how it is progressing through the workflow.
Separate from labels on a ticket, there is a single milestone field which can be used to assign a ticket to a specific planned release milestone. When a ticket is assigned to a milestone, that means that work is expected to be done for that issue to be resolved for that release. Snapshots of milestone assignments are made in release plans at the start of each development cycle and used as a baseline for what changes will be in that release. Each release plan is documented as a separate wiki paged named similar to "ANMSv1.1 Release Plan".
Once a ticket has been accepted into a milestone, a developer is assigned to the ticket to make changes. Any ticket assigned to a milestone but without an assignee is in the backlog for that milestone. After adding assignees and work begins, the project status will change to "In Progress" and the assignee is the person currently working the ticket.
All of the tickets in the ANMS are marked for the ANMS Project to allow status views on the work. When tickets are first added to a milestone, their status begins as "Todo". Once work begins on the ticket its status changes to "In Progress". Finally, when work is completed (but not necessarily verified) its status changes to "Done".
Testing activities at the tail end of a release cycle can be used to add comments about the verification of a ticket and may move the status back to "Todo" if more work is needed.