Complete.Org: Mailing Lists: Archives: discussion: April 2000:
[aclug-L] Re: Asking questions (Was Re: RTFM)
Home

[aclug-L] Re: Asking questions (Was Re: RTFM)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: discussion@xxxxxxxxx
Subject: [aclug-L] Re: Asking questions (Was Re: RTFM)
From: Carl D Cravens <raven@xxxxxxxxxxx>
Date: Sat, 15 Apr 2000 22:41:36 -0500 (CDT)
Reply-to: discussion@xxxxxxxxx

On Sat, 15 Apr 2000, Jonathan Hall wrote:

> There are certian things that need to be done when asking a question.  And
> certian things that should be done BEFORE and AFTER asking a question. 
> Whether the question be on this list, another list, usenet, ACLUG meetings,
> or any other meetings.

A good post, Jon.  I'd like to make a comment here... people shouldn't
feel bad about not knowing how to ask questions.  It takes a little
experience to figure it out.  Knowing how to provide the right information
doesn't come naturally to everyone.  

I participate on the HP-UX admin mailing list.  These are all
*professional* system administrators... some of them very experienced,
some of them are operators or techs that got thrown a manual and told,
"our sysadmin quit, congratulations, you're our new sysadmin."  Some of
them are *terrible* about asking questions... they don't know the first
thing about what to tell readers about their problems.  And it isn't just
the new guys... some very experienced admins still don't know how to ask
questions.  It's a skill, just like anything else.  Fortunately, it's not
a time-consuming thing to learn how to ask questions.

The more questions you ask, the better you can become at asking questions.  
When someone asks *you* a question about your problem, pay attention to
what they're asking.  Next time you have another problem, ask yourself if
you've missed anything similar to the questions you've been asked about
previous problems.  "Oh, yeah... they wanted the log entries from
sendmail.  I bet log entries from for named might be useful in solving
this problem name resolution problem."  That kind of thing.  Don't just
look for an answer to your problem... look to learn how the problem was
solved.  What thought processes went into it, what information was needed.

The heart of asking questions is, "Help us to help you."  The more
relevant information you can give, the easier it is for someone to help
you... and the more likely it is that you will get a response.  

The heart of troubleshooting is figuring out *where* to look.  It doesn't
take a lot of time to learn this outside of your usual learning... you
just have to be aware of it and keep and eye out for things that might be
worth remembering in the future.  

(Of course, if you're like me, you ask the questions nobody has answers
for.  I once had a question about sendmail.  After reading proper section
in the bat book and searching the FAQ and DejaNews, I wrote a very, very
detailed question to comp.mail.sendmail (or whatever that group is).  
Nobody answered.  The funny thing was, nobody answered because I'd given
all the required information... nobody knew the answer and nobody could
think of any more information to ask for that might help. 

When I asked if I was being ignored, one of the sendmail gurus answered...
and told me that he didn't know, and that the answer would be in the
source code if I really needed it.  The ultimate RTFM.  Not a viable
option for everyone, but it worked for me because I could grok it.  (And
for the record, sendmail remembers the peak load value during a queue run
and will terminate delivery for the queued messages when it reaches a
message with a priority higher than allowed for the load value if it
exceeds the *peak* value, even if the *current* value is well below the
maximum allowed load.)

--
Carl D Cravens (raven@xxxxxxxxxxx)
New Mail not found.  Start whine-pout sequence? (Y/N)


-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi


[Prev in Thread] Current Thread [Next in Thread]