17

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!

8
  • Lets ask the obvious question... are you (or the asker, for what matters) able to reproduce each of the behaviors in non-EOL, or non-Ubuntu+1 versions?
    – Braiam
    Oct 25, 2014 at 1:19
  • 1
    @Braiam Lets use common sense. Did I try each and every one? No. But it shouldn't be a requirement. One look at either this or this should tell you, an experienced user, that neither problem is specific to the release. However, this whole "can you verify it isn't specific" is just a red herring. I'm not talking about not closing EoL posts, I'm talking about updating the close reasons to reflect the actual policy.
    – Seth
    Oct 25, 2014 at 1:31
  • If you want to discuss when and when not to close questions that mention EoL releases you might want to start a new post.
    – Seth
    Oct 25, 2014 at 1:32
  • 2
    I did, several weeks ago, pointed out that problem, and nobody listened to me, actually, the efforts were shut down. If what I said at the time was implemented we wouldn't be talking about this problem, so I'm kind of "I told you so". The problem is, that you are essentially saying that we should demonstrate that isn't EOL, where is OP's responsibility that they should fit withing the scope of the site, not ours. We already has many problems to start babysitting each and every question. That just don't escalate.
    – Braiam
    Oct 25, 2014 at 1:47
  • Oh, BTW, you have your priorities backwards: we "collection of useful content" which end with the by byproduct "help people with their problems". That's why upvotes on answers has double the reward than on questions.
    – Braiam
    Oct 25, 2014 at 1:59
  • 1
    @Braiam This isn't "demonstrate it isn't EoL" this is if it isn't specific don't close it. How hard is it? I'm really sick of this "PROVE it" herring. I must admit I don't remember seeing your Quantal PSA, and I agree with almost all of it, but especially bullet one (we have been doing that for a while now, but the close reasons didn't reflect it well, hence this question). Still, I'd hardly call Marco's comments "shutting down" ;)
    – Seth
    Oct 25, 2014 at 2:01
  • You even say in your first bullet "New questions about Quantal 12.10 that only affect Quantal (e.g., APT dependencies, hardware, login, quirks, etc. issues) are off topic.". I don't see you asking for "proof" there. "proof" is extremely subjective and the majority of the questions we should be leaving open are extremely obvious, no "proof" needed.
    – Seth
    Oct 25, 2014 at 2:01
  • 1
    @Braiam That wasn't meant to be taken in any order... You are correct though.
    – Seth
    Oct 25, 2014 at 2:02

3 Answers 3

8

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.

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).

7
  • I'm not really sure what you mean. This isn't a ruling, just fixing the close reasons so they make sense with the current policies.
    – Seth
    Oct 27, 2014 at 13:23
  • Oops! One wrong word - entirely different meaning. Edited my answer. Oct 27, 2014 at 13:46
  • 1
    That's better but I'm still not entirely sure I understand. Do you agree with the proposed wording? We're trying to prevent both 1 and 2 as much as possible by clarifying the reasons so people stop using them wrong (i.e. closing questions just because it mentions an EoL release even though it has nothing to do with that release).
    – Seth
    Oct 27, 2014 at 14:50
  • 1
    actual experienced users just use new versions...
    – Mateo
    Oct 27, 2014 at 17:31
  • If I have Mint problems, I just replace the word "Mint" with "Ubuntu." Free Mint support :D
    – Kaz Wolfe
    Oct 28, 2014 at 17:33
  • So does everybody. This becomes problem when the culprit is actually in Mint specifics. Oct 28, 2014 at 17:35
  • @BarafuAlbino Having found this Question, after posting one of my own, I think you may have missed the point. Don't come here, for Mint Support, as there is a mint tag at U&L.SE. Practiced Site Users will know this, and Mods will vote to close for migration.
    – eyoung100
    Dec 9, 2014 at 22:44
-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.

15
  • 2
    I don't understand.. You are only reaffirming everything I already stated.. Unless you mean to say you would close this.
    – Seth
    Oct 24, 2014 at 19:56
  • 1
    @Seth let me clarify: unless someone proves it's not specific, I'll vote to close. (In that case, you provided the proof.) The proposed wording shifts the burden of proof from the poster to the reviewer, where as I want it to be solidly on the poster. If the poster can't prove it, let them go to Unix & Linux.
    – muru
    Oct 24, 2014 at 20:10
  • 1
    "unless someone[...]proves that" so you are saying in this situation they would not be closed? this is why the wording should be updated to reflect the situations where EOL's are not unequivocally off-topic.
    – Mateo
    Oct 24, 2014 at 20:10
  • @Mateo no need. Let them post on Unix & Linux. If they can show that the question is release-independent, we'll flag for migration.
    – muru
    Oct 24, 2014 at 20:12
  • @Seth also, not everything. The second example is already covered by the current wording. Not need for modification there.
    – muru
    Oct 24, 2014 at 20:15
  • 2
    On the contrary, the proposed wording does not shift the burden of proof from the OP to the reviewer. The burden of proof was already on the reviewer! While we do expect askers to have a basic understanding on site scope there is no such thing as "closed until further notice" or "closed until you can prove it's ok". The burden of proof that a question is a bad fit for the site is always on each and every individual reviewer to decide if the question is within our scope or not.
    – Seth
    Oct 24, 2014 at 21:09
  • If you have not taken the time to convince yourself that this question does indeed deserve to be closed then you are abusing your close vote privilege. Not only does this harm the site by getting rid of good content and wasting people's time, but you are projecting a wrong impression of the site's policies and being a bad example. I have some more to say on this issue too, but not the time right now.
    – Seth
    Oct 24, 2014 at 21:09
  • and the second example isn't covered by existing wording (note I say "wording" not policy, no policy should be changing here, just the wording because it doesn't reflect the policy). The question got 4 close votes and almost got closed. Wasting 7 peoples time, the 4 close voters and the 3 people who left it open. We don't want that.
    – Seth
    Oct 25, 2014 at 1:09
  • I also don't understand what you mean by "nless someone conclusively proves that: ... The question is independent of release". Did someone need to prove this was independent of release? How about my first example? What kind of proof is needed other than the question itself? If an answer doesn't need tailoring to the EoL release than it isn't release specific and thus shouldn't be closed! This isn't hard, so I'm not sure why you seem to be implying it is...
    – Seth
    Oct 25, 2014 at 1:12
  • @muru I recommend you to read my comment below the question.
    – Braiam
    Oct 25, 2014 at 1:21
  • @Seth The reviewer is expected to justify a review, yes. However, in the current wording, nothing more than the question is needed to prove it is offtopic - in that sense, the burden of proof is on the poster, since the poster must prove that the issue appears in a supported release, and reword the question accordingly. With your proposed wording, a reviewer will have to test on all supported releases, since even if one supported release is affected, it would on topic.
    – muru
    Oct 25, 2014 at 7:37
  • @Seth It is covered by the wording, but this example is a case where four people did not pay attention to the question. If they had taken a minute to read the question, they'd have seen it was not a problem.
    – muru
    Oct 25, 2014 at 7:38
  • @Seth Your first example was an error in a third party program, where someone needs demonstrate that it occurs in a supported release.
    – muru
    Oct 25, 2014 at 7:41
  • @Seth see the parallel: is any post of an unofficial derivative on-topic unless someone can prove that its not specific to that derivative?
    – muru
    Oct 25, 2014 at 7:42
  • @Seth "If you have not taken the time to convince yourself that this question does indeed deserve to be closed then you are abusing your close vote privilege." I see EOL release, I am convinced. Nothing more needed. If you or anybody else feels different, it's up to you or them to prove that it's not. I've retracted close votes before, and I'll again.
    – muru
    Oct 25, 2014 at 7:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .