Timeline for Does this diagnose-this-crash question remind anyone else of identify-this-game?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 19, 2013 at 20:11 | comment | added | Frank | let us continue this discussion in chat | |
| Feb 19, 2013 at 20:11 | comment | added | AaronLS | @fbueckert The community does not provide tech support through questions. For exactly the reasons I stated, the question becomes localized and useless to others, and thus they must duplicate questions. Answers should be formulated to not be localized, which means troubleshooting steps are included in them. If you want to provide tech support, take it to a chat room. If you want to provide valuable answers that are appropriate to stackexchange, then follow my guidelines. | |
| Feb 19, 2013 at 20:08 | comment | added | AaronLS | Bottom line is questions on stackexchange should become resources, and they should be answered in a way that cause a need for others to ask the same duplicate question later because the answer for that question didn't solve their problem. If you want to provide one-on-many crowd sourced support as you are describing, then that should take place exclusively in the chat rooms because it adds no value to the community. | |
| Feb 19, 2013 at 20:08 | comment | added | Frank | I've done my time as tech support. Users don't care about what broke. They care about fixing it. They're also not interested in learning how to fix it themselves, so spending time on telling them things they're just going to ignore is wasted. Here's the problem, here's a possible solution. Done and done. They can read the comments if they're interested in the why. | |
| Feb 19, 2013 at 20:05 | comment | added | AaronLS | @fbueckert You don't understand that "how to fix it" includes the troubleshooting process. You are giving a man a fish instead of teaching him how to fish. That localized answer is of ultimately no use to the other 80% of people with CTDs. You end up with duplicate questions, but different answers, which is a bit of a paradox and the reason why stackexchange would encourage a more systematic answer as a community wiki in this case. That's my last response and I'm done. I have alot of experience in doing support, and documenting solutions to complex issues. | |
| Feb 19, 2013 at 20:00 | comment | added | Frank | And that's all we need. The troubleshooting is anecdotal to the actual problem. People don't need to know what went wrong. They need to know how to fix it. If there are several different solutions, that's fine. That's what tech support is about. But the actual diagnosis and isolation of the issue has nothing to do with fixing the issue. It just helps you figure out where the issue is. | |
| Feb 19, 2013 at 19:59 | comment | added | AaronLS | @fbueckert The question will never serve as a resource in that capacity, as it will be too localized. After all the investigation through comments, the asker finds the solution and posts it as the answer. However, that answer is only the side affect of the systematic approach of discovering the problem. If you as a community develop a systematic answer to the question "How to solve Oblivion CTD?" then you can create a question that is useful to everyone with that problem. | |
| Feb 19, 2013 at 19:56 | comment | added | AaronLS | This again is why I suggest community wikis are best for these questions, because just like a sticky in a forum for Oblivion for example, the community has to over time develop a systematic approach to solving the problem, simply because it is so complex and ambiguous. | |
| Feb 19, 2013 at 19:56 | comment | added | Frank | We're not disallowing tech support questions. We just work a little differently, in that we prefer tech support to happen in the comments instead of as answers. That's what I was referring to. We define answers as answers, not some place to put troubleshooting steps that may or may not resolve the issue. | |
| Feb 19, 2013 at 19:54 | comment | added | AaronLS | @fbueckert If you want to decide as a community to disallow posting questions about crashes/bugs, that's your decision. But how you describe the path to a solution for a very ambiguous problem is universal, don't redefine "solution". Because the problem has little information, like a CTD, you have to perform many steps to investigate the cause and test fixes. That is here, or there, or wherever, the only way you can come to a definitive solution to such problems. It's not a problem with the question or answers, it's simply a side affect of the CTDs providing no error/log information | |
| Feb 19, 2013 at 19:41 | comment | added | Frank | Arqade != Superuser. We work a little differently here. | |
| Feb 19, 2013 at 17:15 | comment | added | AaronLS | @Mbraedley By your logic more than half of the answers on serverfault/superuser would be comments. | |
| Feb 19, 2013 at 17:14 | comment | added | AaronLS | @fbueckert "'This is what worked for me.' Not, 'Try this and see if it helps.'", other than the wording, there is no difference. "Try this" is a suggestion that is made on the pretense that it has worked for others before. They are part of the information gathering process. They are a systematic solution. It is the very essence of how troubleshooting works. Change a variable, make an observation, change something else as a result of that observation, etc. rinse repeat. In superuser/serverfault or if you do support, you know these aren't guesses, they are parts of a path to a solution. | |
| Feb 19, 2013 at 11:43 | comment | added | MBraedley | @galacticninja: I disagree. The only place to put "Try this" steps is in the comments. 9 times out of 10, they aren't full solutions, but rather just an indicator of the true problem. If the step succeeds (or fails, as the case may be), then the commenter can post the full solution as an answer. Remember, we're looking for a solution to a problem in this context. Anything that is not a full solution does not belong in the answer section. | |
| Feb 19, 2013 at 8:17 | comment | added | galacticninja | @fbueckert "Try this and see if it helps" answers are not necessarily bad in this context. To troubleshoot most crashes (to help the OP and other people with a similar issue), one would need to to try out different things, i.e. troubleshooting checklists or steps (AKA "things that might work") to see which issue is causing the crashes, and to try out a proper solution. The comment box is oftentimes, not an appropriate medium or format to put detailed troubleshooting checklists/steps and fixes on, which if long enough, should warrant its own answer. | |
| Feb 19, 2013 at 5:00 | comment | added | Frank | Answers on questions should not be guesses, or things that might work. At the very least, if you encounter an error, and you resolve it, your answer should be, "This is what worked for me." Not, "Try this and see if it helps." That's what comments are for. | |
| Feb 19, 2013 at 4:37 | history | answered | AaronLS | CC BY-SA 3.0 |