Skip to main content
Commonmark migration
Source Link

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

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.

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.

replaced http://askubuntu.com/ with https://askubuntu.com/
Source Link

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

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.

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.

added 473 characters in body
Source Link
muru
  • 204k
  • 2
  • 41
  • 67

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.

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

And your second example is non-problem. 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.)

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.

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.

Source Link
muru
  • 204k
  • 2
  • 41
  • 67
Loading