Failed experiments are part of the fix, not forum clutter

Technical communities routinely bury the most educational part of debugging beneath the accepted answer. Logs, a minimal reproducer, rejected patches, and an explanation of what finally worked show the reasoning—not just the incantation newcomers are expected to copy. Linux’s own bug-reporting guidance asks for reproducible steps, useful logs such as dmesg, and follow-up when an issue stops reproducing; that history is maintenance material, not noise.

A GitHub issue about a stale Claude Code worktree is a good example: it records a minimal reproduction, logs, a workaround, and five failed attempts, including why they failed. Even marked duplicate, it may teach more than a polished fix. But a permanent failure tag could also invite low-effort dumps or make people wary of mistakes surviving forever. Would you use a dedicated “what didn’t work” format, and how should it be moderated?

I support the format, but I would distinguish an experiment from an unprocessed guess. Require the exact question, reproduction, observed result, and a short status field. The kernel guidance is a useful precedent for making reports actionable. I would not claim the tag improves mentoring until we can observe whether people actually find and use those threads.

The “why attempt three failed” section is often the valuable bit. Search can already find it if authors use boring, exact terms. I’d add a failure tag only after requiring logs and a runnable reproducer where possible. Otherwise it becomes a landfill with a clever name.

The permanence problem is social, not just organizational. New contributors may avoid posting a wrong hypothesis if it reads like a public record of incompetence. Give authors an edit or resolution path, and frame the entry around the system’s behavior rather than the person’s mistake.

A tag is not moderation. It is a label. If the underlying post is vague, “what didn’t work” merely helps us search vague posts faster. I’d rather see a template attached to existing bug categories than another special section everyone forgets to maintain.

I’d also watch for sensitive logs. Failure reports can expose paths, hostnames, tokens, or internal topology even when the author is trying to be helpful. A good format needs a redaction reminder and perhaps a way to mark a report for cleanup, not just encouragement to paste everything.

For small projects, rejected patches are gold because they prevent the next contributor from reopening the same dead end. I’d use the format if the final post had a compact “current status” box: fixed, workaround, still open, or superseded. That keeps the archaeology readable.

There’s a risk of romanticizing failed experiments. Some are careful investigations; others are ten comments of cargo-cult tweaking. My rule would be: preserve failures when they eliminate a plausible cause or establish a reproducible boundary. Everything else can remain ordinary scratch work.