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 ‘
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:
Copyright © 2009 Morgan Schweers, CyberFOX Software, Inc. under the MIT License