Trackplus User Guide

THL Toolbox > Workflow Issues > Trackplus User Guide

Track Plus User Guide for THL Staff and Collaborators

Contributor(s): Dan Haig.

Introduction: What the Heck is Track Plus?
Getting Started: Your Account Setup
Your Track Plus Home Page
How to Read and Edit an TP Issue
Creating a TP Issue
Life Cycle of a TP Issue

Introduction: What the Heck is Track Plus?

Track Plus is a Web-based project management tool that allows the THL to organize our projects and keep track of the work people do. Everything from individual bug fix requests to vast project plans is stored and tracked via individual Track Plus “Issues” that make their way from Originator to Developer to Tester. The Issues are categorized by Project (big boxes) and Class (smaller sub-boxes), making it easy to quickly locate and examine what work needs to be done for any given area (or by any given person) in the THL. It also leaves a permanent record of our work for future reference. Track Plus makes it possible for the vast array of projects, and the people who create them, to move forward in a coherent, reliable, and manageable way.

Getting Started: Your Account Setup

In order to use Track Plus (often called just “TP”), you have to login at the THL Track Plus Web site on external link: Orion (the same server that serves up the THL Web site), but in order to do that, you’ll need a TP user account. Please contact Dan Haig (danhaig@virginia.edu) to have an account set up. The usual username paradigm is first initial, last name, e.g. dhaig, but you will need to confirm with Dan. When your account is created, you will automatically receive an email from the Track Plus Administrator containing an initial password. If you want to change that password, please login at the url given in the welcome email, click on the “Administration” link at the top of your home page there, and then on the subsequent page click on the “My Profile” link (which will appear just below the Administration link). There on the Edit User Profile page you will see the routine for changing your password (along with other settings you may wish to toggle).

Your Track Plus Home Page

When you log in to Track Plus, you find yourself on your Home page. It shows you three boxes: Responsibles Issues, My Issues, and Manager’s Issues. You will mainly be concerned with Responsibles, because those are the issues you are directly responsible for working on. If you are a Manager for any issues they will be listed in that box, but many of those issues will be someone else’s direct responsibility to work on, and you typically may not care to review all of those every day. “My Issues” is a compilation of all issues for which you are Manager, Responsible, or Originator, which is even less directly useful most of the time.

Under Responsibles, assuming you are in fact responsible for any issues, you will see listed the names of the TP “Projects” under which your issues fall, and how many issues you have for each Project. Click on the numbers to go to a list of individual issues. Once there, you can click on an issue number to see, finally, a single issue.

If you know the number of an issue, you can always enter that number in the white text input box near the upper right of the page, the one with a blue arrow to the right, then click the arrow to go to that issue’s page.

Try this now by entering “19” and clicking the arrow. You should end up at TP 19, which is a test track plus.

How to Read and Edit a TP Issue

If you have gone to TP 19, as describe immediately above, you will see what there is to see in a Track Plus issue. A few things to note:

At the top, you see the number, current status, and title (tp calls it the ‘synopsis’) of the issue:

Issue No. 19 : processing : test trackplus

Next, you get the basics on the issue such as what Project and Subsystem/Class it belongs to, who created it, who’s responsible, etc.

Then comes the “Description”, the basic statement of the situation that requires work to be done, and some detailing of what that work should be. The Description should *not be changed as the Issue gets worked on, rather, comments can be added in the Comment box as you go. It is better to open a new TP issue to address new or changing needs, than to keep altering or recycling an existing issue. If the Description keeps changing, the issue will never be Closed, and it will be difficult to see, later on, why people did what they did. Much of the value in Track Plus is the record it leaves of work done.

Editing a TP

Let’s say you have done the work requested for a Track Plus issue you’re the Responsible for, and it’s time for you to send the issue to the Manager (or whoever else is the Quality Assurance tester for the work or otherwise needs to know that it is done). At the top of the TP, you will see a bolded Edit link; click that. The resulting page is a form that allows you to change the Responsible field to the user who should test the work. Further down, there is a place to change the State of the issue, e.g.:

Current State : processing New State : (choose)

You would then choose “implemented” from the dropdown menu, and add any Comments you may have (for instance, a url for the page in question and instructions for what is to be tested). Finally, click “Save”; the resultant page will show the TP thus changed, and an email will be sent to the new Responsible user to notify them.

This is just an example to show how to generally edit a TP - see below under “Life Cycle of an Issue” for much more information on how and when to move Track Plus issues along.

Creating a TP Issue

By now you should be generally familiar with how to work with a TP issue. Here is your how to create a new issue. Please note, it won’t be necessary for you to click “Save” at the end of this TP creation exercise, so unless you are using these instruction to create an actual issue, just “cancel” at the end instead. It’s not that we’ll run out of Issue numbers, but having faux issues everywhere will clutter up searches for real ones.

So:

To create a new TP, click on New Entry in the top menu bar. The first thing you will want to do on the New Entry page is to select the Project (top center dropdown menu), and then select from that Project’s Subsystem and Class fields (if you set Manager and Responsible first, those fields will just reset to their defaults when you select the Project setting and you’ll have to do it again). There are quite a lot of choices (see the attachment in TP 190 for the full list in a Word doc), but your choices will hopefully be obvious or will have been defined at the outset of your work. When in doubt, ask, or guess now and ask later. Please note that for reasons of strange interface decisions by the makers of TP, we have Subsystem and Class - be sure to set both, and be sure they are the same.
Go ahead and select Manager and Responsible users. If in doubt, try to talk to or email somebody to see who should be working on an issue.
Select one of the choices in the “List” field. “Problem Report” is the default and is almost always ok as such, but if you see a clear alternative, use it. THL workplans, for instance, are all set to “Work Package”.
Priority and Severity: these have defaults set to lowest, you may change these if you or the issue are feeling the heat. “Occasionally” is a strange choice of Priority terms, I know - but Track Plus is made in Germany, so cut them some slack.
Set a Due Date if you like. When a due date is crossed, the Responsible will get email reminders. Start Date is hardly necessary but you can set it if you see fit.
Write the Synopsis! This is your succinct, pithy, and short description of the Issue. Character limit is in effect.
Write the Description. This is the critical part - if you are vague or incomplete, the work won’t be done properly. Be explicit, include specific url’s where necessary, state what should be done with the Issue in terms of production or publication timelines, and to whom the Issue should be sent for Quality Assurance testing.
Declare a parent item, if applicable. A “parent” would be a tp of which the present issue is a subset (see Issue 117, the Drepung workplan, for a good example of this in action). The method to declare a parent item is a little odd: click the ‘three boxes’ icon on the right of the Parent row; type in parent issue number in the popup window, then click “search” button; it will list the parent issue in the popup, as a link, click on that link. The popup will disappear, sending you back at the main TP window, with the parent item now listed.
Add an attachment. Click the paper clip, select “Browse” in the popup, select the file to be attached, then click the “Add” button. Your attachment will now be listed there in the popup. Close the popup window and you will see the attachment now listed in the main TP window. You can click on the little garbage can next to any given attachment listed in the popup to delete that attachment.
Click “save”, and you will see your new TP with its freshly minted number. But you aren’t done yet!
On your new TP, click “Edit” up at the top of the window, and then scroll to the bottom of the Edit page and change the State of the issue to “assigned”. A new tp is set to the “Opened” state by default, and you have to go back in after creating it to change the state.

Congratulations! Now the TP belongs to somebody and will presumably get worked on.

Life Cycle of a TP Issue

Here are the typical steps a Track Plus follows from creation to closing. Please familiarize yourself with this, so you will know how to keep issues moving along properly marked.

An Issue is created/opened.
After the Issue is opened, it is "assigned" to the "Responsible" user. If you don't know who to assign it to, you can "analyze" it to someone - David Germano if you don’t know who else - so they can assign it. It's kind of a polite way to pass the buck without telling somebody they necessarily have to do it themselves. It is often in your best interests to speak (email. chat, phone, whatever) with somebody before making them Responsible for a TP, if it is an issue they wouldn’t otherwise expect.
The assigned developer does the work, then marks the issue as "implemented" and kicks the track plus over to Quality Assurance (typically this would be the user listed a Manager) who is to check the work. Of course the developer includes all relevant info as to how to test the item in question, including urls and etc.
The QA person either says "this is rubbish, you forgot x y and z" and kicks it back to the developer for another cycle, or, the QA person decides it is good and, unless further processing is needed (for instance, if the work was done in a hidden area and now needs to be linked to the live site), marks the issue "closed".

Exceptions to the normal process:

If you are assigned a track plus that cannot be worked on, kick it back to the Originator, marking it “assigned”, with a comment as to why you have done so - for instance, if you receive a bug report but cannot reproduce the bug, send it back to the originator saying “cannot reproduce” and ask them to see if they can still see the problem, in which case further directives or face time would be helpful.

THL Toolbox > Workflow Issues > Trackplus User Guide