THL Toolbox > Workflow Issues > JIRA Task-based Management System User Guide
JIRA Task-based Management System User Guide
Contributor(s): David Germano
Overview
JIRA is a browser-based bug, issue, task and defect tracking system, and project management software solution created by the 
Atlassian company. We at THL are using this internally to register and track the progress of various work issues relating to both technology and scholarly content. The great thing about such systems is that they allow for the organized supervision of thousands of tasks across multiple individuals, including a permanent record that can be consulted in the future. Thus staff can easily retrieve all tasks assigned to them, including filtering them by project and priority. Management can easily see the status of each task, change assignments, and so forth. We also use the system for participating scholars who are doing intensive work with THL. See the THL installation of JIRA at https://jira.lib.virginia.edu, though it is only open to those who have accounts.
Issues
The basic category in JIRA is an "issue", which is a discrete work task entered into the system. To create an issue, click on "Create New Issue" on the top navigation bar. The first step is:
- Project:
- Issue Type: fix bug or link add feature, task, and many other options.
Once you specify those two, you come to the main screen for describing the issue:
- Summary: this is more like a "title" that summarizes the task for at a glance recognition
- Priority: needs immediate fix, major but can't be resolved, minor, purely experimental. We simply use these as 4 levels of priority, such that functionally we understand as high, medium high, medium and low respectively. IMMEDIATE FIX should be reserved to public bugs, or urgent things that must be addressed immediately. It conveys that everything else should be dropped to address this issue. MAJOR BUT CAN'T BE RESOLVED then is to be used for the current work focus for the person in question - say the next couple of weeks. MINOR are the things that are around the corner, to be addressed in a few weeks. PURELY EXPERIMENTAL then is for things that currently we do not have immediate plans to address.
- Due date:
- Components:
- Affects Version/s:
- Fix Version/s:
- Assignee: specify the person who should do the work.
- Reporter: the person assigning this task
- Environment: as relevant, specify the operating system/version, browser system/version, etc.
- Description: this is where all the detail on the task goes.
- Original estimate: this is mandatory, so if you don't know, just put 1m (one minute)
- Attachment: if you have an attachment, like a screen snapshot, etc.
- Impact-Effort Rating: (1) high impact: low effort, (2) low impact: low effort, (3) high impact: high effort, (4) low impact: high effort.
Once an issue has been created, then you will find that when you open the issue, on the left hand side menu there will be a section on "available workflow actions" and a section on "operations".
Available workflow actions begin with:
- Resolve Issue: this gives options for resolution - unresolved, fixed, won't fix, duplicate, incomplete, can't reproduce - and allows you to add a comment.
- Close Issue: this allows you to add a comment, but otherwise simply changes the issue from "open" to "closed".
- Start progress:
If you choose "Resolve issue", the workflow actions menu will change to:
- Close Issue:
- Reopen Issue: this allows you to reopen an issue that was marked as fixed and/or closed.
Once you close, then only "reopen issue" will remain as an available workflow operation.
As you do various workflow operations, the "status" indicator automatically changes:
- open, in progress, reopened, resolved, closed, deployed to test server,
Operations include the following options:
- Assign this issue:
- Attach file to this issue:
- Attach screenshot to this issue:
- Clone this issue:
- Comment on this issue:
- Create sub-task:
- Delete this issue: delete the issue.
- Edit this issue: edit the content ofthe issue.
- Link this issue to another issue:
- Move this issue:
- Convert to sub-task:
- Voting: You cannot vote for an issue you have reported.
- Watching: Watch it to be notified of changes
- Worklog: this allows you to log work done on the issue.
Resolving & Closing Issues
For the person doing the work, they should "resolve" it when done - never close it. Then the person who is checking the work, they need to "close" it. Thus its important that the "reporter" be the person who is checking the work. And it is essential that the "reporter" then actually confirm the work is done by "closing" it.
It is important if you are doing the work and you report it, that you change the reporter to someone else if someone else is going to need to check the work. If in fact no one else is involved, and it is an item you discovered and you fixed, so that no one else needs to check, then please you have to be responsible for CLOSING it and not simple RESOLVING it.
We need to close issues each week, so that a simple query across "all projects" for all "resolved" issues will turn up the things that need review, and not a laundry list of things done weeks ago.
Also notice that you can "save" filters you use in searches to avoid having to manually redo them.
Classifying Issues
JIRA has multiple ways to categorize issues. Firstly, there is a three fold way to categorize issues by subject matter - Category, which contains Projects, which contains Components. In THL, we have only one Category, which is THL itself. We then have a number of Projects, which are broad classifications such as "Administration", "Place", "Literature", and so forth. These then form larger containers, with which we have various THL work initiatives that are rendered as "Components". Thus within the "Places" project, we have components of "Sera Monastery", "Drepung Monastery", "Place Dictionary", and so forth, each of which is a distinct THL initiative involving a number of different work tasks at any given point. We can easily make more "components", but to make new projects we have to ask for the help of the Library staff.
THL Projects are as follows:
- THL Administration
- THL Community
- THL Documentation
- THL Education
- THL Encyclopedia
- THL History
- THL JIATS
- THL Literature
- THL Multimedia
- THL Places
- THL Reference Content
- THL Tibetan Language Learning
- THL Tools
- THL Tourism
- THL XML Text Publishing Tech
In addition, to projects and components, there are two other ways you can link tasks to each other.
Sub-tasks: this is available when viewing an issue and is available in the left hand OPERATIONS menu as "create sub-task". A sub-task is just like an issue in most ways, and gives the same interface. Please note the issue-type is hard-wired as "sub-task". Once made, it will visually appear as a subordinate for its parent task. This is a very convient way to group together items.
Link Issues: this is available when viewing an issue and is available in the left hand OPERATIONS menu as "link this task to another task". This allows you to add a comment, to specify the issue it is linked to, and finally to use a drop down list to specify how the two are linked:
- is a pre-requisite for
- is dependent on
- duplicates
- is duplicated by
- incorporates
- is incorporated in
Checking on Issues Open for you or for a Given person
Click on "Find Issues" from the top navigation bar and then fill out your criteria. In this way you can see all the open issues assigned to you, resolved issues done by someone else, or whatever else you need to see.