7

My question here: Strategies to troubleshoot an error that only happens on a specific device was closed due to being too broad. I don't quite understand why it's too broad, but that's fine, if it's a bad question, then it's a bad question. However...

I'm reasonably sure it's the type of problem that many programmers in the mobile device area will encounter, and I'm equally sure that others will have workaround strategies that may be useful, for me and others who read the question.

What can I do to get the question re-opened? Should I post it on a different SE site? Re-word it somehow? I'd be grateful for suggestions, this is currently a real-world problem for me and probably others too.

2 Answers 2

Reset to default
5

I am by no means an expert on Programmers.SE question expectations, but I think you might find more support if you share a specific example of the problem. Choose your most frustrating, model-specific error and describe it in detail (but not too much detail or it will be closed for being too localized). Share what you've done so far. Share what you know about the problem. Then, with a little luck, someone will help.

An exceptional answer to your specific problem might be generalized to all model-specific debugging, but Programmers.SE is pretty intolerant of generalized questions.

1
  • 2
    that sounds like a case study approach. Must be certainly safer than shooting broad questions, as it creates a natural qualifying barrier for answerers: only those capable to demonstrate their proficiency by addressing presented concrete case are allowed to proceed with further generalizations (in simple words, this would block / allow to flag zero effort crap answers like "I've heard that it may be a good idea to blah blah")
    – gnat
    Mar 26, 2014 at 15:18
5

I'm just going to reopen. I honestly don't understand this closure at all, and I'd like someone to convince me that it's actually too broad for Programmers (especially since there appear to be some answers already). Of course, if you had a specific problem or set of problems that you were experiencing, you may get more specific answers. However, planning strategies for testing in deployment environments doesn't have to be specific.

5
  • ... why thank you! :) I had been debating adding more specifics, but I thought that would change the question too much; I worried that people might inadvertently end up focusing on details of debugging a specific error, rather than the actual question.
    – StackExchange What The Heck
    Mar 26, 2014 at 17:22
  • 2
    I cast the first too broad vote and I stand by it. It's based on my experience of few years of troubleshooting errors on mobile devices and addressing "target market fragmentation" mentioned in the question. Question scope doesn't look reasonable: it attempts to cover UI, network / mobile operators, storage, resources, power and performance differences. Is it possible to configure an emulator to reproduce? How the application is distributed, how hard would it be for users to upload a newer version...
    – gnat
    Mar 26, 2014 at 18:11
  • 1
    ...What is the approach to logging and error reporting in the application? That's just what came into my head in few minutes, I sure have missed something, it's been several years that I'm out of this racket
    – gnat
    Mar 26, 2014 at 18:12
  • 2
    @gnat that's actually useful feedback. I am happy to add some of those details and will do imminently. Next time it might be handy to add thoughts like these directly to the problem question in a comment, though. Compared to a plain 'on hold' status, it makes the feedback more specific and less, err.... broad ;)
    – StackExchange What The Heck
    Mar 26, 2014 at 19:16
  • @yochannah I would strongly recommend "case study" approach like suggested by Corbin as a more reliable way to avoid closure
    – gnat
    Mar 26, 2014 at 19:19

You must log in to answer this question.

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