About RTFM etiquette

Question

When is it correct to answer "Please, RTFM because this is what I'm doing to answer your question/comment?"

I must admit that sometimes I answer not formally correct questions (without MWE, which doesn't show any effort, ...), just like some other users, but I do so hoping that the answer encourage OP's effort in understanding it and LaTeX in general.

I also have to say that a lot of my answers are possible after reading/consulting package manuals or searching through TX.SX because my memory is not good enough to remember the big amount of TiKZ or tcolorbox options.

So, I don't feel comfortable when questioners make new questions in comments or editing the original which can be easily answered after a quick view to package documentation. I'd like to answer RTFM.

But being polite as we are in this site, I just politely comment and|or edit the answer, introduce a documentation reference or a documentation snapshot.

What's the correct behavior? After how many questions can we answer RTFM without breaking TeX.SX etiquette?

Update:

After David's suggestion: Of course I won't answer RTFM under no circumstances. But I think we should more frequently suggest to take a look at package documentation, even more if we know it's worth to do it.

Answer 1

Almost every question here can be answered by reading a manual (or the documented sources) so mostly I don't think a "read the manual" answer is appropriate (and definitely not that particular acronym which isn't that polite in most versions of its meaning).

Sometimes, if I think the user really could have tried harder, I do mention the manual. If an answer starts off "As it says on page 1 of the manual...." then that is (I hope) an implied hint that perhaps the OP could have found that without needing to ask...

The issue about new questions in comments is really a different one. There, if it is just a "clarification" I usually amend the answer or reply as a comment but if it is really a new question, just ask the OP to ask as a new question.

Answer 2

Although telling people to the read the documentation can have a therapeutic effect on ourselves, it's not necessarily helpful to the questioner for reasons that may not be apparent to us. Here are some:

• Not everyone reads English sufficiently well to make sense of documentation, even though with a couple of examples to get them going they can then figure things out.

• Even if you are a native English speaker, the conventions of documentation writing which seem obvious and clear to those of us with a computer science or programming background may be quite non-obvious to those who do not come from such a background (and there are many such users of LaTeX).

• Even if you are a native speaker and have a programming background, some documentation is just plain crappy and hard to understand to begin with.

  And independent of these reasons, if there is a "purpose" to be on the site it should be to be helpful to others on a voluntary basis. So if you don't want to help, don't help, and that's fine. If you want to help, help, don't practice behaviour modification. For some questions I think it's appropriate to point out that the question is answered on p. xx of the documentation, but only as a gentle reminder not as an admonishment.

And remember, as a wise man once described himself "turning the TikZ manual into reputation since 2011" just think of all those points you can get from reading the FM yourself. :)

Answer 3

There's a big difference between an RTFM (even if that exact phrasing isn't used) and a supporting reference to the documentation. For example, "Section/Page n of the manual for the X package says you always need to load X after Y" is an attribution that supports the answer, whereas "If you'd read the manual, you'd know that X must be loaded after Y" is an RTFM.

The StackExchange network generally encourages the use of attribution in answers. This is more important for sites such as english or scifi where answers can easily become opinionated, and answers without attributions may be downvoted because they're unsupported.

On this site, an answer such as "you need to load X after Y" can be easily verified by trying it out. We also have users on this site who are part of the LaTeX3 Project Team, or have been involved with the development of TeX for many years, or who are package/class authors. This naturally lends weight to their answers, but only for those readers who are aware of this.

I often land on StackExchange sites through web searches. I don't have time to do the site tour or find out about the users on that particular site. I just want an answer to my problem. An attribution helps to validate the answer, but it also provides a next step for my search if the question is only similar rather than exactly the same as mine and the answer doesn't solve my problem or doesn't solve it completely.

So personally I don't view a supporting reference to documentation as a cry of RTFM any more than I view a link to a related question as a cry of "why don't you use the flipping search box". The key thing here is about correctly phrasing attributions rather than emphasis on teaching users to read the manual.

---

Here's an attribution for this answer ;-)

From "How to write a good answer" (section "Provide context for links"):

Links to external resources are encouraged, but please add context around the link so your fellow users will have some idea what it is and why it’s there. Always quote the most relevant part of an important link, in case the target site is unreachable or goes permanently offline.

Answer 4

I rarely write RYFM in an answer to a question, but I will often give a URL for TFM and quote some relevant text. Even if you don't quote the text, it's a good idea to verify tat the information really is there and in an obvious location. Also check whether the relevant terms are in the index; often they are not. Alan Munn was being generous when he wrote

Even if you are a native speaker and have a programming background, some documentation is just plain crappy and hard to understand to begin with.

Some documentation doesn't even rise to that standard, and a polite request to read the manual can save you some embarrassment if it turns out that the information simply isn't there.

Answer 5

Well, let me try to provide a perspective that I haven't seen mentioned much.

I've been using LaTeX since around 2000 or so. One would think that I know my way around. I have mastered several programming languages since that time, TeX isn't one of them ;) ... I'm the proverbial one-eyed among the blind, at best, when it comes to TeX et. al. And it's not helping that some colleagues, including those that introduced LaTeX for our documentation process know even less than I do.

I will definitely appreciate a link to a specific manual, a quote from it and all that. Even a gentle Read The Friendly Manual in the well-known acronym form won't offend me.

But if I have my MWE condensed down to half a dozen lines of \usepackage and put considerable effort (and time) into working out why something doesn't seem to work the way it should (in my opinion anyway), it's not helpful to point me to the manual.

Maybe I'm not the average user in my reputation range or whatever, but when I turn here, it's really because I am literally reading the manual or after I did my best to find a solution on my own (often including reading or at least skimming several of the involved packages' manuals and usually several Q&As here on this site), usually having put in quite some time already. And sometimes the fact that the answer turns out to be trivial can be attributed to the same reason rubberducking works or because I didn't really understand what I was looking for in the first place (you can't understand recursion before you understand recursion).

And what does the manual mean anyway when I have half a dozen lines of \usepackage? Which one ...?

A lot and I mean really a lot of the issues I came across with LaTeX came merely from the fact that:

• Somehow I got the order of \usepackage wrong ... and somewhere this is probably even mentioned, but sometimes not. Sometimes in fact the questions, answers and the comments provide so much "between the lines" here on TeX.SE, that I would say reading the manual isn't an option when the sort of knowledge I am seeking is "floating around" somewhere else.
• The package version for some particular package was wrong ... as an example tabu - seemingly a frequent offender - seems broken (cells no longer colored) in the more recent 2.9 version, whereas the older 2.8 that comes packaged on my Ubuntu 18.04 has no trouble. If I use just tabu alone I cannot reproduce the error I run into. But with those three or four dozen packages used in the project in which I get this interop issue, I see it immediately. But creating an MWE from that behemoth of a project is ... not fun, or quick to do. And it's also not what I am paid for when LaTeX is "just" used to create beautiful documentation for the actual product.
• There is so much contradictory advice out there! And while reading the TeX book can be enlightening (as I realized as of late), for LaTeX a lot of the Common Sense™ seems to have evolved. And sure, that's nice. But I am still being recommended books from 2004 and earlier (e.g. here). LuaLaTeX and XeLaTeX were not around back then, if I'm not totally mistaken. The handling of all sorts of non-Latin characters (and the glyphs they are supposed to turn into) was a frequent thing I battled and it's gone with LuaLaTeX, but along with it I can also (it seems) throw out a whole lot of that Common Sense™ I picked up along the way. Oh well ...
  Fortunately for me as German native speaker the situation isn't quite as bleak. Numerous books on TeX et. al. are available in my native tongue. And yet some of them also don't touch sufficiently on points like the next one (IMO) ...
• It's hard to make sense of the log files. They often look like a dog rolled over the keyboard to type it out and it's seemingly more an art rather than a science to know what you're looking for. Thanks to the TeX book I am finally learning how to better read the log file.

I found the comment on another answer here (and I am quoting, because comments are volatile) sums it up quite nicely (emphasis mine):

I have had invaluable help on tex.stackexchange with answers ( where I am still grateful for ) I could ( probably ) have found out myself but only after many hours, if not days, of study and trial and error. For me, and I believe the majority of latexers, LaTeX is an invaluable tool but not a topic of research. Having a background in programming I do provide MWE's when I have one. My point being: I don't think rtfm-ing people away is compatible with the daily practice of the site. (nilo de roock)

And after all, if TeX and its family were a trivial subject matter, we would not have a dedicated SE site for it, would we?

TeX is old. In IT terms it's comparable to Earth's age when life conquered land masses for the first time or so. The corpus of available documentation is vast. Some is actually hard to come by (yeah, TeX book ... I'm looking at you!). Some is outdated (Git, btw, is another good example of a complex tool where this is an issue), in other parts the TeX book can still be of help even today. Some conventional wisdom isn't even in any manual ... or I've been reading the wrong manual all along.

So to the experts "in the room" I want to say: Thanks for the help so far, please be patient and be gentle (but firm!). We, I, will get there! All things are hard until you master them ...