Edit Issue

On this page one can create and modify issues. The form elements are explained below. The entries marked red are the ones that can be filtered on using the report facilities.

Form Block I

Issue No.

The issue no. is the unique reference of an issue throughout the system. It is automatically assigned when a new issue is created.

Created

The date and time when the issue was originally created

Originator

The name of the person that created or originally authored the issue ($ORIGINATOR)

Project

The project name. This is a dropdown box of projects the user has been allowed to access. If it is empty, or a project is missing one has to talk to the respective project or system administrator to get permission. Initially, after first registration this box is usually empty. Projects have to be set up by the Track+ system administrator

Subsystem

A project can be subdivided into many subsystems. This dropdown box depends therefore on the project selected in the project list. Subsystems can be set up by the project administrator.

Release

Each project can have different releases. A release may be commonly thought of as a published version of a system. Releases can be defined by the project administrator.

Build

The build or version is a free format string with up to 25 characters and can be used to further differentiate parts of a release. This string can be defined by anyone. There is the possibility to set a text search filter on this field that works on ASCII text.

Class

Class defines the type of issue. Examples could be {software, hardware, ASICs, housing}. Classes are defined by the project administrator for the repsective projects.

Manager

The name of the person that accompanies the issue throughout its lifecycle and that is responsible to get it closed ($MANAGER). The $MANAGER usually isn't changed very often.

Responsible

The person that is currently assigned to work on this issue. This may change throughout the lifecycle of the issue. For example, once a feature has been implemented, the $RESPONSIBLE could change to a person that would integrate the feature with other parts of the system, and thereafter it could be assigned to a person for testing. Since each change in an Email message to the newly assigned $RESPONSIBLE, she automatically is informed of her new assignement. The $MANAGER is informed as well and knows who is currently working on a particular issue.

Form Block II

Synopsis

A free format text field with up to 80 characters for the issue synopsis. There is the possibility to set a text search filter on this field that works on ASCII text.

Description

A free format text field with up to 32000 characters (depends on database) for an elaborate description of the issue. Only line breaks are preserved as formatting elements.There is the possibility to set a text search filter on this field that works on ASCII text. Additional tags are available:

[issue #/] - create a hyperlink to another issue

[u] [/u] - underline enclosed text

[b] [/b] - print enclosed text in boldface

[i] [/i] - orint enclosed text in italic form

Form Block III

List

The basic idea of the Track+ system is the managing of (semi-) public lists. The category defines what type of list this is, e.g. problem reports, feature requests, action items. Categories can be set up by the system administrator only for all projects in common. There is a recommendation on some list types available.

Priority

The priority defines how soon an action is needed.

Severity

The severity defines how critical an issue is with regard to its implications on the project or products.

Form Block IV

This block is concerned with the state of an issue. States can be categorized into two classes: open and closed. Most states belong to the open category; the default configuration sets only state closed and suspended to category "closed". This allows for easy queries such as: "give me all open issues", meaning all those that are not in states closed or suspended. In the Track+ application the states can be easily configured and customized. The following describes the default configuration.

There are nine different states defined an issue can be in (the state category is shown in brackets):

initial

the initial state of every issue if no other state is assigned. This means the issue has been filed. This state is optional and may be superceded by open [open]

opened

this means the issue has been filed and the person or group responsible for it has been notified [open]

analyzed

the issue has been examined and it has been evaluated whether a solution has to be pursued. Useful for problem reports and change requests [open]

assigned

the issue has been assigned to a $EXECUTOR [open]

processing

the issue is being processed by the $EXECUTOR [open]

implemented

the solution has been implemented and is ready for integration by $INTEGRATOR or $TESTER [open]

assessed

a solution has been found and assessed (tested) at the support site, and sent to the party who reported the problem; that party is validating the solution [open]

closed

the solution has been confirmed by the party which reported it, or the $TESTER [closed]

suspended

in some cases, it may be necessary to suspend work on an issue; in this case, its state changes to suspended rather than closed [closed]

Figure 1: Valid State Transitions

Currently there is no enforcement of valid state transitions as this has shown to be not too helpful. All important state transitions (e.g. from an open state to a closed or suspended state) are being e-mailed to the people concerned anyway. Thus the risk of loosing an issue is rather small.

Last state change

The date of the last state change

By

The name of the person that performed the last state change

State

The name of state the issue is currently in

New state

The new state of the issue

Comment

A free format text field for comments on the state change

Form Block V

Begin date

The date when work is scheduled to begin for this issue

Date due

The date when this issue is scheduled to be closed. Issues that have values entered into this field will be marked as overdue in the reports if they are not closed prior to the due date. A change of this date is recorded in the audit trail of the issue.

Issue No.	The issue no. is the unique reference of an issue throughout the system. It is automatically assigned when a new issue is created.
Created	The date and time when the issue was originally created
Originator	The name of the person that created or originally authored the issue ($ORIGINATOR)
Project	The project name. This is a dropdown box of projects the user has been allowed to access. If it is empty, or a project is missing one has to talk to the respective project or system administrator to get permission. Initially, after first registration this box is usually empty. Projects have to be set up by the Track+ system administrator
Subsystem	A project can be subdivided into many subsystems. This dropdown box depends therefore on the project selected in the project list. Subsystems can be set up by the project administrator.
Release	Each project can have different releases. A release may be commonly thought of as a published version of a system. Releases can be defined by the project administrator.
Build	The build or version is a free format string with up to 25 characters and can be used to further differentiate parts of a release. This string can be defined by anyone. There is the possibility to set a text search filter on this field that works on ASCII text.
Class	Class defines the type of issue. Examples could be {software, hardware, ASICs, housing}. Classes are defined by the project administrator for the repsective projects.
Manager	The name of the person that accompanies the issue throughout its lifecycle and that is responsible to get it closed ($MANAGER). The $MANAGER usually isn't changed very often.
Responsible	The person that is currently assigned to work on this issue. This may change throughout the lifecycle of the issue. For example, once a feature has been implemented, the $RESPONSIBLE could change to a person that would integrate the feature with other parts of the system, and thereafter it could be assigned to a person for testing. Since each change in an Email message to the newly assigned $RESPONSIBLE, she automatically is informed of her new assignement. The $MANAGER is informed as well and knows who is currently working on a particular issue.

List	The basic idea of the Track+ system is the managing of (semi-) public lists. The category defines what type of list this is, e.g. problem reports, feature requests, action items. Categories can be set up by the system administrator only for all projects in common. There is a recommendation on some list types available.
Priority	The priority defines how soon an action is needed.
Severity	The severity defines how critical an issue is with regard to its implications on the project or products.

initial	the initial state of every issue if no other state is assigned. This means the issue has been filed. This state is optional and may be superceded by open [open]
opened	this means the issue has been filed and the person or group responsible for it has been notified [open]
analyzed	the issue has been examined and it has been evaluated whether a solution has to be pursued. Useful for problem reports and change requests [open]
assigned	the issue has been assigned to a $EXECUTOR [open]
processing	the issue is being processed by the $EXECUTOR [open]
implemented	the solution has been implemented and is ready for integration by $INTEGRATOR or $TESTER [open]
assessed	a solution has been found and assessed (tested) at the support site, and sent to the party who reported the problem; that party is validating the solution [open]
closed	the solution has been confirmed by the party which reported it, or the $TESTER [closed]
suspended	in some cases, it may be necessary to suspend work on an issue; in this case, its state changes to suspended rather than closed [closed]

Last state change	The date of the last state change
By	The name of the person that performed the last state change
State	The name of state the issue is currently in
New state	The new state of the issue
Comment	A free format text field for comments on the state change

Begin date	The date when work is scheduled to begin for this issue
Date due	The date when this issue is scheduled to be closed. Issues that have values entered into this field will be marked as overdue in the reports if they are not closed prior to the due date. A change of this date is recorded in the audit trail of the issue.