OTRS as an issue/bug tracker

[voiprodrigo]

Hello all,

I'm starting a OTRS4 deployment focused on incident management for external customers.

I was wondering if someone here is also using OTRS as a simple issue/bug tracker, and has some ideas / best practices regarding that kind of implementation?

Thanks!

Regards

[crythias]

In *general*, helpdesk ticket management is intended to be personal/private. That is, an environment where items addressed are uniquely tailored to the customer, and the customer's situation.

On the other hand, a bug tracker is on the face of it, nearly the reverse. It's (sometimes/usually) intended to be a place where random person, who may or may not be anonymous, adds "me, too" or can review the status of an incident that may affect everyone who uses a specific resource or version/release of software.

Is OTRS good for that? Not if you want the bugs/issues to be public knowledge, such as the case of http://bugs.otrs.org. Why are they using BugZilla? Because it's a community effort to report and address bugs. It's important to know if the bug has been previously reported, and to find out what the response has been for that incident/problem. A customer in OTRS can't find out (outside of FAQ) the status of an issue, or that other customers have reported the same issue, so duplicate related tickets might exist.

It's the difference between one issue for everyone versus everyone having their own, but the same, issue.

[voiprodrigo]

Thanks, and I do agree with you. But I should have been clearer in my question, because the case here would be a private bugtracker. Customers will have access to submit incidents, in the classical way, as part of a support service covered under SLA. But I'm considering to have them also submit bugs for something under acceptance testing, in a pre-support phase. Note that this is in the context of a software development company.

[crythias]

It appears that you will be the best judge of OTRS's usefulness in your criteria.

[voiprodrigo]

Yes, ultimately, that will be the case, for sure. But the objective of my question was to maybe gather some feedback about how other people may have eventually made that kind of setup.

[crythias]

Are you intending to personally respond and log responses to bug submissions? Is your intention to have permanent record of the correspondence on the bug reports? Do you need statistics about when the bug reports were opened and do you think you'd be able to effectively link tickets between customers on a common bug? Even if you do link tickets between customers, you still need to figure out if there's a specific bug (what number?) that is legitimately the same across customers and release. And you need to determine how to integrate that the solving of the bug closes all those tickets (Master/Slave?). Or do they close upon submit?

Is it important that a single bug is open or that multiple tickets on the same bug are open? Do you care about SLA? Does a new bug report on the same bug change the SLA?

A bug tracker focuses on one bug at a time, no matter how many people have problems with the bug. A ticketing system focuses on one customer at a time.

[voiprodrigo]

Those are all good questions. Before anything else I'll need to study better the requirements of the bug-tracking process in order to be able to assess a possible translation to OTRS. So, something to return to later.

Thanks for your input!