When someone says “RTFM”¹, they appear to mean well. They do not. RTFM assumes everyone knows how to read a manual written by engineers for engineers. That assumption is where gatekeeping begins.

The Dichotomy

The Linux community and niche open‑source projects are prime examples. Maintainers² assume any asker already understands what a kernel³ is, what it means to “run” a command⁴, and why error messages matter. Users show up with “It does not work”, expecting answers on a silver platter while providing no failure details.

Both sides are wrong.

The Maintainer Problem

When documentation⁵ assumes technical literacy—it becomes a barrier to entry instead of a bridge. If every newcomer needs a decoder ring just to understand what you mean by “issue the command”, you have not written documentation—you have written gatekeeping disguised as helpfulness.

Documentation should answer what it does, how to run it, and where to find help when it breaks. Documentation should not just be a list of CLI flags⁶ for people who already know the rest of the stack.

The User Problem

When you say “It does not work”, without logs⁷, error messages⁸, OS version⁹, or steps to reproduce, no one can help. Not because they do not care—but because the best troubleshooter cannot diagnose a symptom they cannot see.

Provide effort by including the exact command you ran or GUI¹⁰ interactions you made, the full error output (not only the part that seems relevant), your OS and version, what worked before and what broke after, and if possible a short video of the issue.

Yes, screenshots and videos are acceptable. If every bug report included a 60‑second screen recording documenting the failure, resolution time would collapse from days to hours. We are not asking for your soul—we are asking for enough information that someone else can reproduce your failure without guessing.

The Community Solution

A community exists only if both sides invest in it. When you maintain a project, you have a responsibility to the next person walking through the door. That means you must document assumptions clearly, write “run this command” instead of just CLI snippets, and answer questions with links to specific manual sections, along with explanations. Just saying “Read the docs” is not helpful.

When someone asks for help and is less technical than you, assume nothing. Post the link to that section of the manual. Copy it out. Explain why it matters in one sentence. You are teaching—not punishing.

The same applies when you receive help. When a solution works, do not simply say “works now” and disappear. State how you fixed it, what worked, and why it worked. The next person with the exact issue should be able to read your solution and fix their own setup without posting a new question. Closing the loop keeps knowledge in the community instead of letting it evaporate into silence.

The Ten‑Thousandth Person

Every day, approximately 10,000 people learn something “everyone knows” for the first time. When a new user walks into the Linux community, they are one of that lucky cohort. You cannot be one of them—your knowledge is yours—but you can choose to help them have their own unrepeatable moment of discovery, instead of calling them an idiot because you failed to remember what it was like before you knew.

Randall Munroe put it bluntly in xkcd 1053: saying “what kind of an idiot doesn’t know this” is boring; telling someone about it for the first time is how you stay human. Treat “It does not work” as another person’s Yellowstone supervolcano moment—do you want their curiosity to dry up in your arms, or do you want to share what you love with someone who will actually listen?

Military Logic Applied to Open Source

In the military, every action reflects on the unit—no matter how insignificant. A sloppy report, a missing comma in a log entry, an untested assumption—all cascade. If enough people act this way, the whole mission suffers.

Open‑source communities are no different. Your bug report is your briefing. The way you ask for help shows your commitment to making this project work long‑term for everyone after you. When you get a solution, you owe it to the community to maintain clarity: what the problem was and how it was solved, so the next person does not reinvent that wheel while you move on to something new.

The Hill I Will Die On

Helping someone should mean walking them through the door—not locking it and demanding a password they do not have. That is ego wearing a thin veil of helpfulness.

RTFM becomes anti‑community when it punishes newcomers for ignorance instead of teaching them how the manual works. We need more guides, less judgment. More explanation, less assumption. Documentation that assumes nothing and teaches everything.

If a newcomer does not know what a command line is, they cannot read a CLI manual—no matter how technically perfect those words are. The answer to “it does not work” should never be “read the fucking manual.” It should be: here is the section you need, and here is why it matters.

This is the community we want, or this is no community at all.