One of the things that I try to do with my projects is to create quick, iterative releases. When it comes to client work, I’ve made a lot of progress with this over the past year; however, when it comes to working on products (be it plugins, themes, or something similar), I’m not as good as I’d like to be.

Nonetheless, I’m still working on it and one of the ways in which I’m trying hard to focus on that is through creating a system of bug ticket triage.

Sounds all fancy, right?

Sounds fancy.

It’s not :).

Basically, it’s a way that I sort tickets as they come into the support channel and decide how I’m going to be resolving them according to their level of severity.

Though I don’t think there’s a definitive way to do this, I thought it might be worth sharing how I’ve been doing this with Mayer (as well as some other client projects) in order to try to create the leanest release experience possible.

Bug Ticket Triage

To be clear, the whole “triage” verbiage is not my own – it’s something that I picked up when reading other material and when working with other teams. I just happen to like it.

After all, it explains the act of what’s being done, so it’s the whole “if it ain’t broke…” cliché.

Anyway, before I get too far into this, I should explain that I try to use semantic versioning in my projects. I also try to make sure that I scope milestones so that they are small (in terms of tickets) and lend themselves to quick, iterative releases.

Aim for that unicorn milestone!

Aim for that unicorn milestone!

But for anyone who has worked on selling a product, you are familiar with the fact that just as soon as you define your roadmap and/or set of milestones for the project, bug tickets will come in and derail whatever plans you’ve made.

Don’t see this as a problem or a frustration. Instead, see this as others finding bugs you were unable to shake out that will make for a more robust product.

Sure, you sometimes have to discern the signal from the noise of what’s a “nice-to-have” and what’s “must-have” or a “must-fix,” but if you’re able to do that, then the end result of your work will be a product of higher quality.

But it’s likely that none of this is news, so here’s the approach I’ve taken to handling roadmaps, bug tickets, and general bug ticket triage for WordPress themes.

1. Set Milestones

Seems like a given, right?

The thing is, I don’t think you can really wait to set the roadmap for your project. For those who have read previous articles, you know that I’m a fan of what I call the “strong 1.0” which is creating a lean first release that consists primarily of the core features required with a backlog of the rest of the features.

This gives the product a roadmap (or a bit of a lifetime) and makes it easier to focus on the foundational aspects of your work.

From there, you can then lay out what features will build on top of the initial release. Most of the time, I think that features can prioritize themselves.

For example, in the context of WordPress themes, introducing a feature into the Theme Customizer than improves something that already exists is predicated on actually have features in the Theme Customizer, right?

So usually, I’ll hold those features off until 1.1.0 or whatever the next release is.

Setting milestones gives you the ability to not only set a schedule for releases, but also to give yourself some runway as to continually improving your product.

After all, people love seeing improvements, right?

2. Squash Bugs

This is the part that frustrates developers the most, I think. “Bugs get into the way of features,” we say.

Well, sort of. But wouldn’t you rather have a more stable foundation off of which to build your new features rather than building your new features on code that’s buggy to begin with?

To be clear, I’m not advocating releasing a 1.0.0 without actually testing it with a team of beta testers, but I am saying that it’s probably worth reworking your milestones so that bugs are fixed before moving on to the next feature.

Unless there's a bug in your bug reporting.

Unless there’s a bug in your bug reporting.

Because, in many cases, bugs are generally only going to be related into one of two areas:

  1. The first version that was rolled out (because where else would they live?)
  2. Code that you just released that had a regression on previous work

Yes, there are times in which bugs can crop up and impact issues from versions ago, but assuming that you have good practices in place to begin with such as beta testing, continuous integration, and quick releases, this seems to happen much less than in alternative scenarios.

To that end, always be flexible in terms of how you structure your roadmap. What new features you may be planning for 1.1.0 or 1.2.0 may not be able to be completed until you’ve triaged incoming support requests from 1.0.0 or 1.1.0.

The nice thing is that semantic versioning makes it easy to fit these into versions without totally derailing your milestones.

For example, let’s say you’ve just released 1.3.0 and you’re looking to release 1.4.0 a month later. But, whoops, someone submits a few bugs they’ve discovered with a particular browser or some feature that you integrated in 1.3.0.

You can triage the issue(s) in a number of ways:

  • If they are hotfixes (that is, functionality-critical problems), you can release a `1.3.1`.
  • If they are minor fixes that may go well with a batch of new features, include them in `1.4.0`.
  • Or, if it’s a number of bugs that will require, say, some changes to core but not introduce any new features, simply bump `1.4.0` to `1.5.0` and make the new `1.4.0` the bug fix release.

Don’t let your roadmap and your commitment to your milestones get in the way of you focusing on making a more robust product for your customers.

3. Is It Important or Urgent?

Earlier this month, I shared a few thoughts on the idea that everything is important, but not everything is urgent and I stand by that especially as it relates to bug tickets for WordPress products.

For anyone who has worked with support for their products, you know that some customers – not all, of course – treat very minor details as the most significant thing in the world. Now, I don’t want to say not to sweat the details – in fact, I think that’s what separates good products from great products – but think about it in terms of an emergency.

Is the feature or bug being mentioned a showstopper for the person’s blog? If not, then take the time to explain a temporary workaround, if possible, triage the ticket into the next release, bump any features that aren’t critical to this, and make this a high priority.

If, on the other hand, it is a show stopper, then you likely have a bug that’s affecting more than just this person. At that point, I believe it’s critical to create a milestone for this single bug (yep, just this one issue), and get it resolved as quickly as possible.

On a More Personal Note

Again, all roads lead back to a more robust product, and that usually obtains or retains a customer base.

But I mention all of this primarily because early in my career, I treated everything as urgent. The problem, as you can already guess, is that if everything is urgent, nothing is urgent, and if you feel that it is, then the work becomes significantly more stressful.

There’s no need to subject ourselves to that.

Care about your product, care about your customers, but also care about the work you’re putting into the product for your customers so that you’re not rushing things out of the door as a quick fix.

Instead, you’re truly understanding the problem, resolve it, and moving forward with a stronger foundation.