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
as well as a more detailed way to search, the so-called
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
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.
The "E-mail" field (called "Userid" in the MFCF
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.
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.
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.
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
when the form is submitted.
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)
We are working on developing a system of categorizing our work
in a form suitable for presentation and planning.
requires that up to three characteristics be specified for each work record.
Some fields aren't even used
(and yes, they really should be removed from the UI).
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.
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.
work that must
be completed before the main task can be considered done.
A dependency should not be confused with a
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).
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
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
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
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).
The ST E-mail Gateway
provides a mechanism for
sending e-mail messages directly to ST.