Issue Tracking
Steven J Zeil
Last modified: Nov 20, 2013
An apparently mundane task with significant impact on
Basic Questions
Roles in an Issue Tracking System
Users (internal or external to the project team) report problems
Project administrators prioritize problems and assign some to project staff
Project staff report on status of problem solution
What Questions Does an Issue Tracking System Answer??
Open Alternatives
- Bugzilla was one the earliest well-known such systems
- Defined much of the feature set and organization still used by its successors
- Commonly integrated into Forges to take advantage of infrastructure already provided for project management
- particularly personnel mgmt.
1. Bugzilla
- Originally for Mozilla/Netscape project (1998)
- Major updates have continued through 2011 (v4.0)
Bugzilla Problem Report
Bugzilla Classifies Problems by
- Severity
- Blocker (a.k.a Showstopper): blocks development or testing
- Critical: crashes, loss of data
- Major: loss of important functionality
- Normal
- Minor: minor functionality loss and/or a workaround is available
- Trivial: e.g., misspelled messages
- Enhancement: request for new features
- Priority
- Numeric, assigned by project managers
Bugzilla also Tracks
Comments (forum-style)
Notifications desired
The Life-Cycle of a Problem
What Goes into the System?
2. Other Systems
Forges
Most forge systems integrate some form of issue tracking
MyLyn and Project Perspectives
personal task list, including Bugzilla reports
Change set related to task
Task editor
Context-based task info
Working with an Issue-Tracking System
- Add a connector to the issue tracker
- Define one or more queries indicting what issue
reports you want to be displayed by mylyn
- E.g., in OurProject, display all reports assigned
to me as tasks
- Select a task to update info (will synchronize with remote
manager)
Task List
- Can display by category/query or by date
- Searching & filtering are possible
- “Focus on work week” option
- Color changes indicate scheduling & status
- red for overdue tasks
- blue for tasks scheduled for today
- black for tasks scheduled for later in the week
- green for tasks completed today
- grey for tasks completed earlier
Context Management
- The context of a task is the collection of files &
information related to the task.
- E.g., Java files related to a bug
- Changes made in the course of fixing it
When you activate a task, Eclipse/Mylyn tracks the
context
The Focus on Active Task button causes the package
explorer to show only elements in the active task’s context
Establishing Context
- From the task list, activate a task.
Start working
- As you open files directly from the package manager, or
indirectly (e.g., using Show Declaration (F3), \command{Open
Type} (Ctrl-Shift-T), or Show References (Ctrl-Shift-G),
they are added to the focused package manager view.
Restoring Context
- You can deactivate the currently active task (or activate a
different task that you want to switch to).
- Your various open editor windows close and the package manager
returns to its normal unfocused state
- You “return” to a task by re-activating it.
- Your editor windows for that task context are restored
Contexts and Tests
- You can create a Context Test Suite of those JUnit
tests that you will be frequently re-running as you work on your
active task.
Contexts and Change Sets
Changes made while working on an activated tasks are checked
- Change sets can be manipulated in the synchronize view
- CVS & Subversion
- Said to work with Egit, but I’m not seeing it in practice
Machine Hopping
- A major limitation (IMO) of the Mylyn context support is its
limitation to a single workspace
- I frequently work on the same project on different machines
(office and home)
- Things I have yet to try
- Exporting and importing of tasks
- Not clear if context is included
- Changing the task list data directory to a dropbox folder