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.

