<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2657.73">
<TITLE>RE: [rt-users] RT3 Documentation: Hackers, FAQ, etc. ??? [x-text]</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Jim Rowan wrote:</FONT>
<BR><FONT SIZE=2>> Garrett Goebel wrote:</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Our company is looking to transition away from our current</FONT>
<BR><FONT SIZE=2>> > issue tracking system. I've been hesitant to evaluate RT</FONT>
<BR><FONT SIZE=2>> > because of its reputation for a difficult install and</FONT>
<BR><FONT SIZE=2>> > configuration... </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> RT is a dead easy install if you follow a few guidelines:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> - follow the directions. When they say "unsupported"</FONT>
<BR><FONT SIZE=2>> understand that to mean "there have been problems reported</FONT>
<BR><FONT SIZE=2>> which will result in trouble". Specifically, if you use</FONT>
<BR><FONT SIZE=2>> mod_perl use 1.x instead of 2.x, and do not use any perl</FONT>
<BR><FONT SIZE=2>> earlier than 5.8.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> (Ok, I ran out of guidelines... That about covers it!)</FONT>
</P>
<P><FONT SIZE=2>We'll see. But I've read reviews and more than a few posts complaining otherwise...</FONT>
</P>
<BR>
<P><FONT SIZE=2>> > That and lack of developer documentation for the current</FONT>
<BR><FONT SIZE=2>> > release. I have the time to do a vanilla install, but not</FONT>
<BR><FONT SIZE=2>> > necessarily to wade in and grok the code. However, a</FONT>
<BR><FONT SIZE=2>> > vanilla install isn't going to give me an overview of the</FONT>
<BR><FONT SIZE=2>> > schema, internals, extensibility, etc. I.e., what we as a</FONT>
<BR><FONT SIZE=2>> > customer would have to look forward to and live with if</FONT>
<BR><FONT SIZE=2>> > the vanilla install looks promising. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Grokking the internals is not necessary if you are just</FONT>
<BR><FONT SIZE=2>> planning on using it.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<BR>
<P><FONT SIZE=2>> The interfaces are reasonably clear, it is full-featured,</FONT>
<BR><FONT SIZE=2>> exceptionally custimizable via gui interfaces, and basically</FONT>
<BR><FONT SIZE=2>> "works out of the box". The install directions are</FONT>
<BR><FONT SIZE=2>> perfectly adequate for people willing to read them.</FONT>
</P>
<P><FONT SIZE=2>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...</FONT></P>
<BR>
<P><FONT SIZE=2>> If you are planning to do *development* on it, although it</FONT>
<BR><FONT SIZE=2>> is not documented as well as everyone would like (have you</FONT>
<BR><FONT SIZE=2>> seen ANY product that is?), the code is modular, well-</FONT>
<BR><FONT SIZE=2>> structured, and straightforward to understand and modify,</FONT>
<BR><FONT SIZE=2>> once you understand the paradigms used. In fact, it is</FONT>
<BR><FONT SIZE=2>> designed so that you can replace parts of it with routines</FONT>
<BR><FONT SIZE=2>> of your own. It is very rare to find a product go to such</FONT>
<BR><FONT SIZE=2>> lengths to make that possible. In reality, I have found</FONT>
<BR><FONT SIZE=2>> that the RT2 docs do a fair job at describing it, although</FONT>
<BR><FONT SIZE=2>> there have been significant changes.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<BR>
<P><FONT SIZE=2>> > Currently, I'm left to read the RT2 developer docs and hope</FONT>
<BR><FONT SIZE=2>> > RT3 is only different in "better" ways. The window of</FONT>
<BR><FONT SIZE=2>> > opportunity at my company is slip sliding away. I guess I'll</FONT>
<BR><FONT SIZE=2>> > go ahead and see how far I get... </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> If your window is slipping, go install it and quit talking! :)</FONT>
</P>
<P><FONT SIZE=2>Indeed.</FONT>
</P>
<BR>
<P><FONT SIZE=2>> > Even if the IS guys like the demo... And I don't mean to be an</FONT>
<BR><FONT SIZE=2>> > ass here, but I can foresee the objections I can expect to get.</FONT>
<BR><FONT SIZE=2>> > They're going to visit the bestpractical website and see less </FONT>
<BR><FONT SIZE=2>> > documentation than they're used to and no convenient access to</FONT>
<BR><FONT SIZE=2>> > a knowledgebook. If they're patient enough to navigate the </FONT>
<BR><FONT SIZE=2>> > website, they'll eventually find more documentation on fsck.com</FONT>
<BR><FONT SIZE=2>> > /rtfm. But the click paths between sites aren't always short, </FONT>
<BR><FONT SIZE=2>> > consistent or obvious. Then perhaps they'll visit the fsck.com </FONT>
<BR><FONT SIZE=2>> > homepage itself, and the impression that will be formed when </FONT>
<BR><FONT SIZE=2>> > they realize how intertwined the company and Jesse's personal </FONT>
<BR><FONT SIZE=2>> > website are, will be of a one-man shop operating on a shoe-</FONT>
<BR><FONT SIZE=2>> > string. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Many of these issues might have some validity. Maybe you should </FONT>
<BR><FONT SIZE=2>> just spend 100K on Remedy? Alternatively, consider the situation</FONT>
<BR><FONT SIZE=2>> if you paid Best Practical 100k for support. (I would argue that</FONT>
<BR><FONT SIZE=2>> the latter is a better business decision in many cases.. If you</FONT>
<BR><FONT SIZE=2>> like, your company can hire me to tell you that. :)</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<BR>
<BR>
<P><FONT SIZE=2>> If your IT org is not accustomed to using high quality open source</FONT>
<BR><FONT SIZE=2>> software, then yes -- you are likely to have a problem selling it.</FONT>
<BR><FONT SIZE=2>> (Don't blame RT for that.) If open source is already accepted,</FONT>
<BR><FONT SIZE=2>> stick to the question of whether it is high quality or not. You</FONT>
<BR><FONT SIZE=2>> won't have much of a problem. </FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Garrett Goebel</FONT>
<BR><FONT SIZE=2>IS Development Specialist</FONT>
</P>
<P><FONT SIZE=2>ScriptPro Direct: 913.403.5261</FONT>
<BR><FONT SIZE=2>5828 Reeds Road Main: 913.384.1008</FONT>
<BR><FONT SIZE=2>Mission, KS 66202 Fax: 913.384.2180</FONT>
<BR><FONT SIZE=2>www.scriptpro.com garrett at scriptpro dot com</FONT>
<BR><FONT SIZE=2> </FONT>
</P>
</BODY>
</HTML>