FindingAnswersAboutRT

From Request Tracker Wiki
Revision as of 13:10, 8 January 2017 by Barton (talk | contribs) (Reformat sample question framework)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

Becoming familiar with RT and the resources available to answer your questions can be difficult at first. Frequently you get no answers or very terse answers which don't seem to provide enough guidance. This can be frustrating; it can seem like no one wants to help you when quite often they do.

First, do the legwork

There are a number of places to start your research before you post to the mailing list or send a note to someone who maintains some extension of RT. Here are a few searchable places, listed in order of likely usefulness:

This Wiki (the place with lots of answers)

MailingListArchives (searchable list archives)

http://www.google.com/ (I generally start "+RT +MostUniqueErrMsg")

Search there for answers to your questions. Very frequently you'll find just what you're looking for and perhaps more.

Ask the Right People

If you can't find information on the wiki or in the mailing list archives, you should generally direct your questions to one of the RT MailingLists. Generally, you'll want to direct your questions to the rt-users mailing list, as that's the right place for them (and nearly everyone on rt-devel is also on rt-users). Posting to rt-users allows you the benefit of experienced RT admins' knowledge, which will likely solve your problem much more quickly than any other approach.

The rt-devel list is for development issues such as "I'm thinking of implementing thus-and-such and wonder how I should go about it" or "I found a bug and fixed it; here's a patch" and the like.

While it's often tempting to think you've got a bug or critical issue and should immediately send it to rt-devel, most of the time it's not a bug, but a misconfiguration on your part, which results in a terse note pointing this out and directing you to do the legwork (as mentioned below).

Please don't create a wiki page to ask a question or add a question to the body of a wiki page. A wiki isn't a support group, it is an information repository. It may be reasonable in some cases to ask a question related to the specific topic of a wiki page in its "Talk" sub-page (particularly if the page content is unclear or incorrect) but as a practical matter that is unlikely to be as productive towards getting a good answer as aking your question on the rt-users mailing list, where there is a broad audience of people following the discussion. The time to create a wiki page is after you have an answer that could be useful to others in the future.

Please don't send email directly to the bestpractical.com developers. This may seem callous, but consider this: anyone with a bestpractical.com email address is trying to make a living working on RT; the rest of us have a full-time day job and voluntarily contribute to RT as we can. None of us wants to give up precious development time in order to do your initial legwork; conversely, we're happy to help once you've done it and still have questions.

Ask a good question well

Note that there's an extensive treatise on the art of asking good questions well at http://www.catb.org/~esr/faqs/smart-questions.html

Good questions are clear, concise, and demonstrate that you've done the legwork as mentioned above. They also show an presumption of ignorance on your part unless you're absolutely certain you really understand exactly what's going on. I've been working with RT for six years off- and-on and I still learn new things ... usually starting with an incorrect assumption on my part ;]

A bit of an aside: nothing blows your credibility and diminishes interest in replying quite like an it's-all-screwed-up-and-must-be-a-bug message. RT is a large, complex, mature software system and you're probably not the first person to want to use feature X. It's very likely that there are many people using that feature and they'd be happy to help you join them.

Also, choose a descriptive subject; it's your first impression and will determine who reads your message. Get the good bits early in the subject (you don't know how many characters I'll see in my mailreader). Here are some good ones (chosen randomly from recent postings):

Can rt users come from LDAP?

Installing RT on Fedora Core 4
RT VMWare Appliance
Show stalled on AtAGlance list?

Each of these gives clear guidance to the topic at hand. If it's a subject I might have unique knowledge on or a distinct interest in, I'll definitely make time to read it.

Here are some horrible ones (chosen randomly from long ago to minimize embarassment):

RT questions

Lost information
Headings
Great Program!

As you can see from these last, I have no chance to know what problems lie inside the email or whether I can provide uniquely useful information. On a slow day, I might read one of these to see if I can help. One a busy day, these go straight to the trash.

Here's a decent framework to hang your question on:

Subject: FOO config problems while trying to BAR

I'm having problems properly configuring FOO. I thought I knew how it worked, but my attempts have all failed and searching both the wiki and the mailing list archives hasn't improved my understanding enough to make it work.

I'm trying to use FOO to BAR [insert concise statement of purpose]

So far, I've tried to [insert concise summary of the saga]

I'm using RT [version] on [OS and version] with [all pertinent web server details like apache version, mod_perl/fast_cgi, etc.]

Can anyone point me in the right direction?

Give A Little Bit

If you've come up with the answer to a sticky problem, consider giving back to the community either by summarizing to the mailing list or into the wiki. That'll help the next generation of new RT admins ... and save you answering their questions on the list over and over again. ;]