4 ms·
I find it interesting that the author felt it necessary to print out the thousands of bug reports so they could quickly and efficiently sort through them. That
by gyomu 2y ago
I find it interesting that the author felt it necessary to print out the thousands of bug reports so they could quickly and efficiently sort through them.
That implies they felt like they wouldn't have been able to do the work nearly as well within the confines of the digital bug tracking system.
There is such power to spatial visualization and tangible interaction that we lose out on in digital interfaces.
This makes me think about the Dynamicland vision again...
- ajb 2y agoI have done this, albeit on a smaller scale. Partly it was easier to find useful categories with the bugs on paper, and to resort them when I found a better categorisation. I didn't use whole pages, I exported the bugs as a CSV and then used glabels to extract a few fields and lay them out before printing (on ordinary paper, not label paper, which I then cut up). Once sorted it was then easy to apply labels in Jira The other useful part was to have a physical way to show our overoptimistic boss just how much work his plans entailed
- fweimer 2y agoMore often, people create a spreadsheet with one row per bug once they encounter situations like that. It's a tool failure because these activities are of course core bug tracking tasks, yet bug tracking tools tend to be a poor fit for tracking unplanned side activities. These side activities do not match the regular state progression of bugs, so in-tool tracking requires that someone creates custom logic for the emerging separate process. Usually, there aren't resources for that. (It's also hard to get rid of the excess state and logic once the side project is done.) If you have to use free-form text fields or labels anyway, the spreadsheet option isn't so bad, despite its obvious flaws.