This document outlines the use of JIRA in tracking tasks and issues in the Evaluation System project.
JIRA is an issue tracking system and the Sakai JIRA is located at: http://18.104.22.168/jira/
Issues: Issues should be handled by due date and criticality. Questions about which issue to handle first should be directed to the project lead. Issues with a priority of blocker should always be handled immediately. If there are multiple blockers then handle the issue which will affect the most end users first.
Features and Improvements: New features and improvements should not be implemented unilaterally unless there are system options to hide or disable them. Please get approval from the project lead before making changes to the system that affect all users. Once the feature or improvement has been approved, please create task(s) in JIRA so that time and progress can be tracked.
Tasks: All development tasks should be recorded in JIRA. This others to know what you are working on and also allows for tracking of how long tasks take.
Time Tracking: Time and progress should be tracked to allow the project lead and managers to assess effort required for other similar tasks. This will also allow the amount of effort required to meet milestones to be assessed.
The work log should be used to record all blocks of work time. The work log does not need to be detailed. One sentence is preferable for a work log entry.
Progress: All tasks that are being worked on should be marked as in progress. Use the Start Progress link to the left of the JIRA item to mark it as in progress. Resolving an issue will automatically stop progress.
Resolving: Issues should only be marked as resolved when they are completed (unless you are the reporter). If you are waiting on something and cannot complete the issue then stop progress on it and enter a comment about what the blocker is. Do not resolve issues simply because they cannot be completed now.
Closing: Developers should not close any issues unless they are the reporter of the issue (e.g. a task you entered into JIRA for yourself). The testers or project lead should close all issues once they verify they are completed.
Entering issues: All issues should be entered into JIRA. This includes bugs, feature requests, improvements, text changes, and any other task that requires action. The issue should be assigned to the appropriate person or to the project lead if you are not sure who the appropriate person is.
Priority: Set an appropriate level of priority for all issues. Blocker should be used if there is something that is not working which makes the evaluation system unusable. Critical should be used when some portion is broken or unusable. Major is the average level of importance. Minor should mostly be reserved for cosmetic interface changes. Trivial should be used for misspellings and extremely simplistic issues.
Components: Select the most appropriate component for the issue. Components should only be set to unknown when no appropriate one exists.
Version: All issues must include a version which the issue occurs in (if using trunk then pick the most recently released version). It is also importnant to include the version you want this issue fixed in or it will automatically end up at the end of the issues queue.
Description: Descriptions should be complete and should include step by step instructions for reproducing the issue. URLs to pages which have the issue should be included. Descriptions which are unclear will be marked as Incomplete by the developer.
Screenshots: Screenshots should be used whenever applicable. Attach a screenshot to an issue after you create it by using the Attach screenshot link to the left of the JIRA item.
Windows XP users can do a shot of your entire screen (or multiple screens) by hitting the PrtScn (Print Screen) button and then pasting in the JIRA window. You can do a screen shot of just the current window (probably better in most circumstances) by holding the ALT key and pressing the PrtScn (Print Screen) button.
Resolved Issues: The reporter will be notified by JIRA when issues are resolved by developers. Actions should be taken after resolution as indicated below.
- Reopening: Resolved issues which are not completed to the satisfaction of the tester should be reopened. Testers have permission to reopen items they have reported. Items which were marked as Incomplete or Cannot Reproduce can also be reopened but should include additional detailed information.
- Closing: Resolved issues which are completed to the satisfaction of the tester should be closed no later than one week after resolution. Ideally issues should be closed within 1-2 days.