The Art of Asking Questions in Open Source Communities

Before asking a question

Before you ask a technical question via email, newsgroup, or chat room, please do the following:

1. Try searching for answers in old articles on the forum where you are asking a question.
2. Try searching online to find the answer.
3. Try reading the manual to find the answer.
4. Try reading the Frequently Asked Questions document (FAQ) to find the answer.
5. Try to check or experiment on your own to find the answer.
6. Ask your strong friends to find out.
7. If you are a program developer, try reading the source code to find the answer.

When you ask a question, please show that you have done the above; this will help establish that you are not a questioner who is getting something for nothing and wasting other people’s time. It would be better if you could also express what you learned in the process of doing the above efforts, because we are more willing to answer questions from people who show that they can learn from the answers.

Use certain strategies, such as first using Google to search for various error messages you encounter (search Google Forums and web pages), so that you are likely to find solutions directly. Problem file or mailing list thread. Even if there are no results, it’s good to add `I Googled the following sentence and found nothing useful' when asking for help on a mailing list or newsgroup, even if it just shows how helpful the search engine can’t be. Doing this (plus the searched string) also allows other people with similar questions to be directed to your question by search engines.

Take it easy and don’t expect a few seconds of Google search to solve a complex problem. Before asking an expert for help, read the FAQ, relax, get comfortable, and take some time to think about the problem. Trust us, they can tell from your questions how much reading and thinking you have done. If you come prepared, you will be more likely to get an answer. Don’t throw out all the questions at once just because your first search didn’t turn up the answer (or turned up too many answers).

Prepare your questions and think about them carefully, because hasty questions will only lead to hasty answers, or no answers at all. The more you can demonstrate the effort you put into solving the problem before asking for help, the more likely you are to receive substantial help.

Be careful not to ask the wrong questions. If your question is based on wrong assumptions, a J. Random Hacker will probably answer you with meaningless literal explanations while thinking `silly question…' in the hope that you will learn from the question. Learn from the answers (not the answers you want to get).

Never think you are qualified to have the answer, you are not; you are not. After all, you are not paid anything for this service. You will earn an answer on your own by asking a question that is meaningful, interesting, and thought-stimulating - a question that has the potential to contribute to the community’s experience, rather than just passively receiving answers from others. Ask for knowledge everywhere.

On the other hand, showing that you are willing to do something in the process of finding the answer is a very good start. Can anyone give me some tips? ,What is missing in my example? and What should I check is much easier to get a response from than `Please post the exact procedure I need'. Because you show that you have the ability and determination to get it done if only someone can point you in the right direction.

When you ask a question

Choose the forum where you ask questions carefully

Choose the occasion where you ask your question carefully. You’re likely to be ignored or viewed as a failure if you do any of the following:

• Post your question in a forum off-topic.
• Post very basic questions in forums that discuss advanced technical questions; and vice versa.
• Cross-posting the same question on too many different news groups.
• Send a private email to someone who is neither an acquaintance nor obligated to solve your problem.

Hackers will weed out questions that put them in the wrong context to protect their communication channels from being flooded with irrelevant stuff. You don’t want this to happen to you.

So the first step is to find the right forum. Again, Google and other search engines are your friends, use them to find the websites most relevant to the difficult software or hardware problem you’re experiencing. There are usually links to FAQs, mailing lists, and related documentation. If your efforts (including reading the FAQ) are fruitless, there may be a process or link for bug-reporting on the website. If so, check it out.

Sending emails to unknown people or forums is probably the riskiest thing to do. For example, don’t assume that the author of a content-rich web page will want to serve as your free consultant. Don’t be too optimistic about whether your question will be received—if you’re not sure, send it elsewhere, or don’t send it at all.

When choosing a forum, news group, or mailing list, don’t rely too much on its name. Check the FAQ or permission slip first to see if your question is relevant. Browsing through existing topics before posting will give you a feel for the culture. In fact, it’s a good idea to search the history of newsgroups or mailing lists for keywords related to your question beforehand, and you may be able to find the answer. Even if not, it can help you formulate better questions.

Don’t machine-gun all the channels for help at once, as this can be as unpleasant as shouting. Come one by one.

Figure out your theme! One of the most typical mistakes is to ask a question about a Unix or Windows operating system program interface in a forum dedicated to a cross-platform portable language, suite, or tool. If you don’t understand why this is a big mistake, it’s best not to ask anything until you understand the difference.

Generally speaking, asking a question in a carefully selected public forum will result in a more useful answer than asking the same question in a private forum. There are several reasons to support this, one is the number of potential responders, and the other is the size of the audience. Hackers are more likely to answer questions that can help a lot of people.

Understandably, sophisticated hackers and the authors of some popular software are receiving a plethora of misinformation. Just like the straw that broke the camel’s back, your participation may also take the situation to the extreme - there have been several times when the authors of some popular software stopped due to the unbearable amount of useless emails flooding into their personal mailboxes. provide support.

Stack Overflow

Search, then ask on Stack Exchange.

In recent years, the Stack Exchange community has become a primary channel for answering technical and other questions, especially those about open source projects.

Because Google indexing is instant, search on Google before looking at Stack Exchange. There’s a high chance that someone has already asked a similar question, and Stack Exchange sites tend to be among the first results. If you don’t find any answers on Google, look for them on a website specific to the topic. Searching with tags allows you to narrow down your search results.

If you still can’t find anything useful for your question, please post your question on the website most relevant to it. Please make good use of formatting tools when asking questions, paying special attention to formatting the code and adding relevant tags (especially the name of the programming language, operating system, or library/package). When someone asks you for more relevant information, edit your posts to supplement them [Annotation: Instead of posting a reply or answer! ]. If you find an answer helpful, click the up arrow to vote for it; if an answer provides the correct solution to the problem, click the check mark below the vote button to mark it as the correct answer.

Stack Exchange has grown to more than a hundred websites, the following are the most commonly used sites:

• Super User asks some general computer questions. If your question has nothing to do with coding or writing programs, but just some network connections, please go here.
• Stack Overflow is for asking questions related to writing programs.
• Server Fault asks questions related to the server and network management.

Website and IRC Forum

Your local user group, or the Linux distribution you are using may be promoting their web forum or IRC channel and providing newbie help (in some non-English speaking countries, the newbie forum may also be a mailing list), these are is a good place to start asking questions, especially if you think you may have a relatively simple or common problem. Ad-sponsored IRC channels are places where questions are openly welcomed and responses can often be immediate.

In fact, if the problem with the program only occurs with the version provided by a specific Linux distribution (which is very common), it is better to ask the question in the forum or mailing list of that distribution first, and then ask the forum or mailing list of the program itself. (Otherwise) the project’s hackers might just reply “use our version”.

Before posting in any forum, make sure there is a search function. If so, try searching for a few keywords of the question, maybe this will help. If you’ve done a general web search before (and you should), search the forum again. Search engines may not have time to index the entire content of the forum.

There is a growing trend to provide user support services through forums or IRC channels, while email is mostly reserved for communication between project developers. So it’s best to first seek assistance with the project in the forums or IRC.

When using IRC, it’s best not to post long problem descriptions in the first place, which some people call channel flooding. It’s best to start the chat with a one-sentence description of the problem.

The second step is to use the project mailing list

When a project provides a developer mailing list, ask questions to the list rather than to the individual members of the list, even if you are sure he can best answer your question. Check the project’s documentation and home page, find the project’s mailing list and use it. There are several good reasons for this approach:

• Any questions good enough to ask individual developers will also benefit the entire project group. On the other hand, if you think your question is too stupid for the entire project team, then this is not a reason to harass individual developers.
• Asking questions to the list can spread the burden on developers; individual developers (especially project leaders) may be too busy to answer your questions.
• Most mailing lists will be archived, and those archived content will be indexed by search engines. If you ask a question on the list and get an answer, others can find your question and answer through a web search in the future, so you don’t have to ask again.
• If certain questions are asked frequently, developers can use this information to improve the documentation or the software itself to make it clearer. If questions are only asked privately, no one will see the full context of the most common questions.

If a project has both “users” and “developers” (or “hackers”) mailing lists or forums, and you don’t have access to the source code, ask questions on the “users” list or forum. Don’t assume you’ll be welcome on the developer list, as those people will probably see your question as noise that’s distracting from their development.

However, if you are sure that your issue is unique and you haven’t received a reply in the Users list or forum for a few days, try asking in the Developers list or forum. It is recommended that you sit back and watch for a few days to get a feel for how things are done there before posting (in fact this is a good idea to participate in any private or semi-private list)

If you can’t find a project’s mailing list and can only find the email address of the project maintainer, feel free to send him a message. Even in this case, don’t assume the (project) mailing list doesn’t exist. In your email, state that you have tried but failed to find a suitable mailing list, and also mention that you have no objection to forwarding your email to others (many people believe that private email should not be used, even if it is nothing secret. Public. By allowing your email to be forwarded to others, you give the appropriate person a choice about what to do with your email).

Use meaningful and descriptive titles

In a mailing list, news group, or forum, a title of approximately 50 words or less is a good opportunity to grab the attention of a senior expert. Don’t waste this with endless chatter about ‘Help’, ‘Begging’, and ‘Urgent’ (not to mention ‘Help!!!!’ if it’s so offensive, the headline will be reflexively ignored) Chance. Don’t try to impress us with your level of pain. Instead, use a very simple and concise description to raise the question in this space.

An example of a good title is a ‘Goal - Difference’ style description, which is what many technical support organizations do. In the goal' part, indicate which thing or group of things is problematic, and in the difference' part, describe the inconsistency with the expected behavior.

Stupid question: Help! My laptop can’t display properly!

Smart question: The mouse pointer in X.org 6.8.1 becomes deformed with a certain brand of graphics card MV1005 chipset.

Smarter question: The mouse pointer of X.org 6.8.1 will be deformed in the environment of a certain brand of graphics card MV1005 chipset.

The process of writing a goal-difference description helps you organize your detailed thinking about the problem. What was affected? Is it just a mouse pointer or are there other graphics? Only in version X of X.org? Or just in version 6.8.1? Is it for a certain brand of graphics card chipset? Or just the MV1005 model among them? A hacker can immediately understand your environment and the problems you are encountering with just one glance.

To summarize, imagine you are searching in an index of archived threads that only displays titles. Making your title better reflect the question will allow the next person searching for a similar question to follow the thread instead of asking the same question again.

If you want to ask a question in your reply, remember to change the title of the content to indicate that you are asking a question. A title that looks like Re: Test or Re: New bug is difficult to attract enough attention. In addition, without affecting the coherence, appropriately quoting and deleting the previous content can leave clues for new readers.

For threads, don’t just click reply to start a new onediscussion thread, this will limit your audience. Because some email readers, such as mutt, allow users to sort by threads and hide messages by collapsing threads, people who do this will never see your messages.

Just changing the title isn’t enough. mutt and some other mail readers also check for information beyond the message header in order to assign it a thread. So rather send a brand new email.

In web forums, good questions are slightly different because threads are tightly tied to specific information and the content is usually not visible outside the thread, so it is acceptable to reply to the question rather than changing the title. . Not all forums allow separate titles in replies, and if you do, almost no one will read it. However, by replying to questions, this is inherently ambiguous, as they will only be read by the person who is viewing the title. So, unless you only want to ask questions among the people currently active in the thread, it’s better to start from scratch.

Make questions easy to respond to

Ending your question with Please send your reply to... is likely to get you no answer. If you think it’s troublesome to spend a few seconds setting up a reply address in your email client, we also think it’s more troublesome to spend a few seconds thinking about your problem. If your mail program does not support this, change to a better one; if the operating system does not support this mail program, also change to a better one. .

In a forum, it’s extremely rude to ask for a reply via email, unless you think the reply may be sensitive (someone would, for some unknown reason, want the answer to be known only to you and not the entire forum). If you just want to be notified via email when someone replies to a thread, you can ask the web forum to send it to you. Almost all forums support functions such as Follow this discussion thread and Send email reminder when there is a reply.

Use clear, correct, precise and grammatical statements

We have found from experience that careless questioners are often careless in programming and thinking (I can guarantee it). It’s not worth answering the unwary’s questions; we’d rather spend our time elsewhere.

Correct spelling, punctuation, and capitalization are important. Generally speaking, if you think it’s troublesome to do this and don’t want to care about it, then we also think it’s troublesome and don’t want to care about your questions. Put a little extra thought into your words and don’t have to be rigid and formal - in fact, hacker culture values the accurate use of informality, slang, and humor. But it must be accurate and show signs that you are thinking and paying attention to the problem.

Spell, use punctuation and capitalization correctly and do not confuse its for it's, loose for lose or discrete for discreet. Don’t use all caps, it will be seen as rude shouting (all lowercase is no better, because it is difficult to read. Alan Cox might be able to do that, but you can’t).

To put it more bluntly, if you write like a semi-literate person, you will probably not be ignored. Also do not use instant messaging abbreviations or Martian. For example, shortening 的 to d will make you look like a person trying to avoid typing. A novice who saves words by using a few keys. What’s worse is that if you draw talismans like a child, you are definitely seeking death, and you can be sure that no one will pay attention to you (or at best, they will give you a lot of criticism and sarcasm).

If you’re asking in a forum where you’re not speaking your native language, you can make a few mistakes in spelling and grammar, but you can’t be sloppy in your thinking (yes, we can usually figure out the difference). Also, write in English unless you know the language of the respondent. Busy hackers often simply delete messages written in a language they don’t understand. English is the universal language on the Internet, and writing in English minimizes the likelihood that your question will be deleted without even being read.

If English is your second language, it is good to remind potential respondents that you have potential language difficulties:

English is not my native language; please excuse typing errors.

• English is not my native language, please forgive my typos or grammar.

If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.

• If you speak a certain language, please send me an email / private message;
• I need someone to help me translate my question.

I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

• I am familiar with technical terms, but not familiar with colloquial expressions or special usage.

I’ve posted my question in $LANGUAGE and English. I’ll be glad to translate responses, if you only use one or the other.

• I write my questions in language and in English.
• If you only reply in one of these languages, I will be happy to translate the reply into your language.

Send questions using an easy-to-read, standard file format

If you make a question artificially difficult to read, it will most likely be ignored. People would rather read a question that is easy to understand, so:

• Use plain text instead of HTML (Turn off HTML is not difficult).
• Using MIME attachments is usually OK, provided there is actual content (e.g. attached source code or patch) and not just a template generated by the mail program (e.g. just a copy of the message content).
• Don’t send an email where the text is just a one-line sentence but wraps into multiple lines (which makes it very difficult to reply to part of the text). Assuming your readers are reading the email on a terminal that is 80 characters wide, it is best to set your line break point to less than 80 characters.
• However, do not set a fixed width for some special files (such as log file copies or session records). The data should be included as is, giving respondents confidence that they are seeing the same thing you are seeing.
• In English forums, do not send messages using Quoted-Printable MIME encoding. This encoding may be necessary for posting non-ASCII languages, but many mail programs do not support it. When they handle line breaks, those =20 symbols scattered throughout the text are ugly and distracting, and may even destroy the semantics of the content.
• Definitely, never expect hackers to read documents written in a closed format, like Microsoft Word or Excel files, etc. Most hackers would react to this like you would if someone dumped steaming pig manure on your doorstep. Even if they can handle it, they hate doing it.
• If you’re sending email from a Windows computer, turn off Microsoft’s stupid Smart Quotes' feature (check the Smart Quotes' radio box from [Options] > [Proofing] > [AutoCorrection Options]) to avoid Spread junk characters all over your email.
• In forums, do not abuse the emoticon and HTML functions (when they are provided). One or two emojis are usually fine, but fancy colored text tends to make people think you’re a wimp. Overusing emojis, colors, and fonts can make you look like a giggling little girl. This is usually not a good idea unless you’re just interested in the sex and not the answers.

If you use a graphical user interface mail program (such as Microsoft Outlook or similar), be aware that their default settings may not necessarily meet these requirements. Most of these programs have a menu-based `view source' command, which can be used to check the mail in the sent folder to make sure that it is a plain text file and does not have any strange characters.

Describe the problem accurately and make sense

• Carefully and clearly describe the symptoms of your problem or bug.
• Describe the environment in which the problem occurs (machine configuration, operating system, applications, and related information), and provide the distributor’s release and version number (such as Fedora Core 4, Slackware 9.1, etc.).
• Describe how you researched and understood the question before asking it.
• Describe the diagnostic steps taken to identify the problem before asking the question.
• Describe any recent hardware or software changes that may be relevant.
• If possible, provide a way to reproduce the problem in a controlled environment.

Try to guess what a hacker will ask you, and answer the questions the hacker may ask before you ask them.

Of the above points, when you are reporting a problem that you think may be in the code, it is especially important to give hackers an environment in which they can reproduce your problem. When you do this, your chances and speed of getting a valid answer will be greatly improved.

Simon Tatham wrote an article called “[How to report bugs effectively](http://www.chiark.greenend.org. uk/~sgtatham/bugs-cn.html)"’s excellent article. I highly recommend you read it too.

Don’t talk too much but be precise

You need to provide accurate and informative information. This does not require you to simply transcribe a bunch of error code or information into your question. If you have a large and complex test case that reproduces a crash situation, try to trim it as small as possible.

This has at least three uses. First, showing that you have put effort into simplifying the question increases your chances of getting an answer; Second, simplifying the question makes it more likely that you will get a useful answer; Third, while refining your bug In the process of reporting, you are likely to find a solution or workaround on your own.

Don’t always claim to have found a bug

When you encounter a problem while using software, don’t easily claim to have found a bug unless you are very, *very well-founded. Tip: Unless you can provide a source code patch that fixes the problem, or provide regression tests that show incorrect behavior in a previous version, you probably won’t be completely convinced. The same applies to web pages and files. If you (claim to) have found a bug in a file, you should be able to provide a correction or replacement file in the corresponding location.

Remember, there are many other users who are not experiencing the problem you noticed, otherwise you would have discovered it while reading the files or searching the web (you [did this already, right] before complaining)(https://github. com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md#before asking questions)?). This also means that it’s more likely that you’ve made a mistake than there is a problem with the software itself.

People who write software always work very hard to make it as perfect as possible. If you claim to have found a bug, you are questioning their ability, and even if you are right, you may offend some of them. This is especially serious when you scream about a bug in your title.

When asking a question, even if you’re secretly convinced that you’ve found a real bug, it’s best to write like you did something wrong. If there is a bug, you will see this in the reply. This way, if there is a bug, the maintainer will apologize to you, which is better than if you pissed off someone and then owe them an apology.

Being humble cannot replace your homework.

Some people understand that they shouldn’t be rude or arrogant about asking questions and demanding answers, but they choose the other extreme - talking down to them: I know I'm just a pathetic newbie, a whimper, but.... This is both annoying and unhelpful, especially when accompanied by a description that is vaguely relevant to the actual problem.

Stop wasting your time and mine with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This positions you better than talking down to someone.

Sometimes online forums will have a section specifically for newbies to ask questions. If you really think you have a beginner’s question, just go there, but don’t be so down-to-earth.

Describe the symptoms of the problem rather than your guess

Telling hackers how you think the problem is caused isn’t helpful. (If your inferences are so valid, why bother asking others for help?) So make sure you tell them the symptoms of the problem, not your explanations and theories; let the hackers speculate and diagnose. If you think it’s important to state your guesses, clearly state that they are just guesses on your part, and describe why they don’t work.

Stupid question

I encountered SIG11 errors one after another when compiling the kernel. I suspect that a certain flying wire is connected to the motherboard trace. What is the best way to check this situation?

Smart Questions

My assembled computer is a FIC-PA2007 motherboard equipped with AMD K6/233 CPU (VIA Apollo VP2 chipset) and 256MB Corsair PC133 SDRAM memory. When compiling the kernel, SIG11 errors frequently occur 20 minutes after booting, but at the beginning Never had the same problem happen within 20 minutes. Restarting didn’t help, but shutting it down overnight got me working for another 20 minutes. All the memory has been replaced with no effect. RelatedPart of the standard compilation record is as follows…

Since this seems overwhelming to many, here’s a reminder: ‘All the diagnosticians are from Missouri. The official motto of the U.S. Department of State is: Let me see’ (from Congressman Willard D. Vandiver’s 1899 speech: I come from a country of corn, cotton, burdock, and Democrats, and cannot speak with eloquence. Convincing me won't satisfy me either. I'm from Missouri and you have to show me.) It’s not a suspicion on the part of the diagnostician, just a real and useful need to have them What you see is something that is as consistent as possible with the original evidence you saw, rather than your guesses and inductive conclusions. So, show it to us generously!

List the problem symptoms in order of occurrence time

A series of operations before a problem occurs are often the most helpful clues for finding the problem. Therefore, your instructions should include the steps you took and how the machine and software reacted until the problem occurred. In the case of command-line processing, it can be helpful to provide a record of the operation (for example, generated by running a script tool) and quote a number of relevant lines (for example, 20 lines) of the record.

If the hanging program has diagnostic options (such as the -v verbose switch), try selecting these options to add debugging information to the log. Remember, ‘more’ does not equal ‘good’. Try to choose an appropriate debugging level that provides useful information rather than drowning the reader in garbage.

If your description is long (e.g., more than four paragraphs), it can be helpful to briefly state the problem at the beginning and then detail it chronologically. This way hackers know what to look for when reading your records.

Describe goals rather than processes

If you want to figure out how to do something (as opposed to reporting a bug), describe your goal at the beginning and only later state the specific steps to reproduce where you’re stuck.

People who often seek technical help have a higher-level goal in mind, and they get stuck on a particular path that they think will get them there, and then come asking how to get there, without realizing that the path itself is has a problem. It ended up taking a lot of effort to get it right.

Stupid question

How can I get hexadecimal RGB values from a paint program’s color picker?

Smart Questions

I’m trying to replace the color table of an image with one of my own choosing. The only way I know of now is to edit each table slot, but I can’t do it from a drawing program. The color picker gets the RGB value in hexadecimal.

The second way to ask is smarter, and you may get a response like “Suggest another more suitable tool.”

Don’t ask for a private email reply

Hackers believe that the problem-solving process should be open and transparent, and that if more experienced people notice incompleteness or inappropriateness during this process, the initial response can and should be corrected. At the same time, as a helper, you can get some rewards. The reward is that his abilities and knowledge are seen by other peers.

When you request a private reply, the process and reward are aborted. Don’t do this, let the responder decide whether to answer privately - if he does, it’s usually because he thinks the question is too poorly written or too superficial to interest others.

There is a limited exception to this rule, if you are sure that your question is likely to elicit a lot of similar responses, then the magic question would be ‘email me and I will summarize the responses for the forum’. It’s polite to try to save a mailing list or newsgroup from being flooded with identical responses - but you must keep your word.

Clearly express your questions and needs

Endless questions are an almost endless black hole of time. The people most likely to give you useful answers are usually the busiest people (busy because they do most of the work themselves). Such people are quite disgusted with the uncontrolled black hole of time, so they also tend to hate those rambling questions.

You’re most likely to get a useful answer if you explicitly state what you want the respondent to do (such as provide pointers, send a piece of code, check your patch, etc.). Because this will set a time and energy limit so that the respondent can concentrate on helping you. It’s great to do this.

To understand the world experts live in, think of expertise as an abundant resource and time to respond as a scarce resource. The less time you ask them to devote, the more likely you are to get answers from experts who are truly dedicated and busy.

So, framing your question so that it minimizes the time it takes for experts to identify your question and answer can be a very helpful technique for getting an answer—but it’s usually not the same technique as simplifying the problem. So, I want to understand X better, can you point me to a better explanation? Usually better than asking Can you explain X? `Better. If your code doesn’t work, it’s usually wiser to ask someone else to look at what’s wrong than to ask someone else to correct it for you.

When asking questions about code

Don’t ask others to help you debug problematic code without giving you a hint on where to start. Posting a few hundred lines of code and saying: It doesn't work' will get you completely ignored. Just posting a few dozen lines of code and saying: After the seventh line, I expected it to display , but what actually appeared was ` is more likely to get you a response.

The most effective way to describe a program problem is to provide the most streamlined bug-demonstrating test case. What is the most streamlined test case? That’s the epitome of the problem; a small program snippet that just shows off the program’s anomalous behavior and contains no other distracting content. How to create the most streamlined test cases? If you know which line or block of code is causing the unexpected behavior, copy it and add enough code to reproduce the situation (i.e., enough so that the code can be compiled/interpreted/processed by the application). If you can’t narrow the problem down to a specific block, make a copy of the code and remove the parts that don’t affect the behavior causing the problem. In short, the smaller the test cases, the better. .md#The words are not too much but the essence).

Generally speaking, it is not easy to get a fairly concise test case, but it is a good habit to always try to do this first. This approach can help you understand how to solve the problem yourself - and even if your attempts are unsuccessful, hackers will see that you put effort into trying to get the answer, which can make them more willing to work with you.

If you just want someone to help review the code, say so at the beginning of the letter, and be sure to mention which part you think needs special attention and why.

Don’t post your homework questions.

Hackers are very good at identifying which problems are homework problems; most of us have solved these problems ourselves. Again, it’s up to you to solve these problems, and you will learn from them. You can ask for tips, but don’t ask for a complete solution.

If you suspect you’ve encountered a homework-style problem and still can’t solve it, try asking in a user group, forum or (as a last resort) on the project’s users mailing list or forum. Although hackers will definitely figure it out, some experienced users may still be able to give you some hints.

Remove meaningless questions

Avoid ending the question with meaningless words such as ‘Can someone help me? orIs there an answer to this? `.

First of all: if your description of the problem is not very good, asking like this is superfluous.

Secondly: hackers will get annoyed with you because it’s superfluous to ask - and will usually express their disdain with logically correct but meaningless answers, such as: ‘Yes, someone can help you’ or ‘No , no answer`.

In general, avoid yes or no, true or false, yes or no type questions unless you want a [yes or no type answer](https://strcat.de/questions- with-yes-or-no-answers.html).

Even if you are urgent, don’t write — Urgent in the title

This is your problem, not ours. Declaring ‘urgent’ is highly likely to backfire: most hackers will simply delete the issue in a disrespectful and selfish attempt to gain immediate attention. What’s more, the word ‘Urgent’ (or other attention-grabbing headlines) will often be filtered out by spam filters - the people you hope to see your question may never see it.

The semi-exception is that if you’re in some high-profile place where hackers are excited, it might be worth it. In this case, if you are under time pressure and mention this politely, people may be interested in answering faster.

Of course, this is risky, because hackers are probably excited about things that are different from yours. For example, it’s okay to post a headline about NASA’s International Space Station, but it’s definitely not okay to post a headline about a feel-good charity or political cause. In fact, posts like `Urgent: Help me save this furry baby seal! ‘It’s guaranteed to get you ignored by hackers or annoy them, even if they think furry baby seals are important.

If you think this is incredible, it is best to read the rest of this guide a few times until you understand it before posting.

It’s not weird to be polite to many people, and sometimes it’s helpful.

Be polite and use “please” and “thank you for your attention”, or “thank you for your concern”. Let everyone know how grateful you are that they take the time to help for free.

Frankly, this is no more important than (and not a substitute for) the use of clear, correct, precise, and grammatical language and the avoidance of proprietary formats. Hackers generally prefer to read bug reports that are a bit abrupt but technically distinct, rather than polite but vague ones. (If this puzzles you, remember that we value questions by what they can teach us.)

However, if you have a list of questions to answer, being polite will definitely increase your chances of getting a helpful response.

(We’ve noticed that since this guide was released, the only serious flaw feedback we’ve gotten from veteran hackers is the “thank you in advance” clause. Some hackers feel that “thank you in advance” implies that you don’t have to thank anyone later. We My suggestion is to either say ‘Thanks in advance’ first, and then thank the respondent afterwards, or express gratitude in another way, such as ‘Thank you for your attention’ or ‘Thank you for your concern’.)

After the problem is solved, add a brief additional explanation

After the problem is solved, send a note to everyone who helped you, let them know how the problem was solved, and thank them again. If the problem has received widespread attention on a newsgroup or mailing list, it would be appropriate to post a note there.

The ideal way to do this is to reply to this message in the thread where the question was originally asked, and include a clear mark of Fixed, Resolved or other equivalent meaning in the title. In a busy mailing list, a potential replyer who sees the discussion threads `Problem So you can use this time to solve other problems.

The supplementary explanation does not need to be long or in-depth; it can be as simple as Hello, it turns out there is something wrong with the network cable! Thanks everyone - Bill It’s better than saying nothing. In fact, unless the conclusion is really technical, a short and cute summary is better than a long essay. Explain how the problem was solved, but there is no need to repeat the process of solving the problem.

For in-depth questions, it can be helpful to post a summary of the debugging logs. Describe the final state of the problem, explain what solved the problem, and then identify the blind spots that could be avoided. Avoiding blind spots should be placed after correct solutions and other summary material, rather than turning the information into a whodunnit. Listing the names of people who have helped you will help you make more friends.

In addition to being polite and informative, this type of addition will also help others search the mailing list/newsgroup/forum for a real solution to your problem, allowing them to benefit from it as well.

At the very least, this supplementation will help provide everyone involved with the assistance with a sense of satisfaction from the resolution of the problem. If you’re not a tech guru or hacker yourself, trust us, this feeling is important for those gurus or experts you turn to for help. Having a problem unresolved can be discouraging; hackers are eager to see the problem solved. Good things come to good people. Satisfy their cravings and you’ll reap the benefits the next time you ask.

Think about how you can prevent others from having similar problems in the future and ask yourself if writing a document or adding a frequently asked questions (FAQ) would be helpful. If so send them to the maintainer.

Among hackers, this kind of good follow-up is actually more important than traditional etiquette and is how you earn a reputation by treating others well, which is a very valuable asset.

How to interpret the answer

RTFM and STFW: How to Know You’ve Totally Messed Up

There is an ancient and sacred tradition: if you receive an RTFM (Read The Fucking Manual) response, the respondent believes that you should read the fucking manual. Of course, basically he’s right and you should read it.

RTFM has a younger relative. If you receive an STFW (Search The Fucking Web) response, the respondent thinks you should search the fucking web. That person is probably right, go search for it. (To put it mildly, Google is your friend!)

In the forum, you may also be asked to crawl the forum’s old articles. In fact, someone might even be kind enough to provide you with a thread that previously addressed this issue. But don’t rely on this kind of care. You should search for old articles before asking questions.

Usually, the person who answers you with one of these two sentences will give you a manual or a URL that contains what you need, and they are reading it as they type these words. These responses mean that the respondent believes

• The information you need is easily accessiblehave to;
• You will learn more if you search for this information yourself than if it is spoon-fed to you.

You shouldn’t be upset; by hacker standards, he has expressed a certain level of concern for you without turning a blind eye to your requests. You should be grateful for his grandmotherly kindness.

If you still don’t understand

If you don’t understand a response, don’t immediately ask for an explanation. Just like you did when you tried to solve the problem yourself (using manuals, FAQs, the Internet, the experts around you), first try to understand his response. If you really need an explanation, show that you learned something.

For example, if I answer you: It seems like zentry is stuck; you should clear it first. , and then this is a bad response to the follow-up question: What is zentry? Good question should be like this: Oh~~~ I have read the instructions but only the -z and -p parameters mentioned zentries, and there is no clear explanation on how to clear it. Which of these two are you referring to? Or did I miss something?

Handling rude responses

Many seemingly disrespectful behaviors in hacker circles are not intended to offend. Instead, it’s a straightforward, to-the-point communication style that’s more focused on solving problems than making people feel comfortable and vague.

If you feel offended, try to react calmly. If someone does something outrageous, the seniors on the mailing list, newsgroup, or forum will probably call him out. If this doesn’t happen and you get angry, the words of the person you’re angry with might seem normal to the hacker community, and you’ll be seen as the party at fault, which will hurt Your opportunity to obtain information or assistance.

On the other hand, you do occasionally encounter rude and boring words and actions. Contrary to the above, it is acceptable to hit the real offender hard and to use harsh words to refute him to the core. However, you must be very, very well-founded before acting. There’s a fine line between correcting an offensive comment and starting a pointless war of words, and it’s not uncommon for hackers to recklessly cross the line themselves. If you are a newbie or an outsider, your chances of avoiding such recklessness are not high. If you want to get information rather than kill time, it’s best not to put your hands on the keyboard at this time to avoid risk.

(Some people assert that many hackers have mild forms of autism or Asperger’s syndrome, lacking the nerves needed to lubricate normal interactions in human society. This may or may not be true. If Since you’re not a hacker yourself, maybe you think our brain issues will help you cope with our weird behavior. Just do it, we don’t care. We like us just the way we are, and generally have a knack for being sick. A defensible suspicion.)

Jeff Bigler’s summary of observations related to this is also worth reading (tact filters).

In the next section, we’ll talk about another issue, the ‘offense’ you get when you behave inappropriately.

How to avoid playing the loser

There are likely to be times when you mess up in hacker community forums, in the ways described in this guide or similar. And you’ll be told in public how you screwed up, maybe with a little bit of slur in the attack.

When something like this happens, the worst thing you can do is whine about your experience, claim to have been verbally assaulted, demand an apology, scream, sulk, threaten legal action, complain to your employer, and refuse to care. Toilet seats, etc. Instead, you should do this:

Get over it, it’s normal. In fact, it’s wholesome and reasonable.

The standards of a community do not sustain themselves, they are maintained by active and public enforcement by participants. Don’t cry. All criticism should be delivered via private email, that’s not how it works. When someone comments that one of your statements is incorrect or offers a different view, there is no benefit in insisting on claiming personal attack. These are the attitudes of a loser.

There are other hacker forums that, misled by high etiquette requirements, prohibit participants from posting any messages that find fault with other people’s posts, saying, ‘If you don’t want to help users, just shut up.’ `The result is that thoughtful participants leave, which only reduces them to meaningless chatter and useless technical forums.

To put it in exaggerated terms: do you want to be “nice” (in the above way) or do you want to be useful? Choose one of the two.

Remember: when a hacker says you screwed up, and (no matter how harshly) tells you not to do it again, he is acting out of concern for you and his community. It’s easier for him to ignore you and filter you out of his life. If you can’t say thank you, at least show some dignity, don’t wail, and don’t expect others to treat you like a fragile doll just because you’re a dramatic, hypersensitive soul and a self-entitled newcomer. .

Sometimes, someone will attack you personally for no apparent reason, even if you didn’t mess up (or just imagined that you did). In this case, complaining really messes up the problem.

These troublemakers are either useless guys who think they are experts because they have no solution, or they are psychologists testing whether you can really screw up. Other readers either ignore them or deal with them in their own way. These troublemakers are causing trouble for themselves, and you don’t have to worry about that.

Don’t let yourself get involved in wars of words, either. It’s best to ignore most wars of words - of course, this is until you check that they are just war of words and don’t point out where you messed up, and don’t subtly address the real issue. The answer is hidden behind it (this is also possible).

Questions you shouldn’t ask

Here are a few classic stupid questions and what hackers are thinking when they don’t answer them:

Question: Where can I find X program or X resource?

Question: How do I do Y with X?

Question: How do I set up my shell prompt?

Question: Can I convert AcmeCorp files to TeX format using the Bass-o-matic file conversion tool?

Problem: [My program/settings/SQL statements are not working](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md# q5)

Question: I’m having a problem with my Windows computer, can you help me?

Question: [My program will not move. I think there is a problem with system tool X](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README- zh_CN.md#q7)

Question: I’m having trouble installing Linux (or X), can you help me?

Question: How can I hack the root account/steal OP privileges/read other people’s emails?

Question: Where can I find X program or X resource?

Answer: Right where I found it, idiot—on the search engine side. Oh my gosh! Are there still people who don’t know how to use Google?

Question: How do I use X to do Y?

Answer: If you want to solve Y, don’t ask a question that may not be appropriate. This kind of question shows that the questioner is not only completely ignorant of X, but also confused about the problem Y wants to solve, and his thinking is also restricted by the specific situation. It’s best to ignore such people and wait until they figure things out.

Question: How do I set up my shell prompt? ?

Answer: If you are smart enough to ask this question, you should also be smart enough to [RTFM](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/ main/README-zh_CN.md#RTFM), and then find it yourself.

Question: Can I convert AcmeCorp files to TeX format using the Bass-o-matic file conversion tool?

Answer: Just try it and you will know. If you’ve tried it, you know the answer and don’t waste my time.

Problem: My {Program/Settings/SQL statement} is not working

Answer: That’s not really a question. I’m not interested in asking you twenty questions to find out what your real problem is - I have more interesting things to do. When I see this kind of question, my reaction is usually the following three:

• Do you have anything else to add?
• That’s too bad, I hope you can figure it out.
• Is this none of my business?

Question: I have a problem with my Windows computer, can you help me?

Answer: Yes, throw away Microsoft’s garbage and switch to an open source operating system like Linux or BSD.

Note: If the program has an official version of Windows or interacts with Windows (such as Samba), you can ask Windows-related questions, just don’t be surprised by a reply that the problem is caused by the Windows operating system and not the program itself. Because Windows generally sucks, this is usually true.

Problem: My program won’t move, I think there’s something wrong with system tool X

Answer: It is entirely possible that you are the first person to notice obvious flaws in system calls and function library files that are used repeatedly by thousands of users. It is more likely that you have no basis at all. Extraordinary claims require extraordinary evidence, and when you make such a claim, you must back it up with clear and detailed defect documentation.

Question: I’m having trouble installing Linux (or X), can you help me?

Answer: No, I can only find the problem by working on your computer myself. Still go to your local Linux user groups for practical guidance (you can find a list of user groups here).

Note: If the installation problem is related to a certain Linux distribution, it may be appropriate to ask on its mailing list, forum, or local user group. At this point, the precise details of the problem should be described. Before doing this, do a careful keyword search using Linux and all the suspected hardware.

Question: How can I hack the root account/steal OP privileges/read other people’s emails?

Answer: If you want to do this, you are a despicable person; if you want to find a hacker to help you, you are an idiot!

Good questions and dumb questions

Finally, I will give some examples to illustrate how to ask smart questions; two ways of asking the same question are put together, one is stupid, and the other is wise.

Stupid question:

Where can I find information about Foonly Flurbamatic?

This kind of question is nothing but an answer like STFW.

Smart Questions:

I Googled “Foonly Flurbamatic 2600” but found no useful results. Does anyone know where I can find information on programming this kind of device?

This question has been STFW and it looks like he’s really in trouble.

Stupid question:

The source code I found from the foo project cannot be compiled. Why does it suck?

He felt it was everyone else’s fault, the arrogant questioner.

Smart Questions:

The foo project code cannot be compiled under Nulix version 6.2. I’ve read the FAQ, but it doesn’t mention issues related to Nulix. This is a record of my compilation process. Is there anything I did wrong?

The questioner has specified the environment, read the FAQ, and listed the error, and he has not put the questionPutting the blame on others, his problems deserve attention.

Stupid question:

There is something wrong with my motherboard, who can help me?

A hacker’s answer to a question like this is usually: Okay, do you want a pat on the back and a diaper change? and then press the delete key.

Smart Questions:

I tried X, Y, and Z on the S2464 motherboard, but that didn’t work, so I tried A, B, and C. Please note the strange behavior when I try C. Apparently florbish was grommicking, but with surprising results. What commonly causes grommicking on Athlon MP motherboards? Does anyone know what tests I should do next to find the problem?

This guy, from another perspective, deserves to be answered. He has shown the ability to solve problems rather than waiting for answers to fall from the sky.

In the last question, note the subtle but important difference between telling me the answer and giving me clues as to what else I should do diagnostically.

In fact, the latter question originated from an actual question posted on the Linux kernel mailing list (lkml) in August 2001. I (Eric) was the one asking the question. I observed this unexplained lockup on a Tyan S2464 motherboard, and list members provided great information to resolve the issue.

Through my questioning method, I give others something to chew on; I try to make it easy for people to participate and be drawn in. I showed that I was equally capable as them and invited them to discuss it with me. By telling them about the detours I’ve taken so they don’t waste any more time, I also show respect for their valuable time.

Later, when I thanked everyone and appreciated the good discussion, a member of the Linux kernel mailing list said that he felt that my problem was not solved because I was the first person on the list. People, but because I asked the question in the right way.

A hacker is, in a way, a very knowledgeable but impersonal person; I believe he is right, if I ask questions like a beggar, no matter who I am, I am bound to annoy someone or be criticized. They ignore. He suggested I write it down, which led directly to this guide.

If you don’t get an answer

If you still don’t get an answer, please don’t assume that we don’t think we can help you. Sometimes it’s just that the person seeing your question doesn’t know the answer. Not responding doesn’t mean you’re being ignored, although admittedly the difference is hard to tell.

Overall, simply posting questions repeatedly is a bad idea. This will be viewed as pointless noise. Be patient, the person who knows the answer to your question may live in a different time zone, may be sleeping, or your question may not have been organized in the first place.

You can get help through other channels, which are often better suited to beginners’ needs.

There are many online and local user groups made up of passionate software enthusiasts (even though they may have never written any software themselves). Often people form such groups to help each other and help newbies.

Additionally, there are many business companies you can turn to for help, no matter how big or small. Don’t be frustrated by having to pay to get help! After all, if your car’s engine cylinder seal blows – which is entirely possible – you’d still have to take it to a garage and pay for the repairs. Even if the software doesn’t cost you a penny, you can’t force technical support to always be free.

For popular software like Linux, each developer will have at least tens of thousands of users. It is simply impossible for one person to handle calls for help from tens of thousands of users. You know, even if you have to pay for these assistance, what you pay is negligible compared with the similar software you purchased (usually the technical support cost of closed source software is much higher than that of open source software, and the content is also limited. not as rich).

How to answer questions better

**Be kind. ** The pressure of problems often makes people appear rude or stupid, but they are not.

**Replies privately to first time offenders. ** There is no need to publicly shame those who confess their mistakes. A true newbie may not even know how to search or where to find FAQs.

**If you’re not sure, always speak up! ** An authoritative-sounding incorrect reply is worse than none at all. Don’t give people directions just because it’s fun to sound like an expert. Be humble and honest and set a good example for both the questioner and your peers.

**If you can’t help, don’t get in his way. ** Don’t joke about the actual steps, as that might ruin the questioner’s setup - some poor fool will take it as a real instruction.

**Probing rhetorical questions to elicit more details. ** If you do a good job, the questioner can learn something - and so can you. Try turning stupid questions into good ones, and don’t forget we were all newbies once.

While it’s fair to complain about RTFM to those slackers, it would be nice to be able to link to the documentation (even if it’s just to suggest a Google search term).

**If you decide to answer, please give a good answer. ** Don’t suggest clumsy workarounds when others are using the wrong tools or methods. Recommend better tools and reframe the problem.

**Answer the question positively! ** If the questioner has researched deeply and indicated that they have tried Z , A , B , C` and attaching a link is of no use at all.

**Help your community learn from problems. ** When replying to a good question, ask yourself How can the related document or FAQ file be modified so that the same question is not answered again? , and then send a patch to the file maintainer.

If you answer after research, show your skills rather than just give the results. After all, it is better to teach a man how to fish than to teach him how to fish.

related resources

If you need a basic understanding of how personal computers, Unix systems, and networks work, see Unix Systems and Network Fundamentals.

When you release software or patches, try to follow Software Release Practices.