Corporate Tool v0.1 documentation

Corporate Tool Documentation

Contents   ::   Overhaul of the System  »

Corporate Tool Documentation

Ticketing sucks. What can be done about it?

Todo

Figure out a better way to organize this documentation. This page and the Overhaul of the System pages kind of repeat each other.

The Status is not Quo

Trac satisfies the bare minimum with respect to issue managment. It allows us to create a ticket and add comments to it. It also has a set of fields that add some metadata to the ticket.

The needs of a software developer are different from that of a sysadmin. However, they both have the need to track events. These events may be bug reports, user creation requests, enhancement proposals, merge requests, machine repair request, etc. While the type may differ from field to filed and from company to company, they are all an event that needs to be tracked.

Trac is focused more towards software development and therefore uses tickets to represent events. These tickets are not very flexible. They have a fixed number of fields. While additional fields can be added, they can not be changed based on the type of ticket. This creates the problem of having to enumerate all possible field combinations while only a subset may be used.

Additionaly, Trac is focused on the web. The web is nice for visualization, it is annyoning for creating and updating tickets.

Evil League of Evil Application

A more flexible event tracking system is needed. Software developers need tickets that present the appropriate fileds based on the type of report. Sysadmins need the server to automatically generate an event when an error condition is encountered. Help desks need events to be captured via email and the phone.

A key for event management, is capturing the event when it happens. This might be a failed build, or it might be a call from a user whose computer won’t turn on. In an ideal world, users would interact exclusively with the event management system. However, this is an impossibility. Where possible, the event maangement system should work along side the user to make it as easy as possible to enter events into the system.

Some input methods that may assist the timely entry of events are:

Email Gateway
One can email a specific address to create an event. Additionally, if the event email is not emailed directly, including it in the CC: or forwarding the message will introduce it into the loop.
IRC Bot
An IRC bot can monitor a channel and log a given chat directly to a ticket given some start and stop information.
Jabber Bot
Similar to the IRC Bot, can monitor a group chat for discussion to log to the ticket. Additionally, it may be feasible for an XMPP server to log based on a given trigger.
Call Recording
Using a service such as Tropo it may be possilbe to record a phoen call and have it attached to an event. Using transcription service actually adding text may be feasible.
Continus Integration
A continuous integration system should be able to create events when builds or tests fail. Additionally, it should be able to close said events when builds and test pass.
Mobile Application
A mobile applciation should be able to add events. Voice, video, and time information could be captured and added as well.
Show of Force...
The sky is the limit. From simple targeted web forms, to SMS, to Twitter, to complex parsing of various data, input methods should be created.

The Fish Rots from the Head

Trac is very flexible. The component architecture allows just about anything to be created. This, however, leads to a monolithic process that becomes very fragile the more one asks of it. Some of the other “features” lacking from Trac are:

  • Not easily distributed across multiple machines
  • Database schema is inefficient with large datasets. Especially with regards to custom fields
  • No “offline” mode
  • Limited user management
  • Inflexible default permissions and complicated extended permission system

Why not Cut off the Head?

The event tracking system should be very unix-tools-y. It should consits of small(ish) components that tackle one task, and perform it well. There should be a core service that manages the tracking of events. Input methods should be separate components. Reporting tools separate still. Using well defined APIs, this will allow the entire systm to be very targeted and distributed. It will also ease the addition or modification of certain aspects of the system. The quality of the system will be based on the combination of components used.

Contents:

Indices and tables

Contents   ::   Overhaul of the System  »