On bug-tracking… (draft)

Michael Stone, November 19, 2011, , (src), (all posts)

Earlier this week, my friend Brian offered me a gentle provocation on the subject of bug-tracking, to the effect of “so what did you think of ESR’s post on decentralized bug-tracking?”. As partial payback, here are some… “initial thoughts”. :)

  1. Who uses bug-trackers, anyway?

    Coders? QA folks? Project and release managers? Packagers? End-users? Business folks? (Wedding planners?)

  2. What do people do with bug-trackers?

    So far, I’ve seen bug-trackers used as aides for: memory, control, coordination, traceability, planning, scheduling, abstraction, reification, estimation, inference, annotation, and workflow implementation.

  3. What kinds of bug-trackers exist?

    So far, I’ve personally used or seen others use:

    • flat files & dirs (classic TODO)
    • tree-files (org-mode)
    • spreadsheets (Excel)
    • mailing lists (LKML)
    • web-accessible mail threads (Debian BTS, Roundup, RT)
    • webified relations (Bugzilla, Google Code)
    • webified pluggable relations (Trac, GForge)
    • wikis (Mystery Hunts)
    • cli-fronted dvcs-controlled flat- or tree-files (be, ditz)
    • scrapers (Launchpad, OpenHatch)

    to track issues. Wikipedia lists several more implementations, but they don’t seem to cover much additional ground…

  4. Step back a bit…

    As we can see both from my list and from Wikipedia’s, bug-trackers are basically (data structure, protocol) pairs. As a result, they come specialized for specific queries, attributes, message formats, and data-size regimes. Most appear to pick 1-3 interfaces from the set (Web, Mail, Unix, IM), 3-5 queries from the set (point-query, range-query, top-k-query, aggregate-query, insert-one, update-one, update-many), 1 size regime from the set (n < 100, 100 < n < 10,000, n > 10,000), and 1-20 attributes with codomains of possibly-enumerated, possibly-ordered, possibly-linked small strings or numbers.

  5. An interlude:

    “Decentralization” is not opposite to “centralization”. To see this, consider Ubuntu’s Launchpad instance. Is it more “centralized” or “decentralized”?

    To me, it seems to depend on where we choose to draw the boundaries around “the instance”. For example, on the one hand, Ubuntu’s Launchpad is very centralized in ESR’s sense in that it clearly a timely rendezvous point for a far-flung community. On the other hand, it’s quite decentralized in that you can update it by updating any of a large number of watched bugs in other distro and project bug trackers.

    (Q: How much of the variation we see in bug-trackers can be attributed to variation in the cognitive and organizational challenges facing the populations of people who deal with software?)

  6. To be continued…