Forum OpenACS Development: Response to Software Development (Bugs, QA, etc) and OACS

Collapse
18: Response to Software Development (Bugs, QA, etc) and OACS (response to 1)
Posted by Carl Coryell-Martin on 03/14/02 07:47 PM

General Introduction

I think a strong issue tracking system is an important part of the toolkit and a vital part of software engineering. If I don't use a system, issues get forgotten until they cause embarrassment.

Since Lars is going to spend some time on this, I'll spend a minute describing what I like in issue tracking systems based on my experience running multiple projects with multiple clients at Civilution.

The openACS3.2 ticket tracker is pretty good and what I have been using for about 2 years. We made some major modifications to support logging of hours to tickets. If you want to look at how I use it, feel free to email me and I'll let you see some pieces of our system. Its far from ideal though, I haven't been able to do releases well and email notifications are sketchy at best.

I have also spent some time looking at the Fog Creek FogBUGZ tracker, and some other proprietary ticket trackers. As a reference implentation I have very few complaints with FogBUGZ.
http://www.fogcreek.com/FogBUGZ

I find that the workflow for features and defects is similar enough that we have been able to track both very successfully in a ticket tracker. There are some subtle distinctions between them, and its helpful to be able to filter for one or the other. But the general flow is the same.

So onto specific requests:

Major Datamodel Elements

Projects

You should be able to separate tickets and people into distinct projects. At Civilution, we had two projects for each client (one to track billable tickets and one for unbillable tickets, though I wouldn't do that again) and an assortment of internal projects like: Biz Dev, Overhead Tasks, Sysadmin, Codebase.

Its nice if projects have some kind of subdivision like area that you could use to partition a project into documentation, graphic design, and other major ares.

Its nice to have a good sense for versions of projects. We didn't do a very good job of this, but its really nice to notice which version a defect was found in and assign it to be fixed by a certain version. (At some companies if a feature is deferred more than N versions it is dropped where N is typically 2-3)

Users

Users were attached to projects. We only had Administrators and Users, we didn't get any value from the common separation of internal and external users and I wouldn't waste time on it. Everything should be logged and we trusted our clients so it wasn't worth the bother. The 3.2x ticket tracker seems to offer a way to hide comments from the external users, but I don't think this secrecy adds any value to the client relationship so we never used it (except by accident).

Tickets

  • Should always have one person who is responsible for moving it to the next state.
  • Should notify people via email when they become responsible for an issue. Good email notification is probably the single biggest success factor in using the ticket tracker. It encourages people to open tickets if the KNOW that they will be notified of major state changes.
  • Should only be closed by the person who opened it.
  • Should naturally display the history of the ticket. (see FogBUGZ demo for a great example)
Other nice features for tickets:
  • Ability to subscribe to defects and get email notifications of all updates as it moves through the cycles. This is a big wishlist item for me.
  • Attach Files to tickets. Useful files include screenshots, test data that shows the ticket or links to documentation about what it should do.
  • Estimate Tracking: How long will this ticket take to finish from its current state? This is especially helpful for distributing the estimation of a project or figuring out how busy people are.
  • Work tracking: How long did someone spend working on a ticket. At Civilution we modified the intranet and the ticket tracker to do all hour logging through tickets. We then made a new class of ticket call ongoing that never closed (issues like company meetings) and everyone would log hours to those tickets. This worked pretty well.

Hints for using tickets in an org:

  • Make the Severity ratings mean something and only use Severity ratings with meaning. There is no magic bullet for this, you have work out what the levels mean for your organization and think about ways to teach people.
  • As a developer, refuse to work on issues that are not in the ticket tracker. If it can't be fixed while you are on the phone with the client, it should be tracked. The ticket tracker needs to be the canonical place for issues.
  • Give people an easy why to see: Issues assigned to them and issues that they opened. These are my two favorite views for chasing down tickets.
Workflow

The basic workflow is pretty easy:

Someone, lets call him Client Chester, requests a feature or reports a defect. This ticket gets assigned to Project Manager Mary who is responsible for that area.

Mary may fix the ticket, assigned it to Denny Developer to fix, schedule it for a future version (getting it off the immediate plate), request clarification, or decide that its not worth fixing. (FogBUGZ has a pretty elaborate system of Sinks, We just closed tickets and didn't pay to much attention to if they were closed because it was by design or we just weren't going to fix it.)

After a Mary or Denny "fixes" the ticket, it goes back to Chester who is responsible for closing it and being satisfied with how the situation is resolved.

This basic system works great for features too, a someone can request a feature and they have to review that the feature was implemented satisfactorily before they can close the ticket on that feature.

We had a couple of other tweaks here at Civilution. Hot fixes to production servers had a slightly more complicated workflow:

Client would open a ticket.

Dev would fix on dev server.

Client would approve on dev server.

Dev would prop to production.

Client would optionally test on production.

Conclusions

Just to sum up, If you have good email notifications, reasonable ways to divide tickets across projects and across time (with versions or releases), and simple reliable workflow, I will probably be happy.

Thank you Musea for investing some resources in this.

Cheers,