Developer's Bug Tracker Notes
We use Request Tracker for our bug tracking system. See the public bug tracker notes for a our public description of the bug tracker. You can access the JigCell bugtracker system here.
Reporting a bug
If you find a bug in JigCell, go to the JigCell bug tracker. To report a new bug, click the New ticket in button. Give your bug a subject and provide as much information in the description as possible. If you know which component of JigCell caused the problem, select that component. If you want to be notified when someone responds to your bug, enter your email address in the Requestors field. Press the Create button when you have finished, and your bug will be added to the bug tracker, and all of the JigCell developers will be automatically notified.
Tracking bug report responses
If you want to know what we are doing about your bug report, or to know about other bugs reported in JigCell, go to the JigCell bug tracker. On the right side of the page, in the box labeled Quick search, click on JigCell. You will be taken to a page that lists the current bugs in JigCell.
Bug tracker layout
When you join the JigCell team, you will be given a bug-tracker account. When you sign in to the bug tracker, you will have access to two "queues": the JigCell queue and the Test queue. The JigCell queue is used for bugs in JigCell and the Test queue is there for you to experiment with. If you want to know how things work in the bug tracker, feel free to create and modify bugs in the Test queue.
Notifications
When a bug is created in the JigCell queue, the bug tracker will automatically send an email to you with information about the new bug. If you do not take any action, you will not receive further emails about that bug. If the bug is of interest to you, you may add yourself to the "Cc" list for that bug, and you will be notified when someone responds to the bug. If you should be responsible for the bug, then you may "Take" the bug, which will make you the owner.
Working with a bug
As you learn more information about a bug, do not forget to add it to the bug report. Keeping bugs up-to-date lets users know what is going on and prevents other developers from duplicating your work. When you believe you have fixed the bug, you may mark it as "resolved".
Getting an account
Contact Tom Panning (tpanning@vt.edu) if you need an account on the bug tracker.
Categories of Bugs/Requests
- Error in existing feature- a completed feature doesn't work as designed
- Feature/usability enhancement- desired change to improve an application
- Website/Documentation/Other- work not involving the application software
- Tracking- used to monitor the progress of other requests
Prioritizing Bugs/Requests
| Priority | Existing feature | Enhancement | Other | Tracking |
|---|---|---|---|---|
| 99 | - | - | - | Task lists for upcoming planned releases |
| 50 | Repeatable crash in common user task, loss of critical functionality, major dataloss | - | Must be done immediately | - |
| 40 | Intermittent crash in common task, repeatable or intermittent crash in other tasks, loss of major functionality, some dataloss | - | Must be done before next planned release | - |
| 30 | Rare crash, loss of some functionality, trivial dataloss, requires restarting application | Significant usability improvement, top performance issue, compatibility with other software, new feature with high utility | Desired for next planned release | - |
| 20 | Loss of functionality with workaround | Moderate usability improvement, performance issue, most new features | Desired within next 2-3 planned releases | - |
| 10 | Loss of functionality with easy workaround, cosmetic issue | Minor usability improvement, feature request with little return for work involved | No targetted deadline | - |