5

I saw that Windows 8.1 Preview No sound on Macbook Pro Retina was closed since it's Preview/Beta code and the issue may very well be fixed by MS or the PC manufacturer in the months to come before Win8.1 RTM. Here's another one in the same vein posted recently: Sony Vaio CPU fan runs at full speed after installing Windows 8.1 preview.

Do we treat all such queries about pre-release software and prototype hardware similarly, and close them if the problems cannot be addressed by end users (the questions can be reopened later if required of course)? And if so, what close reason should we use?

4
  • 2
    No, they should not. Just because it's a beta "bug", doesn't mean it's going to get fixed any time soon. I have been waiting for YEARS for certain bugs to be fixed and they still haven't been. More often than not, the community is able to at least help find a workaround. But without it, we're pretty much -.
    – jay_t55
    Jul 11, 2013 at 20:46
  • As part of a test run this close reason is live on the site. Let's see how the community uses it.
    – Karan
    Jul 11, 2013 at 20:58
  • the only reason I am against this idea is because I have seen it being abused in the past by people, and I've been noticing it a lot more lately but we'll see how it goes I guess.
    – jay_t55
    Jul 11, 2013 at 22:02
  • You can list below specific instances of abuse or flag for a mod to take a look. I haven't come across any such cases yet since this went live.
    – Karan
    Jul 11, 2013 at 22:16

2 Answers 2

6

If the community sees fit to do so, we can create a custom close reason for questions about bugs for pre-release software.

I don't personally think it makes sense to close all questions that are at all related to pre-release software, but I do think that questions specifically about bugs/errors/hardware incompatibilities with pre-release software don't do us much good long-term.

Suggested wording - feel free to suggest changes in the comments:

Questions about bugs in pre-release/beta software or prototype hardware are off-topic. Bugs in pre-release products are common and even expected, and are often fixed before the final version is released — at which point the question becomes obsolete. Consider reporting these types of problems directly to the product manufacturer.

19
  • Not all certainly, since there are problems that can be solved. But when enough people agree that it's not something that can immediately be fixed without the software/hardware makers' help, I think a custom close reason would help for such cases.
    – Karan
    Jul 1, 2013 at 1:47
  • @Karan how do you feel about the suggested wording here? Do you think it would be better to emphasize the "cannot be fixed without the manufacturer's help" bit, or do you think that's sufficiently implied here?
    – nhinkle
    Jul 1, 2013 at 1:49
  • Are pre-RTM releases "unreleased products"? I would modify that a bit, but on the whole it looks ok. How about: "Questions about bugs in pre-release/beta software or prototype hardware are off-topic. Bugs in such products are common and even expected, and are often fixed before the final version is released — at which point the question becomes obsolete. Consider reporting these types of problems directly to the product manufacturer."
    – Karan
    Jul 1, 2013 at 1:50
  • @Karan I'd consider "beta", "alpha", "preview", "release candidate", etc. to all be pre-release -- they're not the final version of the product.
    – nhinkle
    Jul 1, 2013 at 2:49
  • What I was trying to say is that "pre-release" implies "pre (prior to) release to manufacturing", whereas "unreleased" to me means "never been released". That's why I felt that "unreleased" perhaps shouldn't be used.
    – Karan
    Jul 1, 2013 at 2:54
  • @Karan ah, I see what you mean. Yes, that is a good distinction - I'll update the draft to reflect that.
    – nhinkle
    Jul 1, 2013 at 2:56
  • Hope you don't mind, I just made a small edit and removed "on". Since the word "bugs" applies to both, "bugs in pre-release/beta software" sounds fine but "bugs on prototype hardware" doesn't. So... now do we wait for others to chime in or are you gonna just go ahead and implement this? (Or does it have to be done by the devs?)
    – Karan
    Jul 1, 2013 at 3:07
  • @Karan moderators can freely edit the off-topic close reasons (although there's a big warning about DON'T MESS THIS UP), but I'd like to wait for some more input - at the very least from the other moderators, and from a handful of users. If this gets enough upvotes in the next couple days and no strong complains against it, then we can go for it.
    – nhinkle
    Jul 1, 2013 at 3:09
  • Great, look forward to it! I'm sure you'll let the others mods know via chat.
    – Karan
    Jul 1, 2013 at 3:10
  • 8
    I'm a little concerned about the wording. A lot of open-source projects (and some closed-source) are in a perpetual state of pre-release, with no concrete plans to move to release. It is not inconceivable that bugs may have third-party solutions, or what one sees as a bug another sees as a feature. And bugs are not exclusive to pre-release software, especially not release candidates. (Another point is we should be careful about having a listed close reason - leaving it for custom reasons may be a better idea to reduce bandwagoning, especially where a question may be answerable.)
    – Bob
    Jul 1, 2013 at 8:01
  • 3
    @Bob Even versions below 1.0 they provide as separate download can be considered releases. But if you're running the nightlies, or build it yourself from version control (e.g. SVN trunk), it's your own fault. We've had quite a few browser issues on MSU/MSO where it turned out the users were running Chrome Canary.
    – Daniel Beck Mod
    Jul 1, 2013 at 8:12
  • 2
    @Bob - I think we are more concerned about the situation where somebody is using a release unstable build when there is a stable build they could be using instead. In the case of Windows 8.1 Preview, driver support is still being worked on, there are specific situation where its not even supported. If a question leads us to one of those situations its best to simply tell the user to report the issues since if it was to work around, then it would already been suggested by Microsoft.
    – Ramhound
    Jul 1, 2013 at 11:50
  • 1
    I agree with @Bob that there's potential for people to see the close reason and use it wherever it could apply, not just wherever it may selectively be needed. We can always turn it on, see how it works, and turn if back off if it turns out that it's being abused.
    – nhinkle
    Jul 1, 2013 at 16:42
  • 1
    I think that – with the low number of possible off-topic close reasons – we'd do best just closing those questions as we see them, potentially linking to this very Meta post. After all we don't get many of these types of questions (at least for major pre-release software products).
    – slhck
    Jul 4, 2013 at 18:42
  • 1
    @kev we can't expect to answer questions on every beta version of an operating system furthermore the number of time that has happen is how many? Asking how many times a beta had a feature that RTM removed
    – Ramhound
    Jul 5, 2013 at 1:27
2

I'd argue that this isn't what we have done so far - we've used preview tags in the past, with the view of using these tags as a deletion target. We can always retag questions still relevant with newer versions.

This close reason might be more useful after the beta period ends.

You must log in to answer this question.

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