Low effort questions with lack of basic troubleshooting

Question

I have been active trying to help people here on serverfault and have been in IT for 15 years, and it's a problem on a lot of communities. But it would be great if we could provide feedback with something lacks basic troubleshooting and with a link to a faq article for basic troubleshooting

Answer 1

I have been playing the ServerFault game for almost as long as you have been an IT professional.

I have learned that, 'no one who needs to, reads anything'.

There are so many questions posted with an excerpt from their terminal that clearly tells them to run systemctl ... or journalctl ... to get more details and ... they just don't do that.

My advice for helping people with low effort and lack of basic trouble shooting.

• Ask them for relevant excerpts from their logs in a comment.
• Downvote for lack of effort.
• Vote to close for lack of detail (Closing-> A Community-specific reason -> Option 2)
• Get on with the est of your life, safe in the knowledge that you have helped the OP and the internet in general be better.

If, in the unlikely event that the OP does provide further information,and edits it into their question you can always remove your downvote and closevote. Rest assured though that this will be an exceedingly rare event.

Answer 2

Our comments and close-voting are the intended feedback avenue for "insufficient troubleshooting." People are quite active with close-votes for this reason, believe me.

As for a FAQ list or similar, we've deliberately not built that framework; "read the docs, come back after you've done that," feels like that great 1990s phrase:

Talk to the hand.

And that isn't nice. Most historic sysadmin communities self-police this way; with best-practice and knowledge bars required for continued existence in the community, often enforced through sarcasm.

The way most StackExchange sites work is we don't require askers to be familiar with our canon of knowledge before asking questions. In part this is because there isn't a canon of knowledge!

• Documentation often doesn't cover every use-case.
• Documentation often goes stale, especially on volunteer-run sites like this
• Documentation often does a bad job of covering all versions of a thing in use
• Writing good documentation requires skills, which are not evenly distributed on volunteer sites like this
• Understanding what documentation is telling you is also a skill
• Remembering what documentation actually covers is not the same as what's actually in there, leading to cases of "READ THE FAQ BEFORE POSTING!!!" when the FAQ hasn't covered that in a while.

FAQs are best used for insular communities invested in gatekeeping membership.