[rt-users] RT3 Documentation: Hackers, FAQ, etc. ??? [x-text]

[Garrett Goebel]

Jim Rowan wrote:
> Garrett Goebel wrote:
> > 
> > Our company is looking to transition away from our current
> > issue tracking system. I've been hesitant to evaluate RT
> > because of its reputation for a difficult install and
> > configuration...  
> 
> RT is a dead easy install if you follow a few guidelines:
> 
> - follow the directions.  When they say "unsupported"
> understand that to mean "there have been problems reported
> which will result in trouble".  Specifically, if you use
> mod_perl use 1.x instead of 2.x, and do not use any perl
> earlier than 5.8.
> 
> (Ok, I ran out of guidelines... That about covers it!)

We'll see. But I've read reviews and more than a few posts complaining
otherwise...


> > That and lack of developer documentation for the current
> > release. I have the time to do a vanilla install, but not
> > necessarily to wade in and grok the code. However, a
> > vanilla install isn't going to give me an overview of the
> > schema, internals, extensibility, etc. I.e., what we as a
> > customer would have to look forward to and live with if
> > the vanilla install looks promising.  
> 
> Grokking the internals is not necessary if you are just
> planning on using it.

Hah! I'd love to just use it. Unfortunately every department has different
needs and even where they don't, they'll want to paint the bikeshed a
different color. No... I know whatever we use will be customized
extensively.  That's one of the reasons RT showed up on the radar. It has a
reputation for being developer friendly to change.


> The interfaces are reasonably clear, it is full-featured,
> exceptionally custimizable via gui interfaces, and basically
> "works out of the box".   The install directions are
> perfectly adequate for people willing to read them.

That's fine and good, I just wish schema, api, internals, and customization
howto's were documented. And I'm sorry, but I've scanned the RT3 manual and
it doesn't really go there. I only have so much time to burn evaluating
stuff...


> If you are planning to do *development* on it, although it
> is not documented as well as everyone would like (have you
> seen ANY product that is?), the code is modular, well-
> structured, and straightforward to understand and modify,
> once you understand the paradigms used.  In fact, it is
> designed so that you can replace parts of it with routines
> of your own.  It is very rare to find a product go to such
> lengths to make that possible.  In reality, I have found
> that the RT2 docs do a fair job at describing it, although
> there have been significant changes.

I have worked with Clientele which is a Customer Relation Management (CRM)
application. And it is well documented and extensible. About as close to an
open source product as I've seen from the prospective of providing access to
the change the code. I could modify it to do defect tracking, etc. except
it'd be overkill and costly in per user licensing for simple issue tracking,
defect reporting, etc.


> > Currently, I'm left to read the RT2 developer docs and hope
> > RT3 is only different in "better" ways. The window of
> > opportunity at my company is slip sliding away. I guess I'll
> > go ahead and see how far I get...  
> 
> If your window is slipping, go install it and quit talking! :)

Indeed.


> > Even if the IS guys like the demo... And I don't mean to be an
> > ass here, but I can foresee the objections I can expect to get.
> > They're going to visit the bestpractical website and see less 
> > documentation than they're used to and no convenient access to
> > a knowledgebook. If they're patient enough to navigate the 
> > website, they'll eventually find more documentation on fsck.com
> > /rtfm. But the click paths between sites aren't always short, 
> > consistent or obvious. Then perhaps they'll visit the fsck.com 
> > homepage itself, and the impression that will be formed when 
> > they realize how intertwined the company and Jesse's personal 
> > website are, will be of a one-man shop operating on a shoe-
> > string. 
> 
> Many of these issues might have some validity.  Maybe you should 
> just spend 100K on Remedy?  Alternatively, consider the situation
> if you paid Best Practical 100k for support.  (I would argue that
> the latter is a better business decision in many cases..  If you
> like, your company can hire me to tell you that. :)

And that I fear is what we'll do. Lock ourselves into yet another system and
watch it go south. I'm quite certain we'd buy a service contract from Best
Practical. Though probably not on the order of 100k. Though, we've certainly
paid more on consultants for proprietary systems that still haven't produced
results.



> If your IT org is not accustomed to using high quality open source
> software, then yes -- you are likely to have a problem selling it.
> (Don't blame RT for that.)  If open source is already accepted,
> stick to the question of whether it is high quality or not.  You
> won't have much of a problem. 

We're on the cusp of opening new possibilities. Bad impressions formed now,
could have long lasting impact and future adoption of open source solutions.

--
Garrett Goebel
IS Development Specialist

ScriptPro                   Direct: 913.403.5261
5828 Reeds Road               Main: 913.384.1008
Mission, KS 66202              Fax: 913.384.2180
www.scriptpro.com          garrett at scriptpro dot com
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20031203/db37982b/attachment.htm>