Remote project administration

via a online ticket tracker by Tracy Adams

The Big Picture

We want a standard process for virtual project administration.

The Medium Picture

There are countless bug tracking systems. If fact, most developers have either coded at least one themselves or swear behind the feature set of one particular tool. Remember, however, it is the process behind the system that is the key to success.

The need for structured communication heightens when clients and developers do not work in the same location. Lack of a standard system is prone will result in a chaos caused by a pile of emails intertwined with various phone conversations no one seems to recall in quite the same way...

The Cornerstone: Status

The status of bug or issue determines who is in control. Either the initiator or developer, but not both, is in responsible for issues in each state. Typically, the initiator of most issues are the client.

Case study

  1. Client enters an issue:
    Message: The edit comment page doesn't work right.
    Status: Open
  2. Developers assigned to the project receives an alert. The developer responds with a comment and changes the status:
    Comment: Please give a step-by-step outline describing what you are experiencing.
    Status: Need Clarification
  3. Client receives an alert. Client adds a comment and changes the status.
    Comment: I logged in as myself. I was on http://arsdigita.com/vision.html . I clicked on edit under my first comment. I changed the title from "I LUV this vision" to "I love this vision" and pressed Submit. When I looked at the page with all the comments, the change was not there.
    Status: Open
  4. Developer receives an alert and fixes the issue. The developer adds a comment and a changes the status.
    Comment: I've edited /general-comments/edit-comment-2.tcl to update the comment title in the database. You should now be able to run your example successfully.
    Status: Fixed waiting approval
  5. Client receives an alert and comes back to check. He decides that it is not quite right. Client adds a comment and changes the status.
    Comment: Oh yeah, instead of saying "Submit", I'd like the button on http://my-service.com/comments/edit-comment.tcl to say "Edit Comment".
    Status: Open
  6. Developer receives an alert and fixes the problem. Developer adds a comment and changes the status.
    Comment: I've edited /general-comments/edit-comment.tcl so that the button says "Edit Comment" instead of "Submit"
    Status: Fixed Waiting Approval
  7. Client receives an alert, checks, and decides he is satisfied. Client closes the issue.
    Status: Closed

Useful habits

Enforcing the law

This system only works if everyone uses it. In the beginning of a project, make an effort to teach clients and co-workers the process.

From time to time, the process will go astray. You will get a solitary email with some tasks. This is the time to reinforce proper use of the system.

You'll come to develop a style of your own to do this, but here are a few templates to get you started.

Testimonials

"I live in the ticket tracker."
  Atiasaya - GuideStar
"I LOVE the ticket tracker."
   Sheila - Infirmation (personally posted 350
   tickets in a 2 week period)

teadams@arsdigita.com