A correct answer is not always a good teaching answer

I’ve answered enough open-source debugging questions to see “correct” and “good teaching” treated as if they were the same thing. They aren’t. A response can solve the immediate bug while explaining almost nothing, or explain the concept well while not being the fastest fix. One vote score compresses correctness, clarity, usefulness, and educational value into a single signal.

For example, telling someone to run `strace` may reveal that a program gets `ENOENT`, but a beginner also needs to know that this means a system call could not find something, and why copying a command blindly may be unsafe. Current reputation systems may, in my view, reward speed and certainty more readily than mentorship. Not every answer needs to become a tutorial, though.

Would separate labels for “solves the bug,” “explains the concept,” and “safe for beginners to copy” improve learning, or merely add moderation overhead? Disagree, or share examples from forums you use.

The distinction is useful, but I’d be careful about presenting the incentive claim as established. We can observe that votes and accepted answers affect visibility and reputation; whether that systematically suppresses mentorship needs evidence. Labels might at least make the different judgments explicit.

Three labels become three arguments, then six labels, then a committee. I’d rather see a concise fix plus an optional “why” paragraph. Searchers usually need the answer first.

A single score is a poor interface for multiple reader goals. Someone fixing production and someone learning Linux are not asking the same question. Even simple badges like “concept explained” could help without pretending to measure teaching perfectly.

“Safe to copy” is the tricky one. A command can be harmless on a disposable VM and destructive on a real host. That label needs context, not just a reviewer’s confidence.

I post the shortest working fix first because buried fixes are useless. If the mechanism matters, I add it below. Separate scoring sounds nice, but I’d judge answers by whether the asker can move forward.

This is partly a product-design problem: the forum is optimizing for fast retrieval, while mentorship is a different user journey. I’d test lightweight reader reactions before creating a formal reputation subsystem.

A teaching label could punish correct specialization. Experts often need a precise one-line reminder, not an introductory lesson. The reader should be able to choose depth rather than making every author provide it.

I’d support a safety flag more strongly than a teaching score. “Do not run this without checking X” is actionable. Educational quality is subjective; operational risk is often easier to identify.

The practical compromise is formatting: command, expected output, one sentence explaining why. That gets most of the benefit without turning voting into a rubric.

Support teams already separate resolution from documentation quality because a ticket can be closed while the next person learns nothing. Forums could borrow that distinction, though someone still has to maintain the categories.

For durable systems, explanations age better than command recipes. Package names, paths, and defaults change; understanding what `ENOENT` represents usually survives. I’d value a small explanation even when the fix is obvious.

Beginner safety also depends on environment, permissions, and data sensitivity. A universal label may create false reassurance. A required warning field for destructive commands seems more defensible.

Metrics create incentives, but not always the ones intended. If a terse answer earns the same visible reward as a careful one, people will rationally optimize for terseness—unless readers signal otherwise.

I’ve changed my mind slightly: separate feedback could be valuable if it stays private or lightweight. Public scores invite gaming; a “this taught me why” reaction might give authors useful direction without another leaderboard.