Posted On: 2026-05-04
Although I've iterated on how I approach planning (both long and short term), I've recently realized that I haven't given that same level of attention to how I track issues. For the most part, this hasn't been a problem, since I use a Definition of Done that (generally) doesn't permit committing code that has unresolved issues. For the few issues that do slip through that check, the major ones get addressed immediately, and minor ones get prioritized (like any other change), but as I try to figure out what work remains, I'm wishing I had a proper accounting of every issue that was de-prioritized. As such, I've started mixing digital resources into my (previously) pen-and-paper approach, in the hopes that will help me avoid re-treading old ground when I get down to the final stages of polish.
Knowing what I needed (issue tracking) and why I needed it (keeping things tidy as I get closer to release) made it possible to focus on evaluating specific tools. After looking at a few different options, the one that seemed the best suited to my needs was the way Github handles issues and pull requests (PRs): every issue can be marked with a specific change to the code (a PR), which automatically documents how a particular issue was resolved (or any abandoned attempts to do so.) It'll be a small change to my workflow, but using PRs like that should make issue resolution effectively self-documenting, and having a digital record should make it much easier to look for problems that were resolved (or abandoned) at any point in history.
While using Github itself is not necessarily desirable for a bunch of reasons*, there are alternatives - a lot of them, in fact. Tying code changes to issues is kinda a ubiquitous need, and a lot of tools have landed on using very similar approaches to solving it. Of the various tools, I decided to use Forgejo, a community-driven, more modern fork of Gogs (which made a strong impression on me when I was considering whether or not to self-host the code for Skies Below.)
To minimize friction, I set up Forgejo so that it's hosted on my local machine*. This eliminates the latency I would normally see with an instance hosted online, and gives me a lot more confidence about where my data is and who can access it**. This approach also has the added benefit of working without internet, meaning I can continue to be fully productive during a network outage or travel.
Forgejo provides a lot of value beyond issue tracking. The projects feature looks like it will be a good way to tell at glance how much progress I've made towards any given milestone, but I am perhaps most excited about action runners. I've used something similar to handle automated deployments for this site, but having that capability in a zero-latency, offline-capable package is extremely appealing*.
Although using a local Forgejo instance for issue tracking is an excellent approach for me, I'm not sure it's something I'd recommend for everyone. Setting up a local instance was not too difficult, but neither was it plug-and-play. Using a local-only setup also brings tradeoffs (ie. only I can access it, and only via the one machine it runs on), and while I am personally ok with them, I expect they would be unacceptable for many others. Fortunately, there are a number of hosted Forgejo instances available online (though I can't vouch for any specific one), so I can still recommend using Forgejo generally, just not necessarily the specific way I've set mine up.