Effective, cooperative bug escalation

Overview

Development and support are aligned on the same mission: deliver a product that customers love using enough that they'll not only pay us for it, but become engaged evangelizers for it.

While the developers are busy writing code, support should offer input on issues affecting customers in an actionable format. This document is an attempt at responding to the reality that, since we are always adding features to the product, there are likely to continue to be more bugs than will be fixed.

Rationale and Current Practice

Fixing every bug, while it has some appeal to Support, is not practical and is not an explicit goal of the development org. In light of this, support can offer to help development in picking up the most effective bugs they have bandwidth for. A neat side effect of this project will be that we'll have a better tool to show how many bugs go unfixed, which could enable a better discussion about prioritizing sustaining work versus feature development.

Once open bugs top a few hundred, triaging incoming bugs becomes a time consuming task with many gotchas, for instance:

Currently, support and development spend a non-trivial amount of time in synchronous fix/wontfix bug decisions, yet the developers are left without a single "most important bugs" view that is usefully pre-sorted without additional human input (dev: got time? pick the top one from this list!)

Goals

This project has the following explicit goals:

  1. Improving the process for identifying how important support thinks bugs are (The current system is manual and ignores customer size and # of reporters)
  2. The process must be functional for both engineering and all of customer success - both support's "typical" priority bugs, major issues, as well as sales escalations.
  3. Support must be able to commit to completing our role in this process as scheduled (e.g. daily/weekly/monthly)
  4. This process must be amenable to change, so to start with we aim small yet flexible, and go for "good enough" vs "perfect"

The Details

Some parameters for the process:

Immediate proposals

Eventual Proposals

First steps