Post History

## Users vs. questions

Personally, I don't care much, if at all, about the motivation behind a question - as long as it isn't a thinly veiled rant or other sort of soapboxing (i.e. is genuinely a *question*). On Stack Overflow meta I would say that questions are 100% about the questions in themselves and 0% about the people asking them. Of course, here we're explicitly looking for a "community"-oriented approach, but honestly I think that doesn't make a huge difference.

There is value in trying to "onboard" people and get them used to community norms etc. so they can ask better questions, but any site that gets large enough will eventually accumulate a long tail of people who have zero-to-minimal interest in long-term engagement. Expecting a "minimal level of effort" is helpful insofar as it deters "help vampires" from repeatedly asking bad questions. But *many people who ask a lazy question won't come back anyway*, no matter how we treat the question (and even if it's the uncommon "lazy but good" question). It's not possible to predict in advance who the help vampires will be.

## Different types of "lack of effort"

If the answer is found "with a 5 second [web search]", *ideally* that would be a web search that leads to an existing Codidact question - that would be evidence of Codidact taking over as the go-to Q&A site, and what loftier goal could a Q&A site have? As I said [on Software meta](https://software.codidact.com/posts/285035/289176#answer-289176) (which I also linked on your other question about "clutter", and from the other Software meta question that Lundin linked): we can keep Codidact DRY, but we can't keep the Internet DRY. If we want to grow Codidact communities then we **must** host information that is found in some form elsewhere on the Internet, even in easily found places. If we do not, then people have no reason to come here for information. Simple as that.

If the answer is found "by reading the question title back", then that is simply not a good question. Rubber ducks are only useful to their owners. Such questions should be promptly removed, if there is no evidence of a *common underlying* question (e.g. about a common misconception or gotcha).

If someone "finds the material hard to understand or difficult to read", then *that is exactly the place where a Q&A site can add value*. It would be absurd to turn away such questions, as they are the very lifeblood of Q&A sites and the reason for their existence. Documentation often provides all the necessary information but fails to *answer the underlying question*.

For example, documentation commonly lists what each tool in a collection does, but in order to figure out the right tool for your task, you need to reverse that mapping. In the best case, the combination of documentation and web search solves the problem. But often you need to search again within a candidate page, and then you might discover that it's the wrong documentation page and have to try again. Or maybe you don't conceptualize the task in the same way that the documentation does, and therefore can't craft an effective search for the task description, and don't find the tool.

Then again, sometimes someone has *already* found documentation, and then is confused by what is written there. In a *lot* of these cases, this process is actually irrelevant background noise - the confusion has resulted in a new question that is independent of the task that motivated the search for documentation. This situation doesn't represent *zero* effort, but it often represents less effort than we'd like. What I propose is that the lack of effort isn't a problem *in itself*, but it can be a problem because of the *effect on the question phrasing*. Such questions should be edited to *reflect what they're actually about*.

Relatedly, sometimes in computing contexts, people get an error message and just freeze up at that point. It's important to be able to point people at reference material for understanding and diagnosing such error messages, even if we aren't interested in fixing a specific user's issue. Even something as simple (please pardon the specific, programming-related example) as "A `TypeError` is an `Error` that happened because something has the wrong `Type`" is worthy of elaboration: the very underlying concept of "type" may need explanation, and there are many potential approaches to resolving the problem *that need to be carefully considered* (Which thing has the wrong type? What should the type(s) be instead, and why? Can the type be converted straightforwardly? What should be the semantics of such a conversion? Is the proximate cause of the problem also the *ultimate* cause, or was there some other code earlier that produced an intermediate result with the wrong type?).