A simple interface to the Lighthouse API to allow for fast triaging of tickets

The initial goal is to build a few screens that allow for one-button triaging.

Background: After a while of not having time to handle triaging
tickets for an open source project I moved over to Lighthouse, I found
I had over 170 new tickets to wade through. If it takes me 1 minute
to triage (excessively low) then I’m still looking at 3 hours just to
speed through those tickets. The truth is that it usually takes me
5-10 minutes per ticket. I needed some way to triage it down to a
core set of ‘investigate’ issues quickly, then I could take my time
with those.

I decided I wanted a way to search for tickets (preferrably using the
existing search bins), show the first ticket result, and click Skip,
or one of ‘details’, ‘investigate’,
‘acknowledged’, ‘feature’,
‘duplicate’, or ‘invalid’. This set of
buckets is what I use; the idea is that everybody’d have their own,
and whether it changes the state of the ticket (and what to), or
milestone would be customizable per-bucket.

This magic application would then apply that tag, change it from ‘new’
to ‘open’ (or closed in the case of the last two), maybe stick some
boilerplate in the ticket comments, and move to showing the next
ticket in the Lighthouse search results. The buttons would be in the
same place for each ticket, for minimal and predictable mouse
movement.

Eventually, I’d love to offer niceties like applying tags to multiple
items at once, perhaps with some simple gmail like multiple selection.
There are other UI features that Lighthouse itself might not want to
include (in order to keep the core app simple), but that would be
useful to many developers.

For now, I’m working on the simple things. Getting a list of projects,
then a list of search bins, then a list of tickets, then an individual
ticket. That all works, right now, and caches the results in a local
database. It’s not fast, but it tries to keep in sync with Lighthouse,
so it probably won’t ever be very fast.

Searches aren’t cached, but the ticket retrievals are, and cache
expiry is handled using the updated_at field.

Triage uses #to_yaml on the Lighthouse API objects to store original
responses, so the app can manipulate the data without needing to
differentiate between cached and non-cached, and so I don’t have to
re-implement the entire database structure of Lighthouse. This
required a small change to the Lighthouse API library, so it’s bundled
as a packed gem (cyberfox-lighthouse-api on http://gems.github.com ).

It’s currently functional; you can create buckets and apply them to
tickets. Applying a bucket moves to the next search (or redisplays
the current ticket if it’s not part of an existing search.) You can
also skip through tickets, allowing you to walk through a search very
nicely. It’s pretty nearly completely functional for my use, now.

Then maybe I’ll re-skin the whole thing and make it look pretty. :)
Actually I’m not very good at making things look pretty, but I’m
pretty good at making things functional…

— Morgan Schweers, Cyber*FOX*!

p.s. You’ll need to create your own site_keys.rb in config/initializers
with:

  rake auth:gen:site_key

Copyright © 2009 Morgan Schweers, CyberFOX Software, Inc. under the MIT License