Site Map - skip to main content

Hacker Public Radio

Your ideas, projects, opinions - podcasted.

New episodes every weekday Monday through Friday.
This page was generated by The HPR Robot at


hpr1033 :: Go RTFM

Asking for help from others versus trying to find the answer yourself

<< First, < Previous, , Latest >>

Hosted by aparanoidshell on 2012-07-18 is flagged as Explicit and is released under a CC-BY-SA license.
RTFM, helpfulness, self-help. 1.
The show is available on the Internet Archive at: https://archive.org/details/hpr1033

Listen in ogg, spx, or mp3 format. Play now:

Duration: 00:07:49

general.

This my first show for HPR I wanted to express my feelings on why we should be able say rtfm and why. With understanding that its good for growth and that maybe not to say rtfm fully persay, but to find away say it in a positive light for the user. I type this to see people gets the point to read more then hear! :)

Comments

Subscribe to the comments RSS feed.

Comment #1 posted on 2012-07-27 12:16:36 by Mike Hingley

Alternate viewpoinr

My counter argument to the central point made by your podcast is this :

I feel almost intrisictly opposed to the stock RTFM answer - here are my reasons why :

1. Elitism This may not be intentional - but when someone says "RTFM" the subtle message it puts out is "I know the answer, but I'm not going to tell you because I do not believe you are worthy of my time and energy because you have not displayed sufficient schooling in this area". To me - this represents a knowledge elite, where those that can and do,laugh down their noses at those that can't. One thing I can't stand is elitism especially in the open source community, where access to information and resources is the ultimate leveller.

2. Puts people off It may be that the user asking that question has no background in the computer science aspects of computing, but approaches the use of computers like any other consumer device. For example : I recently fitted some smoke alarms into my house. the manual said that the light should flash every 45 seconds - but in reality it flashed every 10 seconds. I phoned the help line and spoke to a technician who answered the question. His response was much more useful to me as it answered my question directly. I now feel much more confident in my ability to work with electronics not only from this company, but from others, as I know there is an element of support.

3. Adds nothing In reality all information relating to Linux is either gathered by reading the manual or source, or through experience with the product. Therefore the stock answer to any query from anybody could be RTFM, and the chances are that there is a manual page or documentation out there that covers that subject.

4. Makes assumptions about the users RTFM assumes that the user that has made contact is indeed able to read a manual. To make such an assumption based on no information does us a disservice

5. In some instances - inappropriate for the communication paradigm If I contact a IRC help chat channel and all I am told is RTFM, then the channel could be hosted by bots which just respond RTFM. If the help chat channel offers no help, then it ceases to be a useful tool.

6. Aggressive The use of offensive language in this term makes it inappropriate for use. I always pride myself that the communications I have made within the open Source community are free from swears - I would have no problem with my parents, or grand parents, or little nieces and nephews reading what I have written.

7. Competition The point is that Microsoft, Oracle etc already have this type of facility - where questions can be asked and answered. We're competing with these companies, and therefore we need to raise the bar. Making someone slog through a reference book to find out why their network isn't working isn't competing so well.

8. Obtuse Responding to a technical query from a user with a technical acronym only compounds the issue.

I want to table something : I'd like to suggest that we censor ourselves from responding with RTFM - I'd like to ban the term, and instead suggest that we start to write things in plain english.

For example :

Oh - I'm sorry you've experienced an issue with the FOO widget under Distrix. Let's see if we can't offer some advice. It looks like the issue is , which means

There are a number of things we can try :

1. instruction 1 2. instruction 2 3. instruction 3 4. instruction 4

If you want to learn more about FOO widget, then you can find the man page by going to terminal and typing man FOO.

---

Once we have done this a few times we can start to formulate strategies to solving the issue, which we can document.

The important things I wanted to raise with my suggestion are :

1. Empathy - we are empathising with the user. This helps to establish a bond, and the user may feel happier that at least someone understood the issue.

2. Information - we are presenting the user with some basic information about the issue they are having.

3. Tasks - we are presenting some ideas that the user can try

4. Further information - we are instructing the user how to get more information about the issue.

Leave Comment

Note to Verbose Commenters
If you can't fit everything you want to say in the comment below then you really should record a response show instead.

Note to Spammers
All comments are moderated. All links are checked by humans. We strip out all html. Feel free to record a show about yourself, or your industry, or any other topic we may find interesting. We also check shows for spam :).

Provide feedback
Your Name/Handle:
Title:
Comment:
Anti Spam Question: What does the letter P in HPR stand for?
Are you a spammer?
What is the HOST_ID for the host of this show?
What does HPR mean to you?