Let's refine and clarify our off-topic close reasons

Question

Recently I have noticed, both as a user and a moderator, a good number of questions either being closed as end-of-life or as a development release when they probably don’t need to be.

Just a few examples:

• ERROR: 32-bit Linux Android emulator binaries are DEPRECATED when attemping to run the Android emulator The OP is running an End of Life Ubuntu release, but the question itself has nothing to do with that fact, any Ubuntu release could experience this problem, it simply stems from the fact that they are running a 32bit operating system. To this end I added an answer detailing a solution and added a comment explaining why I didn’t close the post.

• Why did my highlights turn pink in Xubuntu 14.10? This question is about a development release (at the time of this writing), but it isn’t a problem or feature that will be fixed or changed before the actual release happens, nor is it a bug (although someone did file one). It was also asked within a few weeks of Utopic’s official release, but still got 4 close votes and was almost closed.

After pondering over this a bit I realized one problem that contributes to this issue is the close reasons themselves. In my opinion the wording of both the EoL and Bug/Development release close reasons is overly broad. We understood them at the time they were written, but time hasn’t been too generous to them and they’ve widened out substantially since first introduced.

To this end I suggest we edit both of the aforementioned reasons to be more specific, in line with the actual site policies, something around this:

This question is specific to an end of life Ubuntu release . These are no longer supported and therefore off-topic here. To upgrade, see How to install software or upgrade from and old, unsupported, release

and

Bug reports and problems specific to development versions of Ubuntu should be reported on Launchpad so that developers can see, track, and fix these issues.

Note the “specific to” part.

Hopefully this will help clear up any confusion about what questions genuinely need these close reasons and which ones could probably just use an edit (or sometimes just being left alone completely).

Why is this even an issue?

For several reasons. Not only is this costing us precious review time (Oli goes over review time math in another post), but in the end I don’t believe it helps the site any. Many of these questions are good and useful posts and by closing them we’re sending them towards the dustbin, which doesn’t further the goals of the site: to help people with their problems while generating a collection of useful content for later generations.

What do you think? If you have even better wording for the reasons I’d especially like to hear it!

Answer 1

Yes! I think this is a great idea. Way too many perfectly valid questions are being closed by trigger happy reviewers simply because the OP happens to be using an older or newer version than we'd like. I think what you're proposing makes a lot of sense since it is just a tiny shift in emphasis and will make the intended scope of the close reasons clearer.

For example, if I were to ask how to do X on the command line and had the misfortune of mentioning I am using a development version, my question would be closed and the wording of the close reasons would support that. However, the chances of any bash solution not working on a different Ubuntu version are slim to none. Yes, it might theoretically happen but most bash questions here are quite basic and would apply to any *nix system of the last 10 years or so.

I also disagree with this idea of "shifting the responsibility". First of all, the onus of checking whether something should be closed has always been on the reviewer. With very few exceptions, the OP does not vote to close their own question. We don't, and can't, expect novice users to know enough about a subject to guess whether it would be specific to their particular Ubuntu version. That's always been up to us, the experts. If the user knew that, they often wouldn't have needed to ask a question in the first place. Heck, I've been using Linux for 15 years and I can't always tell either. While we can and do expect users to familiarize themselves with the site's scope and be on topic, expecting them to know whether a question is only applicable to a specific version is a bit much.

Seth is not suggesting any change to the site's scope, he is just saying that the scope should be more accurately reflected in the close reasons.

Answer 2

Current ruling actually achieves only 2 things:

• Newbies with previous version of Ubuntu feel like they had been shown at the door. This is especially rude in November and May.
• Experienced users will omit or tell lie about ubuntu version.

If one thinks that non-supported ubuntu version is actually the culprit in given question, he should flag it and explain in comment why he thinks upgrading will fix it. For example "This feature was implemented in Kde 4.11" or something. On the other hand I know a dozen of bugs that are here since 2010 and still not fixed in Unicorn. If another newbie runs into such bug, his question should be marked as duplicate (which points to solution).

Answer 3

I disagree. My first response to an EOL question will always be to vote-close as off-topic it for being EOL, or as a dupe to the old-releases question, unless someone conclusively proves that:

• The question is independent of release
• NO answer is specific to that release
• Upgrading to a supported release will not solve the issue

In particular, consider Eliah Kagan's comment in your first example:

... this is in the minority of new questions about a problem in an EoL release where (a) we know the answer is release-independent, and (b) both the question and the answer (because they involve a common activity with a non-obvious pitfall) seem like they may be of especially high value to others. This could be edited to generalize it to all releases ...

For example, say the poster has a problem with $EOL_RELEASE. Let them post it. If they, or someone else, shows that it also happens on $SUPPORTED_RELEASE, we can simply reword the question to make it on-topic. If they can't, close vote or perhaps migrate to U&L.

And your second example is a non-problem, so it's already covered by the current wording. It's more curiosity than anything else. If someone asked a question about the reasons behind the migration to systemd, I wouldn't close it, since it is not a problem. (It might be too broad, though.) No change needed here.

My main issue with this proposal is this:

The proposed wording shifts the burden of proof from the poster to the reviewer, whereas I want it to be solidly on the poster.

The current wording is fine by me.

If the poster really wants help, let them post on Unix & Linux, where we have no restriction on releases, and where quite a few of us are also active. We have a set of topics on-topic here, and EOL/development release problems are not in that set.