[rt-users] P.R. criteria

[Tobias Brox]

>    Criteria for Problem Reporting Systems 
>      * basics
>           + all software involved (interface, main system,
>             database, etc) must be GPL-compatible unless that
>             seriously hinders practical selection

GPL as in Gnu Public License?  Wouldn't it be better to say "free"?  RT
is.

>           + must have an excellent developer support community,
>             willing and able to actively accept change requests
>             and patches. very important.

I think that applies to the RT community.  Well, the split between the
stable version and the development version is uncomfortably big at the
moment, so it's mostly only me and Jesse that's working at the development
version.  Anyway, we hope to be finished before June with the next stable 
release, and I also hope the migration from 1.0 to 2.0 will be painless
for the users.  We also hope to have a development version out pretty soon
which can actually be used by those who has the guts for it.

>           + not exclusively oriented on software development.

RT is more a request tracker than anything else.  It can be used
for bug tracking and project management, but it's not a good tool for it.
My organization will produce patches making it easy to make links between 
RT 2.0 and Bugzilla, and I hope RT 2.2 will pay more attention to bug
tracking.

>             configurable for all general problem-reporting tasks

I think RT 1.0 is a good tool for "problem reporting tasks", though the
configuration could have been more flexible.

RT 2.0 and particularly RT 2.2 will be more flexible and more easy to
hack on and extend with locally developed modules.

>           + integrate with source code repository -- "what patch
>             is associated with this bugfix?"

RT 1.0 can't handle that very well.  RT 2.0 will have general "links" that
can be used for whatever.

>           + integrate with billing system
>                o lets people buy support
>                o lets us farm out support

RT 2.0 will have a "billing field".  It should be trivial to integrate
with a billing system.  The 2.0 code allows site-specific "plugins" to be
executed after a transaction is done.  I also hope we can manage to make
links that goes from one RT installation at one site to another RT
installation at another site.

>      * user interfaces
>           + www
>           + maybe command line (probably through RDBMS)
>           + email interface

We have those, though I think there might be some bugs with the mailgate
in 1.0. An administrator can also operate it through the DBMS frontend,
though we have admin tools for that (in 1.0 ... fixing the admin tools for
2.0 is not our top priority at the moment). 

>           + maybe open standard application like tcl/tk

Somebody has made an X version that builds on the cli.  It's not unlikely
that we will have an X version that builds on the perl libraries some time
in the future.

>           + easy enough to use, operable by external parties and
>             the random public

With the admin tools for 2.0 in place in June, it should be pretty easy to
use, yes.

>      * database interface options
>           + database-neutral (maybe perl-based for DBI)

1.0 is built around mysql, though hacks exists for getting it working with
other DBMS'es, among those PostgreSQL.  2.0 should be neutral, though we
(me and Jesse) will probably only priority that it actually works with
mysql.  The problems are just some small differences in the SQL DD syntax
(that is, the database schema might need some modifications), and also a
problem setting and finding the right id at rows (MySQL has
"autoincrement", probably other DBMS'es have similar systems, but it might
need a tiny amount of porting anyway). 

>           + SQL RDBMS
>                o preferably PostgreSQL because of entirely free
>                  license
>                o will consider MySQL, due to not entirely free
>                  license

In 1.0, all metadata is stored in the DBMS.  In 2.0 all data is stored in
the DBMS.

>      * configuration
>           + interface configuration template,

Templates are supported for the mail interface, both for 1.0 and 2.0.

The Web UI will be template-based in 2.0.

I've never thought of having the CLI template based.

I do have some thoughts about some redesign that might do it easier to
maintain all the UIs when adding functinality to RT, but this won't come
before earliest 2.2.

> for adding new
>             categories, items, actions, etc

We have easy tools for most of this, more or less ... though it will be
more flexible and powerful in 2.0.

We also have a knowledge database which we're going to link up to RT.  I
don't think the system is working too well at the moment, but I find the
concept behind it very powerful.  Locally, we have made the possibility to
link requests to KB items.  It's done very easily when the support worker
knows about the most freqently asked questions (they actually have a
paper list at their desk they can refer to), they just write in a well
known, short tag for the FAQ item, and then they reply semi-automaticly.
That is, a reply consisting of quotes, the standard answer and some
comments is generated, and the support worker just kills off some quotes
and eventually modify the answer a bit.  It works like a charm.

>           + dependancy support between tasks

We've had that internally for a year, almost, and it works like a
charm.  2.0 will have that.

>           + the rate of its support is uncertain. Seems to be a
>             small developer base, maybe one person, according to
>             web site. Maturity of product is uncertain to me.

Argh ... that is not up to date :)  

>      * Frontdesk
>      * Front Track
>      * PRepS

I haven't heard of those.  I'd consider GNATS and Bugzilla as the most
serious competitors at the Bugtracking arena.  There is also another
serious competitor at the request tracker arena, but I can't remember the
name ... something with "Stone", I think.

>      * Jitterbug / Caretracker

I think Jitterbug is a very simple tool.  I _think_ that GNATS is not very
suitable for tracking external support, but I might be wrong.

-- 
Tobias Brox (alias TobiX) - +4722925871 - _urgent_ emails to
sms at tobiasb.funcom.com.  Check our upcoming MMORPG at 
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades, 
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)