Are diagnostics/troubleshooting issues on-topic and not too localized?

Question

Following on from this question. I made a comment there:

By the same token, we shouldn't automatically close any question that says "virus" anywhere in the subject or body, because it may be that the user is mistaken in believing that they have a virus, when in fact, it's just good old fashioned broken software that may be able to be fixed somehow. My dad, for one, being extremely tech-unsavvy, thinks it's a virus when almost anything goes wrong with his PC. Many users come to us having already "pre-diagnosed" the symptoms they're seeing with their PC, and, not being experts, can easily get the diagnosis wrong and mislead themselves and us.

This led me to continue the discussion in Root Access, where this chat line drummed up some more discussion about the issue.

The general gradient of reasoning of the proponents of closing these types of questions goes something like this:

---

• Assumption: We have a canonical question/answer about how to deal with viruses. (Valid)
• Assertion: When the user thinks they have a virus, they should take the advice in the canonical question, i.e. nuke their system. Then we should nuke their question as a duplicate. (Debated)
• Assertion: If the user is incorrect in their diagnosis that it's a virus, then it will take a lot of back and forth comments and tooth-pulling to get them to provide us the info we need to properly diagnose the problem. (Valid)
• Assertion: Even if the user does not even attempt to provide an alleged diagnosis of their problems, and instead merely reports their symptoms, the question shifts from being a duplicate to being too localized, and is still a bad question. (Citation)

---

This seems like we're sliding down a slippery slope of becoming increasingly strict. I don't think it makes sense to close all questions which don't have encyclopedic significance; that would make us a clone of Wikipedia. Also, not every question that's asked, and not every set of symptoms that are reported, will already have a question previously asked about those symptoms. But the fact is, troubleshooting very often, if not always, requires a lot of "back and forth" chit-chat. Troubleshooting fundamentally involves:

• Having limited information about what the symptoms are;
• Having limited information about what the root cause is;
• Having limited information about what the solution is;
• Trying various things that either provide more information, or potentially reveal / shed light on root causes, or actually resolve the problem;
• Referring to help manuals, forum posts, technical knowledge bases, and possibly related SE network questions/answers which may or may not help.

When we encounter a question with limited information about what the symptoms and root cause of the problem are, should we:

• Close the question because it's going to be too chatty?
• Close the question because it's too localized?
• Leave it open and attempt to help them in comments until we have a definite answer, then post the answer?
• Invite them into a chat.stackexchange.com chat room (in our case, Root Access)? If we do so, what becomes of the question?

What I'm trying to accomplish with this question is just to collate some different opinions on what should be done in these cases.

Answer 1

Troubleshooting questions are bad!

We are a Question & Answer site, not a forum. You mentioned becoming a clone of Wikipedia, which is basically exactly what we should be. (Obviously, we don't want to be an exact clone, but we want to be an encyclopedia of problems and solutions to these problems).

When thinking about if a certain type of question (or a single one in particular) is good for the site, ask yourself if the question will help future visitors. A question that requires troubleshooting to get to the real problem will usually not be useful to people. Chances are, they have the same symptoms, but not the same problem.

When a user presents a problem where it is obvious that there could be numerous reasons and troubleshooting is required to solve it, the actual problem that needs to be solved is often far away from what has been described in the question. The user will describe symptoms but not realize the problem.

This is not helpful to a future visitor. The visitor may find the question through a search engine only to realize that it is about something completely unrelated to their problem.

Let me paint a picture:

Question: "Why is my winxp computer SO SLOW all of a sudden?!?!?!"

Comment: "Please run Process Monitor and look for weird things."

Reply: "wat is a process monitor?"

Comment: "It's an application you can download here. Run it and record a log."

Reply: "i did there is lots of stuff. where does it say why my computer is slow????"

...50 comments later

Reply: "OOOOHHH!!! so your saying that mining bitcoins at realtime process priority causes my computer to be slow? that stupid! XP SUXXX"

Comment: "Be that as it may, just turn down the process priority and you'll be fine."

...unless they are canonical.

People who post questions like that need to be redirected to other questions that outline processes of how to get closer to the problem. As in:

• What is the proper way of debugging a slow Windows installation?
• How do I troubleshoot a Windows freeze or slowness?
• How can I analyze performance issues before/during the logon process?

It's a lot more useful to post a ton of questions like the ones above than to hold a users hand while they try to diagnose a problem. Help them to help themselves.

Once they have helped themselves, they can bring the collected "evidence" to a proper question and present their real problem. Future visitors who already know their real problem will be very happy about finding an actual solution on our site.

And if the future visitor also doesn't have a clue about what the problem is, then they'll find directions on how to find the problem (and not some troubleshooting path that only solves a single problem with those symptoms).

Answer 2

Summary : We should be focusing more on the "Why can X be/(not be) done?" type of questions, and remove some of the sNARQ.

For debugging any specific issue with a person's computer, you need a back-and-forth approach to be able to iterate between different solutions, starting from simple to complex.

SU is directly opposed to that by discouraging back-and-forth in the comments. I think we'll all agree SU chatroom is not THE most helpful (please hold the flames) community of people from the point of view of the askers.

These types of issues are best dealt with in forums such as Sevenforums, Eightforums(http://www.eightforums.com) and other zillions of them. They have FAQs, multiple users, tutorials, and even a tiered system akin to a tech-support setup, where the simple stuff is handled by power users and the nutty cases by extremely-highly-experienced users or developers of tools.

Here on the other hand, it most definitely creates a million duplicates. Few of them result in solutions, because you don't get the handholding required when facing a very unfamiliar task. SU doesn't even greatly result in askers becoming more knowledgable in comparison to the situation at good forums. The community feel of a forum results in a lot more learning.

If you remove tech-support from SU, then you come to the "How Do I Do X?" type of questions. Here I mean those which are not also tech-support style. These are the best fit for SU right now. Granted, back-and-forth happens here also, but tech-support is about recovering from failure which happens in a lot more ways. In a properly working system, OTOH, rarely would a HowTo mysteriously not work resulting in back-and-forth.

SU doesn't seem suited for it at all. SU should be more about in-depth explanations about mechanisms, tradeoffs, little-known problems, and subtle pitfalls. BUT this heads out into the oh-so-dangerous territory of Not A Real Question.

Answer 3

This question and the answers are great. However, I keep running into the same issue because no change in practice has resulted from the discussion. Let me describe some additional considerations.

• There cannot be a definitive answer for these question as asked (other than sheer luck that someone recognizes the issue), so at least initially, these questions don't fit the site's definition.

• These questions often don't lead to normal SU answers, so they are never brought to closure (as in finished). At some point during the questions and tests, the OP solves the problem (or gives up, in which case no answer is possible). In most cases, no formal answer is prepared and these end up bloating the pool of unanswered questions.

• Even though a definitive answer isn't initially possible, these questions often attract lots of bad answers (helpful suggestions that should be comments, or speculative solutions).

• While the question asked is, "How do I solve this problem?", it is really a potentially long sequence of questions, "What test do I run next?" Each of those component questions can be the equivalent of another "normal" SU question, often requiring a tutorial. So these problems quickly exceed the intended scope of a question.

• Usually, the OP lacks the rep to move the problem to a chat room where things could at least be explored off-line.

It appears that there is unanimous agreement that these are bad questions for SU. The suggestions are to send the OP to canonical Q&A or one of the forums. We generally do neither. I would like to suggest that we adopt an explicit position on handling these and actively apply it.

• "Officially" define these as off-topic. They could be added to the "too broad" category. Incorporate verbiage so people are aware of the "standard".

• As with any off-topic question, these would be subject to closure votes when they arrive, potentially with referral to named or unnamed forums, or canonical Q&A (when an indexed resource is available).