3 ms·
I'd like somewhat less emphasis on closing tickets and more on a big picture. Not everything is best represented as a ticket, but JIRA has tended to make manag
by cryptonector 8y ago
I'd like somewhat less emphasis on closing tickets and more on a big picture.
Not everything is best represented as a ticket, but JIRA has tended to make management think it can get useful data from it, and that the useful data is "tickets closed" or "time logged". Then employees just optimize for that...
Now, one can have tickets open for the purpose only of tracking work towards larger goals -umbrella tickets if you wish- and structure as much work as possible this way. This is cultural, not so much about the technology, but it needs to be widely adopted. Then you can have task, trouble, bug, etc. tickets that you fit (or don't) into these structures.
Customization of various things is important, most notably ticket status. JIRA does have that, but it'd be even better if it came with good statuses to begin with.
CLIs please. REST JSON APIs please. Email->ticket->email please.
- jasonpeacock 8y ago^this. You get what you measure. To design a better issue tracker, figure out what you need to measure for success and then design a tool to measure that track changes that drive improvements in those metrics. For example, "feature completeness". When you achieve N of M features complete then you have an Alpha release - now build something to track the progress of those features. The same for bugs - they're really an aspect of your overall product quality. Figure out what quality metrics are important and build something to track the progress of improving those metrics.