Suggested special feature: Clinic/case study

We have special features/sections on Codidact, so maybe this is a nice use for them.

What if we had a section named something like "clinic" or "case study" or "debugging"? (name suggestions welcome)

The point of this section would be specific debugging or troubleshooting help questions. The format would still be QA, but the culture would be different. This section will be specifically for questions like "why is this code breaking" or "how do I fix this method returning wrong value".

A lot of people complain about such questions, because they are too localized/specific. In other words, they help just OP and maybe two other people in the world who have that exact problem, and nobody else cares. I personally disagree, because a normal intelligent person can look at the solution of a problem that's not exactly the same as theirs, and still glean enough useful insight to solve their own. I do see the other concern about them not being searchable, and I haven't made up my mind on whether I buy it. But such questions are controversial, so maybe it would help to give them a separate place.

On this new debugging section:

• Any type of debugging question is welcome, no matter how localized or specific
• Askers are encouraged to provide all necessary data, ideally MWEs, and no more (redundant data should be deleted)
• Askers are gently guided with edit requests and comments, not downvotes without an explanation of what's wrong
  • It's very annoying, when you are trying to solve a tough problem, got frustrated, gave up, and are asking for help, then someone downvotes you with no explanation, or yells at you for not doing a bunch more frustrating reading when you're already sick of going in circles through incomprehensible manuals. It feels like "screw you, you're not worth helping, no real reason just cause".
• "Teaching to fish" is strongly encouraged in answers. So explaining how to solve the problem, rather than just giving the solution. Giving the solution is okay, especially if it helps illustrate the solution method (it's also annoying to solve riddles when you're frustrated and just want some help), but the focus must be on the how not what.
  • Linking to relevant general questions of the Q&A section, or even creating them there, is encouraged. This is a good soft way of recruiting hapless newbie "help vampires" into becoming good users of the main section. They come for the debugging, calm down and feel gratitude when their problem is solved, and stay for the community and quality SWdev discussion.
  • I would go as far as saying you should not upvote answers (but don't downvote unless they're blatantly incorrect) that only give the solution, without explaining how they arrived at it. I consider these "closed-source" answers.
• Paraphrasing relevant data is allowed.
  • Adding this based on personal experience with Arch forums, which ban paraphrasing and demand excessive logs. This creates a lot of privacy concerns, logs often contain private data that is a lot of work to scrub, they take space, and there's no point demanding them in full if an accurate summary can be provided. Arch forums assume their users are idiots and cannot provide an accurate summary, but we shouldn't.

In principle, the code review section can be used for this. Usually I think of it as "this code works and is as good as I can make it, but is there any improvement areas that I have missed?". But if you paste broken code, obviously a review must explain how to fix it. However, I think it would muddle things too much to reuse code review for debugging, especially if you consider my suggested policy above. Also, currently the code review section requires working code only. As I understand, creating sections is not hard, so why not just make a separate one and be safe?

posted 7 months ago

CC BY-SA 4.0

7mo ago

matthewsnyder‭

1719 reputation 43 48 197 80