Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Give actionable feedback when closing questions
Having had the dubious honor of experiencing the closing process from the perspective of a question author, it seems to me that closing does not adequately communicate why the question was closed, and which aspects need improving in order to make the question work here.
Specifically, for feedback to be actionable, it needs to
- specifically identify the problem
- explain why it is a problem
- and ideally explain a way to move forward
So, how did our process measure up? The close reason given was:
This post contains multiple questions or has many possible indistinguishable correct answers or requires extraordinary long answers.
That lists 3 different reasons for closure, leaving it unclear which one applies to the question.
Also, the second possible reason is not conveyed clearly, because "many possible indistinguishable answers" does not make grammatical sense: if the answers are indistinguishable, they are duplicates - why is that a fault of the question?
And it doesn't explain why that is a problem.
And it most definitely doesn't show a way forward.
Of course, people are smart. They can ask for further information if they care, and then wait a day for that further information to arrive.
I did, and received:
I closed this post because it's asking for personal anecdotes; there's an infinite number of possible answers to such a question, and as such doesn't fit so well into a Q&A format. It might be better suited to chat, or possibly a series of blog posts (which you might want to discuss in the Meta category). See also How to ask a great question in the Help Center.
That's much better:
- It clearly identifies the problem.
- It attempts to explain why it is a problem (but doesn't quite succeed, because it doesn't explain why "many answers" make a question "a bad fit for Q&A")
- It attempts to show a way forward (but doesn't quite succeed: why chat? how do I blog? Does he mean the currently disabled article feature?)
but it also shows how challenging it can be to communicate and explain site policy in a comment box. And how time consuming. And that's probably why Mythical gave that link to the help center. Alas, as the "how to ask" page does not appear to mention "many answers" at all, the link didn't help me much ...
So ... can we find a better way to give feedback when closing a question?
4 answers
This is a current limitation of the software.
Right now, there is simply no way to add detailed feedback to the close reason. There is a list of pre-written close reasons (which can be set per site). If you feel like there is an issue with the wording of a close reason, then feel free to suggest wording changes in a new post (ex. this one on Meta).
Changes are planned
See luap42's post on What are the close reasons on Codidact?. From that post:
If I recall correctly, the future close system will be based on three groups of problems with posts:
- Duplicates.
- Off-topic. This includes every post that isn't suitable for a site. If a community should ban easy questions, "too easy" would fall under this entry. Off-topic posts are inherently unfixable.
- Needs author's attention. These posts can be fixed but need attention from the author, because not everyone can do so (for example: missing information).
For the groups 2 and 3, the sites will be able to define sub-reasons (such as: "opinion based" under off-topic or "unclear" under needs author's attention). It might be possible to support the selection of multiple problems for these groups, or at least group 3.groups, or at least group 3.
Once those future changes are in place, close notices should be much clearer. With the ability to select multiple close reasons, we can make individual close reasons more specific.
So ... can we find a better way to give feedback when closing a question?
If you're asking about methods, then comments are probably the best way to give feedback, since it allows for discussion on why it was closed and how to improve the question.
If you're asking about what we, the givers of feedback, can do, then there isn't much that we aren't already doing, or trying to do. As you said, sometimes the feedback doesn't entirely succeed in explaining the close reason, but if that happens all we can do is have them ask for clarification.
Miscellaneous
This post contains multiple questions or has many possible indistinguishable correct answers or requires extraordinary long answers.
That lists 3 different reasons for closure, leaving it unclear which one applies to the question.
Also, the second possible reason is not conveyed clearly, because "many possible indistinguishable answers" does not make grammatical sense: if the answers are indistinguishable, they are duplicates - why is that a fault of the question?
This would probably do better as a separate question on Meta. The way I see it, just ignore the "indistinguishable" - i.e., "This post has many possible (different) correct answers." This overlaps with both "too broad" and "too subjective," if there is no way to distinguish which answer is correct, then the question is unanswerable.
I think the best solution is to have specific canned close reasons, with vetted messages clearly communicating what was bad, why that is bad, and specific tips for improving it.
Here are some attempts how this could look:
This post contains multiple unrelated questions.
[explanation why that is a problem]
Please split it into separate questions.
Or
There are many potential answers to this question, but we can't tell which ones apply in your case.
Please provide additional information as requested below.
Or
Doing justice to this question would require very long answers.
Unfortunately, few of our contributors have the time to write such long answers.
Could you make your question more specific?
The above suggestions are just first drafts, I am sure they could be improved further.
I am also not sure that closing is the ideal process here. Our aim should be to give feedback, and reduce the visibility of poorly received questions, but not every feedback necessarily justifies preventing answers.
A lot of close reasons are matters of judgment. Just how long is too long? Just how broad is too broad? People have different thresholds, and rounding that gradual scale into a boolean presumes a degree of objectivity that can not exist. (Case in point: my second-most popular answer on stackoverflow was on a question that received informal "too long" feedback)
Put differently, I think there can be value in communicating why I won't answer while still allowing other people to answer.
To expand on my comment somewhat...
In a question and answer format, personal questions like "What do you personally think?" don't tell to fare too well. There's not really any way to identify right or wrong answers. It's very hard to vote on the quality of answers, because it's asking for personal opinions (or in this anecdotes). You can have 1,000 different answers, and no real way to sort them by "quality" - because the question doesn't focus on a specific, actionable question; it's asking for everybody to chip in to a discussion.
To me, this doesn't seem like a good fit for the Q&A format.
In the Help Center, I was specifically thinking of this paragraph:
Avoid too much subjectivity
Questions like "What's your favorite way to eat an egg?" can't be answered objectively - the answer, naturally, changes depending on who you ask. On the other hand, "What's the difference between hard-boiled eggs and an omelette?" can be answered without relying too much on personal opinions. Try to ask questions that can be answered with some level of objectivity.
I suggested chat simply because that's currently the "laid back" area, where you don't have to worry about sticking to any sort of Q&A format.
When I suggested possibly a series of blog series, I was indeed referring to a category of articles that doesn't currently exist. (That's why I mentioned bringing it up here on Meta.)
I was thinking that a series of blog posts, by various authors, about "the worst code I've ever seen episode #6" would be a good way of sharing the (useful) knowledge that would have been contained in the question that was closed, just in a format more suited to it. (If there's interest in setting something like that up, a new Meta post about it is probably the way to go.)
I absolutely agree that the canned closed reasons need to be reworked. As @Moshi mentioned, it's in the pipeline for being revamped entirely.
And as a last point, it's entirely possible that I was in the wrong closing the question; I realized afterwards that I was largely operating on instincts brought over from Stack. Sorry about that! It's entirely possible that the Software Dev community here will decide that they want to keep that type of question around. If that's the case, the question can definitely be reopened, but that's probably a community-specific discussion that needs to happen.
We rather need to make a close reason for every kind of off-topic reason.
In this specific case, the reason could for example be Purely subjective question rather than the old "primarily opinion-based". Because we hope to allow some form of best practice & design questions here and not be as strict as SO.
We need to define the reason in detail. One example could be (I just made this up here and now):
This question was closed as purely subjective, because it is asking for subjective opinions, discussions or anecdotes.
- When asking for best practices, please make sure to specify what qualifies as "best". Fastest execution, most readable, most portable and so on.
- Questions asking to discuss a topic with no clear goal or outcome, or asking for anecdotes or personal past experiences are not suitable for the Q&A format used by this site. Instead focus on a specific problem you are facing, what behavior you expect and what behavior you encountered.
1 comment thread