Ask HN: What would your ideal issue tracker look like?

Currently I use Fossil (which is not bad, but there could be a better way (possibly even modifying Fossil to support such thing), I think).

If it is on a remote server, support using a SQLite virtual table to access it (this does not mean the server needs to use SQLite to store the database, but only that it supports the equivalent of xBestIndex) (for local data you can just use a SQLite database without a virtual table), then you can make up your own queries (although you may need authorization to post messages, to view them shouldn't need authorization). A command-line interface to file issues (as well as to view/download them) is also helpful, and perhaps a HTML interface too. Use whichever interface works best for your use, or all of them, if needed.

Fogbugz/Kiln had a variation of this. You could easily see which branches a particular commit was in and it was tied back to the ticket as well. It didn't influence ticket state, but it was easily cross-referenceable.

The basics should be simple enough to sync cleanly to org-mode and it should have the api for it at least!

Kanban, assigne (maybe as tag), tags, custom text-fields, custom date fields and that should be it.

I'm slave to atlassian, but for you trello folks: https://github.com/org-trello/org-trello

A definable FSM with a fixed set of transitions. Webhooks for each. Tagging, integrated or not into the state machine. Integration with branches and commit messages. GitHub issues is close.

Ideally the whole thing is in git or sqlite or json.

It should have a proper bidirectional email interface.

I guess you were more thinking about the view of a developer of the product or project, but what I hate with a passion is when other people expect that I create an account on their issue tracker and then use their user interface for what for all intents and purposes is writing them an email. Even more fun when that includes the need to enter into a contract with a third party (like GitHub) and you would have to read pages and pages of legalese first.

If you want to have some UI for managing bug metadata, great, I don't mind, but don't expect me to use your UI. A bug tracker in some regards is a sort of specialized electronic messaging program. If you use Thunderbird, you don't ask me to "create an account with Thunderbird" or to install Thunderbird, you simply hand me your email address, and I use my MUA to send you an email--which you can read and archive and whatever in whatever MUA you prefer. It makes no sense to handle issue trackers fundamentally differently.

But the same at least to a degree also applies for the developer side of things. While some of the issue tracker functionality probably is not a good fit for email, a lot of the day to day stuff very much is, and that even includes some of the management of metadata, so a good issue tracker should also have at the very least a bidirectional email interface, optimally with the possibility to manipulate bug meta data via email as well--see the Debian bug tracker for an example of a very powerful email issue tracker interface.

An issue is essentially a thread, and as such, it should be mapped to an email thread, where you can reply to previous messages just as you can to any other email, without the need to switch to a different user interface.