The Issue sensor data type is designed for representation of data concerning issues managed by an Issue Management System such as Jira or Bugzilla.
The Issue sensor data type is designed for use in collecting "snapshots" of an issue repository on a regular basis. In other words, once a day (or week, or month), the Issue sensor for a particular Issue Management System (such as Jira) runs and collects a snapshot of the state of the repository (typically with respect to a single Project). This snapshot includes a sensor data entry for each "interesting" issue in the repository related to this project. (If the total number of issues for a project is small, then sensor data on all issues related to the project might be deemed "interesting" and included in each snapshot. If the number of issues for a project is large, then perhaps only open and/or recently closed issues might be deemed "interesting" and included in the snapshot.)
Each issue data sensor data entry is sent to the Hackystat user who "owns" it. The property of ownership is typically interpreted as the user who is assigned to work on the issue (as opposed to the user who reported the issue). In most Issue Management Systems, it is possible to have issues that are not assigned to anyone. In this case, the Issue sensor tool has a choice: it can either not send sensor data on those issues at all (i.e. until the issue is assigned to someone, it is not of interest to analysis) or declare a user to be the "default" owner of issues that are not assigned to anyone yet.
Table 25.14, “Issue SDT attributes” documents the Issue SDT attributes.
Table 25.14. Issue SDT attributes
| Attribute | Description |
|---|---|
| tstamp | The UTC time at which this data was collected. |
| tool | A string indicating the tool that collected this data, such as "Jira". |
| id | The ID associated with this issue. |
| type | The type of issue (Task, Risk, Defect, etc.) |
| paths | The paths associated with this issue. |
| status | The current status of the issue (Open, Resolved, Closed, etc.) |
In addition to the above required fields for all Issue data, there are a number of "optional but common" attributes that can appear on the property map. These are documented in Table 25.15, “Issue SDT "optional but common" properties”.
Table 25.15. Issue SDT "optional but common" properties
| Property | Description |
|---|---|
| summary | The Summary string for this issue. |
| priority | The priority of the issue (Major, Trivial, etc.). |
| runTime | A timestamp indicating the set of Issue sensor data gathered during this particular snapshot. |
| creationDate | The date that this issue was created. |
Finally, it is important to note that the Issue SDT was evolved in April 2006. Thus, there may exist data prior to that time (or subsequent to that time, if the sensors were not updated) that is stored on disk in a different format. However, the evolutionary mechanism will upgrade the old data to this format when reading it in from disk.
The Issue SDT, and the analyses that currently use it are based upon a "snapshot" view of the data. In other words, sensors that generate Issue data should provide a snapshot of "all" of the Issues relevent to a particular project each time it is run.
This may seem wasteful, and it is in some sense: data about an Issue relevent to a project will be sent each time the sensor is run, regardless of whether or not the state of the issue has changed. An alternative paradigm for Issue data collection is an "incremental" mode, where only the changes in the state of the repository are sent by the Sensor.
Incremental issue data collection is far more efficient on the sensor side, but has two drawbacks of its own. First, in order to determine the state of the repository, you must effectively read in all of the sensor data that has ever been sent; there is no way to bound how far back in time to look for relevent changes to the database. Second, drop outs or malfunctions in the sensor create gaps in the sensor data that cannot be easily overcome, since important state changes will be lost permanently.
One interesting approach to obtaining the best of both the "incremental" and "snapshot" modes of data collection is to provide an alternative pair of sensor data types. The first might be called something like "IssueStatistics". Each instance of this sensor data would contain "snapshot" types of statistics: the total number of issues associated with the Project, the total number of open issues, closed, and so forth. The second might be called "IncrementalIssues", and instances of this sensor data would be generated only when changes to the state of the repository occur. Through this pair of SDTs, one can reduce the overhead associated with the current snapshot based approach, while avoiding the need for analyses to do arbitrary look-back.
The Jira tool provides facilities for creation and tracking of issues encountered in software development. A sensor for Jira represents this data as Issue entries.
Once collected, Issue data can be used to track trends in the creation and/or resolution of issues the occur during software development. For example, are issues being resolved more quickly or less quickly as time goes on? Another way to use issue data is to correlate the occurrence of defects with the areas of the code in which they occur. This can provide a measure of "fault proneness", useful in understanding where to apply quality assurance resources.