Home / server / Questions / 32435
In Process
Toto
Asked: 2009-06-27 12:17:10 +0800 CST

Issue tracker requirements

  • 772

I haven't done this for quite a while, but I'm actually going to go through the process of evaluating various issue trackers.

Starting with these requirements:

  • needs to be customizable (custom fields, custom workflows)
  • email & web gateways
  • metadata manipulation via email (e.g. close via email, etc...)
  • email notifications (on demand)
  • ability to assign default "watcher(s)" for new issues
  • support for issue classification (categories, projects, ..)
  • issue relationships (sub issues, linked issues, duplicate issues, merge issues)
  • AD integration
  • Security (for example, only allow users to see their own issues)
  • API
  • CLI interface (i don't care, but others will suggest it)

What requirements am I missing here?

evaluation

7 Answers

  1. I might add:

    • Platform (OS and programming language) depending on what you're comfortable with maintaining, or whomever will own this once it's in house.
    • IDE Integration if you're going to be using it for application issue workflows (i.e., does it interface with Eclipse or Visual Studio in a helpful way).
    • SCM Integration, again if you're going to be tracking app issues. It's nice to tie bugs or features to check-ins in your source code repository. Not as helpful for helpdesk ticket type work.

    Also, if this is going to serve a helpdesk role, perhaps inventory tracking or license tracking.

    UPDATES

    • Ability to assign default resources (i.e., technicians/programmers) as new issues come in (automated Level 1 triage) depending on the type of issue or application the ticket comes in for
    • 3

  2. Possibility to attach file.
    Possibility to use template : like create a new kind of case with a predifined list of subcase.
    Possibility to log work time on case.

    • 2

  3. Along the security lines, encryption between endpoints is important yet not always offered.

    The virtual user feature in FogBugz is quite nice. I like it better than standard groups. I would consider it a requirement having used it for a few years now.

    • 1

  4. Whenever looking at a software platform/package, it also pays to look at the support of the product itself. How quickly can bugs be fixed? Is it open source so you can fix issues yourself, or will you be reliant on another company?

    • 0

  5. A minor thing - theme/template/logo customisation. Some businesses would favour a solution that they could customise to suit their corporate image.

    • 0
    1. Whitepapers or solutions section allowing support staff to search for a known issue or HOWTO.
    2. Ticket creation on monitoring action
    3. Attaching files/logs
    4. Smartphone friendly interface for offsite access
    5. Automatic escalation for unresolved issues
    • 0

  7. A process management system flow based on ticket status (like Jira does)

    • 0