I'm thinking about bringing back a project I first created when I was just starting programming: a local-based issue tracker.
My original thought was that I needed to keep track of tasks for a personal project, and didn't want the annoyance of configuring or using a web-based issue tracker. With many more years of experience under my belt, I've since revised the idea.
I'll probably wind up building this in any case for myself, but before I do, I want to get some feedback from the community as to whether this would be useful to anyone else.
Here's the features I have in mind:
The issue tracker's data would be saved in a standardized JSON format. This way, it could be committed to a repository, creating a networked issue tracker without the need for a web interface.
While I'd be building an elegant issue tracker application GUI for working with this JSON file, the standardization would mean that others could be built. Plugins could be created for VSCode, Atom, PyCharm, IntelliJ, Vim, Emacs, or whatever, allowing each developer to use the issue tracker from their IDE of choice.
Another advantage of this system is that, when used with a VCS, it is effectively decentralized. The issue tracker can't "go down", it never needs to be "migrated" between services, and if something happens to the remote, you've got plenty of local copies.
One of the other beautiful implications of a VCS-hosted issue tracker is that it can create an implicit connection between a commit and a closed issue, and that connection runs both ways. For example, if you run a
git bisect and find a commit that broke some functionality, you also find the issue that the breaking change was related to; it can now be reopened or amended.
Of course, if hosting the issue data on a VCS doesn't quite work for you, there's nothing stopping you from parking the file on a network share, the cloud, wherever! It's just a JSON file, after all.
I would be building Quantified Task Management fully into this issue tracker, including some of the advanced features that are impossible on existing trackers. (QTM actually got its start in my initial version of this issue tracker, many moons ago.)
The application I'd create for it would be small, fast, and cross-platform. No unnecessary bells and whistles here; just a clean, elegant, "get it down" interface. I'd also be creating a CLI tool, for those who live in the terminal.
I may also be the one to make the VSCode plugin, simply because that's the IDE I'm always using.
I can see this issue tracker as potentially useful to...
Personal projects, where setting up an issue tracker online would just be a hassle or overkill; anyone who would create a
TODO.mdcould use this instead.
Private projects where one does not desire to pay for or host a full-blown issue tracker, and cannot use most free options because they're not open source.
Academic projects, where the team would otherwise be misusing text messaging and email to track issues.
Hackathon projects, where you need an issue tracker running right now so you can just get coding!
Impromptu work projects, where you would have to cut through a heck of a lot of red tape to get an issue tracker on the company server.
Anyone who spends significant time coding with limited or no internet access, but still wants to see the issue tracker.
Anyone who doesn't want yet one more reason to leave their IDE.
I am already aware of some downsides to this idea:
First, because we'd be using a VCS, it would not be real time, and conflicts could occur. Some individuals and teams may not care, as this can be overcome with proper VCS use.
Second, it wouldn't allow non-developers to easily report issues, especially as doing so would require an external tool and the creation of a PR. This could be a negative thing for many open source projects.
However, this may also be a useful thing for teams that regularly have to "clean up" their issue trackers because of users. Phacility (the team behind Phabricator) has this project, and they've begun allowing users to post issues to a public forum, and then manually promoting valid ones to the formal issue tracker themselves.
This could also be overcome if someone creates a web interface (ironic!) with special
An officially standardized JSON format, published as a specification, so other front-ends can be built.
Quantified Task Management integration, which offers many advantages itself.
An (optional) local GUI frontend. (
trackerhas a web interface, and both have CLI interfaces, but neither have an application frontend.)
Is this something you can see using? Is there anything I'm overlooking? Share your feedback in the comments, please!