What are the guidelines for "How would you... ?" questions here?

Question

I did read the Six Subjective Questions post and its Enforcement Notice, as well as some of the following discussions.

My question is about questions that asks users to share their experience and/or offer creative suggestions in solving/approaching a particular problem. Obviously everybody's experience differs, so answers could be deemed subjective.

We, obviously, do not want to reinvent the wheel over and over again. So, how to ask such questions, that by definition cannot have the right answer?

Everybody's experience differs, so different folks would suggest different remedies. I am not starting a discussion about what is better, merely looking for an advice.

For example, it could be a question about heuristic rules employed in the application monitoring process with enough specifics to narrow it down.

Answer 1

You can ask questions that lend themselves to answers based on subjective experiences: subjectivity does not necessarily mean opinion-based or discussion-based.

Most types of questions on Programmers may not have an objectively correct answer that works for all situations, but they are still okay here because:

• Some answers are better than others, and that means voting can still work as it was intended. Even though they are based on subjective experiences, people can evaluate two answers and determine one is better than the other for the situation presented in the question.
• To the first point, good answers have something backing them up. A convincing story, some data, an argument, etc. Bad answers just state an opinion or what you should do with no reasons for believing it to be the right course of action.
• The question asker can evaluate all of the answers and decide that one answer best solves the problem they have presented in their question, allowing them to mark one answer as "accepted".

In your case, you're looking for advice and not necessarily the "one true way", but you can still tell good advice from bad and evaluate answers based on that.

One major problem we have here on this site is that certain people focus too much on how the question was asked instead of what the question is asking. To avoid your question getting closed by those people, try to avoid asking your question in a "soft" or "welcoming" way and instead ask it in an authoritative way:

• Bad: "What are your experiences with X problem?"
• Bad: "How would you approach X problem?"
• Okay: "How can I solve X problem?"
• Better: "What's the correct approach to solving X problem?"

You'll get exactly the same types of answers: answers based on the subjective experience and expertise of the answerers, and you've essentially asked the same thing, but you won't attract the ire of the people who reach for the close button before they reach for the edit button.

Answer 2

We, obviously, do not want to reinvent the wheel over and over again. So, how to ask such questions, that by definition cannot have the right answer?

What you are talking about is not a "question," it is a "discussion point."

If a question has no right answer there are three possibilities:

1. It is impossible to know (e.g. what is on the other side of an event horizon?)
2. It is possible to know, but we do not have an answer yet (e.g. P == NP?)
3. It is soliciting opinions.

The first two can work as questions. History is littered with research papers that explore topics with the result "nope, that doesn't work -- yet." But you asked about "by definition" not having a right answer, which fits squarely into condition three, which would be "primarily opinion-based," a close reason everywhere on Stack Exchange.

My question is about questions that asks users to share their experience and/or offer creative suggestions in solving/approaching a particular problem.

Sharing experiences works in a forum (this is not a forum) or in chat. Not in the Q&A format.

However, the "particular problem" part is probably on-topic if asked right. Questions should be about programming problems and soliciting creative solutions to solve them.

Presenting a design and asking for feedback is fine, as long as it is properly-scoped and not too broad. That is not really what you were getting at, but it is a better focus for those types of questions.