So, I'm just going to dump some things that bother me about JIRA and other options, mainly from an Ops person perspective. I don't actually think JIRA's that s

So, I'm just going to dump some things that bother me about JIRA and other options, mainly from an Ops person perspective. I don't actually think JIRA's that slow, if you actually run it on decent hardware. It's definitely not fast either, but there are slower things out there. But you want to keep your application snappy. Many ticketing systems are really bad at actually tracking e-mail conversations. JIRA works for this, but it usually makes a mess out of the original email, gets stuck in loops, redirects mail to who knows where, creates dozens of redundant tickets with no option to merge them, and so on. conflating this feature with actual work tickets is, I think, a mistake. An issue tracker that also features a good way to track external communication would be a godsend. If you are looking to implement anything like this, by all means process the messages, but also store the original unchanged. There needs to be a means of having bi-directional integration with a CMDB and a documentation platform. Being able to associate work tickets with their related resources in a CMDB is a massive time saver. Don't allow customizing workflows too much. Certainly don't allow duplicate ticket and field types that do the same thing. Holy crap it's so easy to make a mess out of JIRA, and it's really difficult to undo. I sometimes wish that I could enforce RDBMS-style referential integrity in JIRA and write migration scripts to remove redundancy without losing data... Implement native checklists for issues. Sometimes work items are too small to deserve their own tickets, but should be tracked nonetheless. Checklists allow you to have standard procedures without having to create a ton of redundant tickets that will just be resolved as "done".