-4

Yes, its kind of a stereotype that this question crops up in a Unix/Linux forum, but I need reassurance on this, i.e. I have an idea.

I do not as much mind the questions as I mind the diverging answers. If the question is asked so that it can be answered by a pointer to the manual it should be. If there is a more specific problem, the question needs to be refined. Instead we see elaborate approaches to trivia and implied problems the original question never described. Even if this yields interesting things, nobody would find it when they need it, as those things would be hidden behind a trivial question, in title, tags and body.

I think this has grown big enough to constitute a problem. It clutters the platform, binds a lot of time and undermines this sites approach to be a good platform for finding information. This problem is exacerbated by the fact that markup, a nice introduction and 1 or two implied problems often yield more reputation than a (correctly and adequetely used!) simple plain pointer to the manual.

I think we need a generic, polite and educating way of telling people to read the manual. Maybe some sort of special flag where one can vote to close the question by providing a link to the manual. Better, a link to the manual and an excerpt with the relevant information. Restricting this to one link to one manual also limits the applicability so that this doesn't become a tool to slap people around.

If the answer isn't as simple as a link and an excerpt its a valid question requiring an elaborate answer, IMO. If the question is closed following a RTFM-vote the link to the manual and the excerpt are posted as first answer.

This avoids redundancy, showcases the potential of manuals (who teaches this to people?), answers the question and gives people direct access to more knowledge on the topic at hand ... the manual.

To have questions in here:

  • Is there a problem with a flood of trivial questions on UnixLinuxSE so that we need to react?
  • Should we introduce a method to propagate the use of available information?

And on a wider scope: Does anybody else see the problem I describe?

  • 3
    Can you highlight some sample Q&A's? Not to point blame but to put some examples to your point, otherwise it's difficult to know exactly what you're pointing out. – slm Jan 27 '14 at 13:46
  • I understand the RTFM temptation but I think if you feel that way about a particular question that isn't also, e.g., a duplicate, then maybe you should move on and leave it to others to answer. If you feel really strongly, the downvote button does mention "lack of research effort" as a justification. I didn't downvote this, BTW -- that seems inappropriate for a reasonably expressed question. – goldilocks Jan 30 '14 at 11:06
9
Is there a problem with a flood of trivial questions on UnixLinuxSE so that we need to react?

Not that I am aware of. In fact, taking all of the questions asked on the site, irrespective of their quality, I would struggle to apply the adjective "flood".

Yes, there are questions that are regularly asked that exhibit at best an introductory understanding of Unix & Linux, but the wiki is designed to cater for all levels of understanding.

What is important is the quality of the answers. Quoting the most relevant part of the manual can be both enlightening (in terms of addressing the immediate issue at hand) and also educational by way of teaching someone how to use manuals.

Should we introduce a method to propagate the use of available information?

We have a method already: quality answers. The best answer, no matter how apparently trivial the question, can always highlight some additional information (like the history of the command, or how it works across different shells or platforms).

If the question is especially uninteresting, you can always edit it to fill it out and provides some broader context for it that may not be evident to the original poster (as long as the intent is not corrupted).

If you are really desirous of conveying the message that the answer is well documented in the manual (or some other source), then just say that as part of your answer.

Of course, there are always exceptions...

  • 1
    +1 Esp. for making explicit the significance of "teaching someone how to use manuals"; doing it well by example counts, whereas just saying "Go read it" is at the low end of a pedagogical spectrum. – goldilocks Jan 30 '14 at 11:02
  • A quick personal note: It was when I starting telling my MaraDNS users "RTFM" quite a bit on my old MaraDNS support mailing list (e.g. woodlane.webconquest.com/pipermail/list/2009-July/000338.html ) that I knew it was getting time to stop using a mailing list for MaraDNS support (I now use a MyBB forum) – samiam Feb 2 '14 at 14:04
2

As a related issue, here is an example of me politely telling a user to STFW (Search The Fine Web, the 21st version of RTFM):

Note that I normally don't do STFW answers, but I did one here because the question was a little unclear, so I answered the question with a tutorial on how to SIGKILL processes until the person explained his problem was different (editing the question).

Another point where a lot of technical people can be, in my opinion, rude, is when they say a working solution is "incorrect" or "wrong". I think it is far better to say "I would not do something that way because XXX".

For example, let us suppose was complaining that processes were not terminating via the kill command, and someone tells them to always run kill as kill -9. Instead of saying, in a comment, "That is wrong. Always try to TERM a process before giving it a KILL signal", I would instead say "That is not how I would do it. If I send a KILL signal to a process, the process will have no opportunity to save its data before terminating. I prefer to send a TERM first, and only a KILL if a hung process ignores TERM signals."

(If topic drift is not allowed in meta, go ahead delete this "answer" and I will convert its contents in to a new "question")

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .