I understand that devs have to deal with a lot of "dumb" questions, but that doesn't mean they have to be rude. As someone else said, silence would actually be better in this case, but a better response would be something like "hey, that's in the manual, in the blah section" because its not rude, it affirms that it is, indeed, in the manual and gives me a pointer where. Even without the last bit, it would be better. Part of good support is to acknowledge that the person has a problem, even if you can't help. If you don't want to provide support for an open source project (as in the case of the linked issues) then don't respond or at least set up a replacement to turn RTFM into something a bit more human.

> I found the answer valid, because I couldn't find the manual before.

How did RTFM help you find the manual if you didn't find it before, aside from affirming that there is, indeed, a manual?

Is it the category of response, or is it just the simple "RTFM" that turns you off? That is, if the answer was, "The answer to your question is in the manual; please read it", would you consider that ok?

Arguably the latter answer is the exact same thing in content as "RTFM", but it's easily more polite and doesn't have the same negative baggage.

If you're ok with the more wordy answer, then you're really just objecting to the negative tone and lack of politeness, not the amount of information given by the answer.

> This bad comment not only made d0ugal search for a different project, but also made sure I won't use it, and worsened my opinion of the author considerably.

Just a final note: many open source developers consider that a feature, so I doubt you'd sway most of them with this argument. As in, they're doing this in their spare time, and don't want that spare time to be squandered by people who don't even give them the courtesy of reading the provided documentation. (This is why, if you have read the docs and are still at a loss, you should say so: "How can I do X? I read through the man page and searched the wiki, but I wasn't able to figure it out". Framing your request this way shows that you aren't just a lazy leech who is wasting the developer's time.)

Having more users is only great if they aren't a support burden. A company can afford to hire scores of first-line support and afford to pay for support-desk platforms that automatically help triage and suggest answers to common questions. Most single-person and small-team open source projects can't do that. And users should not feel entitled to free support for software they haven't paid for. Sure, it would be great if people could always be courteous and friendly despite stress and overwork, but everyone has their limits.

Two days ago, I tried to get a vim plugin working. After trying the instructions over and over for about an hour and a half, I finally gave up and opened a ticket with a question that probably looks pretty lazy and dumb to someone experienced with it. Did I get an RTFM? No, it turns out there actually WAS a bug (actually, a bug and an undocumented setting). I almost didn't post out of fear of being called lazy or whatever and just give up on it, but it turns out there actually was a problem. They fixed it and I'm now a happy user and the positive experience makes me more likely to report future bugs, tell others about the tool or even contribute if I can. An "RTFM" would have driven me away forever.

If you feel like neither of them deserves a RTFM, I think you have a very entitled view of being a user, and personally I will never want you as a one for the software I write.

RTFM is a perfectly justified answer to people that consider that a developer's time in replying to their problem is less valuable than their own in searching for a solution. Exceptionally more so when the answer is an "apropos" or "man" page away. The least thing a user can do is to spend a fraction of the developers' invested time into finding solutions on their own.

Having worked on a variety of user-facing products for several years, I can tell you that it is hard. It depends on your audience but typically many users don’t report problems. If they do, they don’t give you enough details to diagnose the issue. And why should they? They’re not knowledgeable in how your system works. So you have to reach out to them and ask for more information. Maybe they need to reproduce the problem to give it to you. If you’re unlucky, they won’t be able to reproduce it. Even if they were able to, you have now taken more of their time.

The ask could be as simple as “hey this went wrong, but you can click here to send us the error info and someone will get back to you” and many users will STILL not share the information. You might think that they must not care that much but often times you’d be wrong. Users can be surprisingly irrational at times.

It's hard and some devs are not very patient, tbh...

> I really want to improve the quality of our implementation but have no idea how to without some pointers from experienced devs.

Come on IRC. Really.

> You make it sound like you got to where you are by yourself

Hardly. I ask questions. RTFM doesn't answer everything, nor does it explain, but you actually ask intelligent questions and are in a position to understand answers if you did some work before hand. Of course the referenced post wasn't looking for an answer to understand, they wanted 'use libfoo.'

> "Are we helping each other?" That's should always be the purpose of any community site

I have to write a script to install this thing here at work, would you mind doing it for me? That would be a BIG HELP to me.

See the problem yet? Technically it is a question, it would be a help to me. I suppose a community site would be more than happy to go about that then.

Oh and the response on any newsgroup for decades would be "Do your own damn homework, come back when you have a question."

Yeah, you can invent a new phrase (but that won't help, if RTFM becomes "carefully reading the documentation again", then that will start to implicitly carry the same shame and we'll play musical chairs with words until the next term is tainted too), but telling somebody to Google the error message or read the documentation is a valid response.

Especially on StackOverflow, there's an endless stream of no-effort-questions of the "I want this done, please do it for me" variety. Typing out an essay of why it's better if you invest some time yourself every time doesn't scale. You downvote/flag the question, and if you want to be helpful, you tell the person why they won't get help: because they didn't care enough about their problem to RTFM or GTFE (Google The Fucking Error) and everybody else cares even less than they do. And yes, you often can tell whether somebody googled the error or not.

I don't recall ever seeing "RTFM" responses to legitimate questions, plenty of people take time out of their days to explain why things aren't working and how they could work.

Don't retire RTFM, RTFM before asking. Once you do, either the problem goes away or you can state what you don't understand / where your understanding doesn't get you the expected result.

The stretch of suffering and overemphasizing of empathy in the article makes me think the author hasn't spent a lot of time actually engaging with questions on SO.

Not to berate users, but sometimes when people run into an issue they want a solution yesterday. So they hop on to the mailinglist/irc and demand to have their problem fixed... Only for more informed people to point them at the FAQ which probably results for the first Google search on problem.

I'm not saying that the software could't have flaws. I'm saying that if people are armed with the answer to their issue, then they are more equipped to make suggestions at the future direction of the software. When they still don't have an answer they are still in, "FIX THIS NOW!" mode.

Why anyone would volunteer to answer queries for free in this context is beyond me. What do they get out of it? A flashy hat to wear and a few trivial perks?

Respect to those trying to help out, but when a question like this is posed in the forum, I would only be interested in hearing the response of a salaried Google employee, not a volunteer.

It's even worse when the response offers trite, generic information that doesn't relate to the problem, regrettably a common occurrence on this type of forum.

Edit: Note, these remarks are not applicable to the commendable people providing support in FOSS projects, and in other non-commercial contexts.

"Hey I was trying to use Mary's api but I couldn't figure it out, can someone help me find who to contact?"

If you ask immediately for help all the time you aren't being self sufficient. At the same time if you are spinning your wheels then just a second pair of eyes can be helpful.

a bargain (for you)

and ps -- just so we're clear, the package I've contributed includes the mandatory per-user function help (each with runnable code examples), plus a 10+ page vignette discussing common usage, implemented inference algorithms, and parameter setting suggestions.

The vast majority of email I get starts with the implicit sentence [I'm a lazy prick who can't be arsed to read any of the docs, runnable code examples, or surrounding discussion. So if you could answer questions from someone who couldn't do the briefest amount of research that would be fabulous.]

Those emails are closely followed in quantity by the emails best summarized as "I'm gonna be super vague here but something didn't work. I neither wish to share the exact invocation of your package nor data, and certainly neither of those without prompting, but something didn't meet my unknown expectations and I want you to fix it now!"

It gets worse; A lot of those people expect fully fledged support for trivial "problems" which are clearly explained in the help file (that ships with the product) on the website, in the forums, and in a wiki. And they'll be dicks about it too.

Absolutely!

It will also help if people can see what you already tried, e.g. code, links, screenshots, and photos.

You don't do that if the plugin is provided for free, you can just say "thanks" or "no thanks", just don't use it / develop your own.

Instead of that rant, asking what those things mean and then writing good documentation would have been a much better use of their time. Or just some research, even.

When I'm doing something new (and I do that a lot... I tend to start new hobbies all the time) I don't rant at people for not explaining things to me. Instead, I do a lot of research and experimentation. As a last resort, I politely ask questions, first of friends and family, then of strangers on the internet. It's just polite.

I never understood this attitude.

IF (and only if) your help would very likely be useful and you know how to approach the person, then, why not?

As for the software angle, Clippy was indeed dumb and rarely offered useful help (partially because, as one of the comments above states, some boss forced engineers to replace a good algorithm with a more business suitable algorithm). But in general, I subscribe to the idea that software should be less interactive and guess more (and let you correct it, if the guesses were wrong).

To the contrary, I'd say something like: Ask yourself for help, first. If that didn't work, you might have a worthwhile question. This also requires you to be open to other people asking for help, and my greatest worry about this rule of thumb is that it makes people disinclined to help _each_ _other_. We're not cogs, human teams have value for good reason, and it's not just design or architecture decisions.

Sometimes we need to be "sounding boards" for each other.

Years ago, I'd get pulled into ridiculous flamewars on open-source mailing lists when I had run into a relatively simple issue. I was annoyed that each time I asked for help - the type of help I often provided myself - that inevitably whomever was paying attention to the list at that time of day would jump all over me and treat me like a n00b. I didn't want to come out restating my entire experience with a project before answering a question, but these flamewars aside, I found that often people would help anyway, but that sometimes the answers made me feel dumb.

This came down to asking well-informed questions. I would try to predict the clarifying questions that I would have, esp at my most cynical or annoyed time of the day, for someone else. I would end up with a page and a half describing my question, something some people might TL;DR, but probably wouldn't solicit a bunch of one-liner insults.

Ninety percent of the time, in composing such a message, I was able to answer my own questions. Unfortunately, that means that my presence in mailing list archives has my worst work, and that much of these messages never saw the light of day. I would just have an "ah-HA!" moment, along the lines of:

-- "And then even though I already tuned the kernel settings as recommended in [2], and installed the proper dependencies from the PP --- OH SHIT! I'm using the default packages and not the ones from the PPA."

Discard Draft Problem solved. ;) --

In these situations, I actually avoided asking other people for help by asking myself a question, but if I had been able to complete explaining my problem and my confusion to my satisfaction, I'd simply hit 'send'.

Dealing with people in-person is a little different, that's where the 'sounding board' comes in. If you respect your teammates, you can just kind of spitball a little about, "Hum this is really frustrating, are you kidding, Feature X in Package Y is implemented with a Dorner-Lannister sort? The Fuck? How stupid is.." And an intrepid teammate may say something like:

-- "Yeah. I mean. I'm not sure that's the decision I would have made, but I spent a good two days fighting with this exact problem a couple of months back, let me find you a mailing list thread. It will make you furious, then you can go outside and have a walk. Then come back inside and do it that way, so that you can get on with life." --

Or such conversations may be less existential:

-- SMASH SMASH SMASH keyboard "What in the actual fuck?! I can't stand cut! How has civilization progressed so far without a better way to grab output separated by variable lengths of spaces?"

"Bro, do you /even/ awk?" --

:-P