Timeline for Are Windows bug reports on topic here?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 7, 2016 at 17:30 | comment | added | fixer1234 | Just to clarify, when I said "the only thing I would disagree with...", I was referring to the thread in general. Your answer framed it right, so I posted the comment here as a supplementary thought, not as a critique of what you had written. But the edit makes it even better. :-) | |
| Aug 7, 2016 at 17:16 | comment | added | Ben N | @fixer1234 That makes sense. I've adjusted my answer slightly. | |
| Aug 7, 2016 at 17:16 | history | edited | Ben N | CC BY-SA 3.0 |
added 116 characters in body
|
| Aug 7, 2016 at 17:13 | comment | added | fixer1234 | Without this information, the OP will spend endless time trying unsuccessfully to diagnose the problem, and readers will volunteer useless answers containing ineffective things to try. But answering that it's a bug shouldn't be just speculation. It should cite documentation or at least include a way to replicate it so that the "bugness" is verifiable. | |
| Aug 7, 2016 at 17:13 | comment | added | fixer1234 | The only thing here I would disagree with would be that answering that it is a bug isn't helpful. It isn't helpful in alerting Microsoft or putting pressure on them, but it is helpful to people who come here with that problem who are looking for solutions. Yes, it should be framed as a proper question, with the bug documentation offered as an answer. If someone has a workaround, that would be a much better answer (and that isn't precluded). But in the absence of a workaround, documentation that it's a bug is useful. (cont'd) | |
| Aug 6, 2016 at 18:24 | history | answered | Ben N | CC BY-SA 3.0 |