I created something similar when I had to work in an extremely resource-constrained project (we could only work by ssh'ing to a server with no graphical utilities, and no internet access other than ssh). It has worked like a charm, and I would find it difficult to go back to anything else for ticket management now. I use this for 'in-project tickets/milestones' and leave stuff like github issues for 'external' issues by users.

Here it is on github for anyone who's interested: https://github.com/tpapastylianou/bashtickets

My tool is slightly less minimal than the one in the article, but essentially the same philosophy. Everything is a local file following a simple but fixed template, so that they can be grepped / manipulated if necessary. It plays very well with versioning, and supports milestones and 'advanced queries' as pre-made scripts. Obviously, since the tickets/milestones are simple text, it should be fairly straightforward to write your own queries if you know a bit of bash (or any other language you prefer, obviously).

In fact, this little system has worked so well, that I have recently been trying to convert it to a nice, portable, "command-based" tool, i.e. the way git works; bashtickets init (or just bt init) initialises a ticket repository, bt new ticket creates a new ticket, bt list lists open/closed tickets, or active/completed milestones etc. There's nothing wrong with the original, of course, except for the fact that it's a bit ugly to have a bag of scripts in each ticket repository you want to manage. A command-based interface simply makes it look a bit more 'modern', and clean, putting any pre-made scripts and 'template' files out of sight for peace of mind. This is still very much under development, but please see the "commandbased" branch if interested [1]. I'd be very open to feedback :)

  [0] https://github.com/tpapastylianou/bashtickets

  [1] https://github.com/tpapastylianou/bashtickets/tree/commandbased