Work Tracking

Note: this guide was written for ST. As of May 2017, we are making new tickets in RT, the campus ticketing system. We are expected to close tickets we are currently working on in ST, but there are still many open tickets tracked in ST. Read this page for information about ST; and then see STToRTDocumentation for how things work differently in RT.

Background

We track our work in a database with a WWW front-end. You'll need to learn how it's used, as it's fundamental to all of our technical work. It has a general interface as well as a more detailed way to search, the so-called RunOn Sentence.

The latter was originally intended for viewing all of CSCF's work, however it can also be useful in providing various ways of looking at your own work. It can help you organize and prioritize your work, provide information for others should they have to take over when you're away (i.e. provide "business continuity"), and provide a measure of the nature and quantity of problems we face (to aid in planning).

We call the system "ST" (Service Tracker). It is based upon a rather old version of RT (Request Tracker), although it now bears little resemblance to either the original or to the current version. Many still refer to it as "RT", out of habit.

There are three versions of the interfaces, "debug", "beta", and "production". As a CSCF staff member, please be sure to use the "beta" versions (as referenced in this document). If in doubt, check the URL, as the initial part should end in "_beta" (rather than in "_debug", or nothing special at all). That way changes to the interface are well tested before they graduate to the "production" version, used by those CSCF clients who wish to.

Who Uses It

We make ST records ourselves; we do not expect our clients to have to do that. That's why the ST interface is located in our "internal" WWW space, not in a public WWW page. That doesn't mean that clients are forbidden from using ST; just that they're never required to. In some cases it has proven handy for them to do so.

When is it Used

In general, you should record almost all of your work in ST. It's the primary way of recording your work for the benefit of yourself and other CSCF staff. Some examples of work that benefit from being recorded are:

• recurrent problems
• solutions to problems - howto's
  • especially when non-trivial thinking time required
• non-trivial elapsed time and work still not completed
• any work for research support

Research support is a special case in that we're required to track the time spent on the work. Time tracking is not a requirement for other work, so use your own judgement as to whether you use ST to record time spent working on any problem not related to research support.

Note that ST isn't intended as a replacement for documenting standard procedures. If something is to be done repeatedly, it deserves to be documented in our "internal" documentation, in a way that's easy for others to find and use.

Creating a Record

When creating an ST record, be sure to include who the work is for in the "E-mail" (or "Userid") field.

When looking at the details of a record (selected via the "#" column in the work listing), most of the attribute names (also called field names) link to a description of what they mean. That's handy for reminding yourself what a field means; there is also a reference list of all of the descriptions of ST fields.

Once you've made an ST record, there may be other fields that you want to set, as the creation WWW page doesn't provide for setting all fields. This should be done right after the ST record is created, using the resulting update page. E.g. it's almost always the case that the "owner" and "responsible" fields should be set; quite often that's yourself.

Who

The "E-mail" field (called "Userid" in the MFCF version) describes who the work is being done for, also known as the "requester". The "CC" field is intended for those who wish to receive the same e-mail that the requester does, without being listed as a requester.

When a record is created by a CSCF staff member, the "requester" does not default to the staff member, as the work is often being done for a client. So for a client request, be sure to fill in the userid of your client, not your own userid.

What

The "Subject" provides a one line summary of what is to be done. It can optionally contain more information, if there is room.

Note that while the list of ancestors and dependencies in a record display includes only the status and subject, selecting "showing children as well", "showing ancestors as well", etc. in the RunOn Sentence and searching for a serial number will usually show the desired records, with whatever fields you want.

Why

It should be obvious to any reader (of a record) why the work is being done. Typically that's recorded in the first comment. In some cases, the ancestry of the record, or the subject, will make it clear.

Serial Number

Every record has a serial number, often written in the form "ST #NNNNN". Email to and from the system uses the serial number. When work requires making an additional record, it is mentioned in the "Dependencies" field (as just the NNNNN number) if it's made within our ST system, or the "Other IDs" field if it's a request for another group/system.

Extension and Office

The "Extension" and "Office" fields are provided via WatIAM when the form is submitted.

Priority

If ST recognizes the person as CSCF staff, the record will be prioritized as an "Upcoming Project"; otherwise it's an "Upcoming Request". The "priority" is one of many attributes a record may have. General categories for priority are:

• Emergencies (takes precedence over all other work until completed)
• Current (active work requests)
• Upcoming Requests (requests from clients that we expect to complete)
• Upcoming Projects (proactive work that we expect to complete in the next 12 months)
• Uncommitted (lowest priority, things which can't currently commit to)

Work Organization

We are working on developing a system of categorizing our work in a form suitable for presentation and planning. This approach requires that up to three characteristics be specified for each work record.

Unused fields

Some fields aren't even used (and yes, they really should be removed from the UI). They are:

• Your name

Ongoing

Comments and Summary

While working on a record, keep track of progress using "comments" and the "summary". Comments, added at the bottom of the page, keep track of details and progress on the work request. They appear in the "Transaction History", which also records all of the changes made to the record's attributes over time. The Summary, which is displayed just before the transaction history, is intended to summarize the current state of the work. A good summary avoids the need for others to read the entire transaction history to determine the state of the work. It should be terse, describing things like

• the estimated time to completion,
• remaining steps in the work to be done,
• things that are preventing the work from being done, e.g. why the work is stalled,
• ...

Think of the Summary field as a summary for management, who can use the information for planning purposes as well as to keep our clients informed of the progress on work they have requested.

Client Communication

In addition to recording the technical work being done, record client communication as well; it's very important to avoid the "black hole" phenomenon, in which the client thinks we're doing nothing.

The "mail" (a reply) button in the record update page is one handy way of recording client communication.

When a mail message is manually recorded, be sure to record the relevant message headers (Date, From, To, Subject); it's not helpful if it's not obvious who sent the message when.

Relationship to Other Work

You may find it useful to break a task into sub-tasks. Those are dependencies; work that must be completed before the main task can be considered done.

A dependency should not be confused with a See Also, which is related work of interest that is not required to be done in order to complete the task at hand.

Where ST References are Useful

Some places that benefit from referencing ST items are:

• other ST items
• purchase orders
• surplus declarations
• configuration files
• change logs (e.g. RCS) * e.g. sponsors data
• documentation * WWW page updates, sometimes as comments
• inventory entries

with the primary goal being to help others (which includes your future self).

Closing Records

Do not leave work records open when the requested work is done. Doing so creates a very misleading picture of our work. If there is followon work, in addition to original work to be done, then use the Create button beside the "See Also" field in the Update page. Avoid the temptation to leave open a record that is done, at least as far as the requester is concerned.

When a record is closed, the resolution should be clear; the extent to which the work succeeded should be documented. It should be possible for someone else to look at the record and easily determine what did(n't) happen.

When we think the work is complete, let the client know, and document how that was done, typically by including the complete email message that was sent to them. Just because we think it's done doesn't mean that they do.

There are a variety of statuses that can describe the cause for closure, ranging from "done" to "forget". They provide only a rough categorization, not replacing a description of the reason for the resolution when it's not obvious.

How to Use ST

It's advisable to arrange your morning routine to automatically look for

• overdue or soon to be overdue records
• your work list

One way to do this is to use the run-on sentence to bookmark those queries and make them your browser's home page.

In the selection (at the beginning of the third line of the run-on sentence) that defaults to "owned by or the responsibility of", the next two selections are useful ways of separating your work:

• Not Stalled And Owned By
• Overseen By

The former are things you can work on now, the latter are things that you should check up on from time to time (e.g. once a week).

Emailing ST

The ST E-mail Gateway provides a mechanism for sending e-mail messages directly to ST.