I just found this in the review queue: Does it matter that wlan0 has changed its name to eth1 after I upgraded to 12.04? It has a couple of votes to close as off-topic, I assume because somebody posted a link to this bug report and they thought:
I can see the word Launchpad on the page!
It must be a bug!
Let's close this now!
I'm all for closing flat-out bugs as bugs but there are a few problems with this bug report:
It's a really bad bug report. The report blames udev because the user found a udev configuration file. People who know what udev does will know it just parrots what it's told to do. The reason udev is calling this interface eth1 instead of wlan0 is because the Kernel told it to.
The problem actually lies in the gradual change in Broadcom drivers. As somebody who was doing a lot of kernel compiling around the 12.04 release, I've seen how violently the naming convention has flipped around but anybody upgrading with the right hardware probably would have seen this too.
The problem isn't actually a problem. No applications I've seen have given two hoots whether or not wireless hardware was called
eth*
.
And that's all the answer needed to say. "It's a driver quirk but it shouldn't give you problems".
"But Oli, not everybody knows the sordid history of Broadcom drivers like you do!"
Sure, but everybody voting has the ability to read that bug thread. By comment #4 you can see it might not be udev. The mere fact it's "confirmed" means nothing. That just means more than a couple of people say they see the same behaviour. The plural of anecdote is not data.
And it's clear to see there's no actual resolution. There's no diagnosis churn and there's no indication whether this is something to worry about. It doesn't answer the question at hand.
A person came to us asking if they had a problem and we're telling them to shut up and watch a dead bug report. That's not good enough.
If you don't have the technical je-ne-sais-quoi to make determinations like these, perhaps you shouldn't be voting either way. That's fine. We don't expect everybody to know everything, just skip it.
If you think you do, please make sure you're reviewing bug reports as well as the questions.
And [almost] lastly, just because the answer is "Look at this bug report", it doesn't mean the question is off-topic or a bug report.
If it's a known bug, a good answer linking to the bug, explaining the problems (and answering sub-questions) is better than voting to close as a bug report. It's more helpful to the user and it'll be better for attracting future searchers with the same issue (and therefore stopping dupes).
Edit: "But we've always closed bug reports..."
Yes and no. Historically we closed bug reports. Issues where people would come onto the site and say "Firefox doesn't work" as "not a real question" because they weren't questions. Those sort of shouty posts are still fair game. Tell them to go and file a bug report in the right place using the OT reason.
What I have been talking about here (and to a degree what Braiam has distilled into just a few words in his answer) is some people are targeting "things suspected of being bug behaviours" and are trying to get them off the site.
Well over 90% of all our questions here are in some way related to a bug of some sort. A design flaw, missing drivers, PEBCAK-through-poor-design-or-documentation. If we followed this and closed everything that fell into the gaping chasm of suspected bugs, we'd have twelve questions left and half as many users.
By all means push people to Launchpad, just don't forget we're a community support site. We fulfil our goals by helping people, not having the most conditioned answer rate.
And this also helps us. It's not just about attracting people here, it's resolving their problems. If they have a problem and Google brings them to an OT-Bug question simply, what do they do next? Is there a LP bug attached to it? Do they know what that means? Does that even help (cite this one... which doesn't). If that process hasn't answered the problem to some degree, they're going to ask somewhere. It doesn't matter where but that's the moment where we've just failed.
An answer with a documented explanation wins. Explains the problem. Explains where the problem is being handled. Answers periphery questions.