This is for fellow builders and project managers.
Gissue freshening is important and powerful (and it seems like it’d be very hard to achieve without Beeminder yay Beeminder). I think of it like doing Anki on the backlog of open issues in our bugtracker. Every day, I have to grab the oldest 5 non-snoozed gissues from our backlog of (currently) 437 and freshen them. Freshening a gissue means improving it in some tiny way that makes GitHub update the last-modified date. That might include updating the labels, tightening the copy in the top-level description, clarifying the title, or adding keywords for easier future searching. If there’s nothing to improve and the gissue is still not a priority and I’m ok letting it go out of sight out of mind, I can snooze it by applying the “ZzZ” label to it.
With 437 gissues and freshening 5 per day, I’m cycling through the gissues every 87 days, so every 3 months. The biggest value in doing so is I mostly remember all the gissues. When we encounter bugs, I can find an existing gissue instead of creating a new one. That keeps the backlog from getting more and more overwhelming and crufty. Also I can add links in the gissue descriptions to related gissues – a common improvement to make when freshening.
Even without appreciably whittling down the number of open gissues, I feel drastically better about them than I would otherwise.
A common and very fair objection we hear to UVIs is that they distract you from deep work and bigger features that can’t be built in a day. My opinion is that it’s worth the tradeoff. And normal companies can just dial the slope down until it’s not impinging on deep work. In our case I’m resistant because of some pretty huge don’t-break-the-chain psychology. We’re hitting 4000 UVIs around new years or so!
An idea we may try, to reduce the UVI burden/overhead, is doing UVI Fridays where we do hourly tocks and try to crank out 7 UVIs in one workday. Or usually fewer than 7 required since deep work typically yields UVIs too and we just need to average 7 per week. Again, if you’re not wedded to exactly 7 UVIs per week every week forever and ever, just dial the slope until the tradeoff feels right.
(We have a lot more thoughts on UVIs and something we call the Anti-Cobweb Principle. Expect another blog post eventually. There’s a very old one we still like in the meantime on my old blog.)
I don’t know how to articulate this part yet but Part One and Part Two feel connected in that there are so many small issues that come up and it can feel discouraging and overwhelming how fast they appear and I don’t know how to triage them. But the UVI goal means steady pressure to pick up a lot of those and that feels like good and important pressure.
In conclusion, you should have a freshgish goal, as I call mine, to cycle through your backlog, touching and improving the oldest items. I actually do this for several things besides Beeminder’s main GitHub repository. Also you should absolutely beemind user-visible improvements to whatever your primary project is, if it has an audience of some kind. Steady visible improvement plus triage and not letting things go out of sight out of mind. And just scrolling through that changelog when you’ve built up years of history is immensely satisfying.