Long time Microsoft executive and now head of VMWare Paul Maritz is credited with coining the expression “eating your own dogfood” as used by the software industry to describe relying on their own software before they subject customers to it. In an internal memo in 1988 he suggested that Microsoft software would in the long run be better if Microsoft employees relied on it more heavily during development.
That same spirit is embraced by blist and in fact, we have been using it for bug tracking for a long time. It’s well beyond the dogfood stage and we rely on blist to keep track of software defects discovered internally and by our users. A number of people have asked how we use blist to track bugs and so I thought I’d tell you and show you.
Bugzilla is a 10-year old open source bug tracking project from the Mozilla project. Pretty much every programmer in the world knows what bugzilla is. The naming gurus we are, we named our blist-powered bug tracking system blistzilla. Here’s a thumbnail view of what blistzilla looks like:
blist is ideally suited for use as a bug tracker. A bug tracker needs to perform 4 critical tasks:
- Allow someone to record a bug
- Provide a means for each bug to be assigned an owner and for the owner to find bugs assigned to him
- Provide a means for the status of each bug to be updated as it is being worked
- Offer some ability to analyze all bugs as a database
blist meets these needs perfectly. Bugs can be entered by any of 3 methods: a) typing directly into the blistzilla in tabular layout; b) typing directly into blistzilla in page layout; c) entering data through a page layout form widget on a foreign host page – for example on your company’s wiki.
Let’s examine the columns in blistzilla:
- tags – all blists have a built-in tags column which allows you to assign arbitrary tag(s) to any row. We use tags to loosely group multiple bugs together. For example, we have a number of bugs having to do with pick lists. We’ve tagged all of these bugs “picklist redo” and now the engineer who’s polishing up that area of the application can find all of the bugs with that tag.
- ID – it’s easier internally to communicate about bugs by a specific ID than by description so we assign each bug an arbitrary ID.
- Type is pick list containing 4 discreet values we use for broad categorization: bug, feature, UX, infrastructure
- Subject is a plain text column for a short description
- Description is a rich text column for a long description. As a rich text field it supports color, bold, italics, bullet lists, etc. which provide for a nice way to write up a detailed summary of an issue.
- Priority is a pick list the values of which are: Urgent, High, Normal, Low
- Status is another pick list, the values of which are: New; Needs Repro; Ready; Assigned; Feedback; Resolved; Rejected; Duplicate; Will Not Fix. In that blist supports columns having default values, we default this column to “New” which saves us time when recording new bugs.
- Assigned To is another pick list, this one containing the names of all of our employees
- Assigned On is a date column. Hint – you can type “today” in a date column which makes it handy for entering new bugs
- Top 25 is a checkbox. Sometimes the engineering team stops feature work and goes into bug fixing mode. When we do that, we’ll often try to steer the engineers towards fixing the bugs having the most impact. Top 25 is a quick way to achieve this.
- Severity is another pick list: Minor Issue; Major Issue; Cosmetic; Crash; Performance
- Found In Stage is a pick list which contains: Production; Test (Blocking Deployment); Test (Non-blocking); Development
- Regression is a checkbox (we like to keep track of bugs we’ve fixed more than once)
- User Submitted is a checkbox (we like to keep track of bugs submitted by users)
- Resolved Date
- Resolved By is the same pick list containing the names of our employees that we used for Assigned To above (blist allows you to re-use pick lists)
- Created Date
- Author is the same pick list of employee names
- Notes is a rich text column
- Master Backlog Xref is a column that allows us to link a back to a major work item on our master backlog. I’ll tell you about our master backlog in another post soon.
- Attachments is a blist-in-a-blist containing 2 sub-columns: Description (text) and Attachment (document). This structure allows us to store an unlimited number of attachments per bug. Attachments could be screen shots or crash dumps. Here’s an example:
Each color band is a separate bug – there are 3 bugs in the screenshot above. The first bug has two attachments – a screenshot (PNG) and a video (Flash movie). The second bug has no attachment. The third bug has a single attachment – a JPG which is presumably a screenshot.
As you can see our blistzilla bug tracker is fairly comprehensive.
One of the most powerful and useful features of blist is its provision for creating and using lenses – saved filtered views of your data. We have more than 100 lenses in blistzilla:
In the screenshot above you can see a few of the lenses we use in blistzilla. High Priority Bugs. Low Bugs. Infrastructure Tasks. Last 100. By simply selecting a lens from the drop down menu, the criteria and layout stored in the lens is dynamically applied to the data in the blist. Loading the “Last 100″ lens will show different results today than when I ran it yesterday.
If you’ve never created a lens, you should try it. Lenses are incredibly powerful and useful. Here’s a short video you can watch to get started creating lenses.
We like using blist for our bug tracking. One of the questions I’m asked from time to time is why we don’t use one of the commercial or open source bug tracking systems instead. The answer is simple. Because we have full control to create whatever columns we want, by using blist we can mold our bug tracking system to match our real world processes instead of the other way around. With every other bug tracking system, you have to conform to the fields and layout that the creators of the software thought you need, which usually means you’ll need to adjust your processes to fit the software. With blist, you’re in control. You decide what to track and the result is an application that matches your business process instead of the other way around.