Req: Basic Overview

This is a high-level description of how req works. For further details, see the manual pages.

Users send request mail to an alias. (For example, in our original setup, mail was sent to systems or help.) Their mail is piped through a program which takes the mail, assigns it a new request number, and puts a copy of the mail in file associated with the number. That file will be used as a log of all the events associated with the request.

The mail is then passed on to the recipients of the list, with the number of the request added to the subject line of the mail. It will look something like:

  Subject: [Req #42] Help! How do I send mail?

Any mail sent through the mail alias with a request number in the subject line is assumed to be associated with that number, and is appended to the log for that number. Typically, a member of the alias will reply to the user and send a copy of the reply to the list. The reply then becomes part of that number's log. If the user replies, the same thing happens.

A request item has several features:

A requester, who is the person who originally requested it.
An owner, who is the person, if any, working on the request.
A priority, used by the group to prioritize requests.
A status, which indicates whether or not the request is resolved, stalled, or open.
Several dates, indicating the time of the original request, the last time it was updated, and the last time the user was informed of the status.

One may do any of these actions (and a few others) on a request:

Take it. (Assume ownership if no one else owns it.)
Give it to someone.
Change the priority.
Change the status.
Add comments to it.
Resolve it.

These can be done via mail, via a UNIX command line, or via any of the interfaces that have been developed for it. Currently, the only other interface that exists is a Tk based X interface, but an emacs client and a curses client are under development.

In addition, the queue of active requests may be viewed in a variety of ways, based on owner (or lack of one), status, priority, requester, and other features.

The status program allows users to check the status of their own requests.

We've tried to design the system to be as policy-free as possible.

Remy Evard

Webmasters@ccs.neu.edu