Skip to content
Zarina edited this page Sep 22, 2015 · 4 revisions

All tickets in the PMT are called items. An item can be either an action item or a bug.

An action item is a task assigned to a personnel. The task is often a new task.

A bug is simply a problem with a product. This can range from an broken code or functionality, a typo, or something that just doesn't work the way it is supposed to.

Life cycles

  • When a item is assigned to a designated user, that item is associated with a milestone, and given the OPEN status.
  • Optionally, the item may be marked as INPROGRESS, signifying that the item is currently being worked on but has not been completed yet.
  • When the user fixes the bug, completes the action item, or otherwise deals with the item, user then sets the status to RESOLVED with a resolved-status of FIXED, INVALID, WONTFIX, DUPLICATE, or WORKSFORME. Please read Statuses of PMT items for the definitions of each status.
  • After the item is resolved, it is passed back to the owner who checks to see if the item has been satisfactorily resolved. If it is now fixed or completed, the owner sets the status to VERIFIED. Otherwise, the owner reopens the item by setting the status to REOPENED, providing a brief explanation of why it is being reopened, and, if necessary, reassigns the item to another user.
  • Whenever the status of an item is changed, its milestone is re-evaluated. If it no longer has any open items, the milestone will become CLOSED.
  • Whenever the status of an item is reopened, the milestone will also be reopened.

Add an Action Item

You can add either an action item or a bug from the project's page.

  • Title: The title of the action item. Should be concise and meaningful.

  • Milestone: The milestone to which the item is assigned. The default is the upcoming milestone. An item can be moved to a different milestone later. The end date of the associated milestone is the default target date for the action item unless a different date is specified.

  • Owner: The user who entered the item (usually) and who is responsible for verifying the item once it has been marked as resolved. The selection of owner is available when you create action items. The ownership of a bug and action item can be changed later.

  • Assigned To: The user responsible for the item. This user is expected to resolve the item, either by fixing the bug, completing the action item, or resolving with some other appropriate conditional such as "WONTFIX", "DUPLICATE", "INVALID", etc.

  • Priority: The urgency with which the item must be handled. The priorities are 'CRITICAL', 'HIGH', 'MEDIUM', 'LOW', and 'ICING'. 'CRITICAL' items should be very rare. These items are total emergencies and should be handled immediately. 'HIGH' is something unusually important; for example, if a bug is preventing students from accessing an application which they need access to to complete a homework assignment. 'MEDIUM' is slightly lower but still quite important; such as something that has to get done quickly to keep the development on schedule. 'LOW' is the default priority and should be used for anything that is 'normal', that is, for items which fit into the development schedule but definitely need to get done. 'ICING' is for items that would be nice to have if development gets ahead of schedule. This is useful for possible future items and wishlist features.

  • Target Date: The date by which the item should be completed. If this date isn't specified when the item is created, it is inherited from the milestone that it is assigned to.

  • Time Estimate: The amount of time it will take to complete an item. Ideally, this should be discussed and agreed upon before the action item is entered. However, this often doesn't happen, so the estimated time can be edited after the item is added. This field is available when you create action items. The time estimate for both bug and action item can be changed later.

  • Tags: A fairly free-form way of classifying and grouping items. Any item can have zero or more tags associated with it. A user can filter the list of items in a project by tags.

  • Description: A clear description of the bug or action item. For a bug report, it should cover steps for the developer to reproduce the bug and include any relevant information such as platform or release version. This field supports Markdown and simple HTML for formatting. For Markdown formatting, please see the Markdown syntax cheat sheet for syntax rules.

Time formatting

Adapted from [https://github.com/thraxil/simpleduration Github simpleduration] syntax details for time formatting.

Enter time with appropriate required unit. For example:
30hrs 59min

This field is case insensitive, and white space or punctuation are ignored.

Acceptable unit abbreviations are as follows:

  • d
  • day
  • days
  • h
  • hr
  • hrs
  • hour
  • hours
  • m
  • min
  • mins
  • minute
  • minutes
  • s
  • sec
  • secs
  • second
  • seconds