When nobody replies
The most common outcome of asking a reporter for more information is nothing. No reply, no closure, no annoyance, just an issue that stops moving and stays in the backlog with a question mark hanging off it until somebody clears out anything untouched for ninety days.
The default reading is that the reporter did not care enough to answer. It is a comfortable explanation because it places the failure outside the team. It is also, most of the time, wrong.
What the silence usually is
Five things account for nearly all of it, and they call for completely different responses.
They answered somewhere else
They told somebody in a meeting, or in a direct message, or by walking over. The information exists and is not in the issue, which is the worst of both worlds: the thread looks abandoned and the work has quietly moved on without it.
They no longer have the problem
They found a workaround, or the deadline passed, or they left the team. The bug is still there. The urgency that produced the report is not, and urgency is what pays for the effort of replying.
They do not know the answer
You asked what version they were on and they do not know how to find out. Nobody replies "I don't know" to a technical question in public, because it feels like admitting to not belonging. They say nothing, which looks the same from the outside and feels much better from the inside.
They did not see it
Notification settings, a full inbox, a repository they were added to for one purpose. It is worth remembering that plenty of reporters do not use GitHub daily and are not watching the thread.
The question was too much work
This is the big one, and it is the only one entirely within your control. The reply asked for reproduction steps, or a log file, or answers to seven things. They meant to do it properly, later, and later has not arrived and now feels overdue, which makes it harder to start rather than easier.
The second attempt should not be the first one again
The standard follow-up is a nudge: "any update on this?" It performs sincerity and asks for exactly as much work as the message that already failed, so it fails for the same reason.
The move that works is to reduce what you are asking for, usually to nothing at all. State your assumption and let them correct it. Correcting is enormously cheaper than composing, and people who will not write a paragraph will absolutely tell you that you have got something wrong. The same idea drives the clarifying question that gets an answer the first time round.
Hi, just following up. Could you send those reproduction steps when you get a chance?
No problem if you have moved on. We are going to assume this only happens on the large exports, on the current release, and that it fails every time. If any of that is wrong, one word is enough and we will pick it back up.
That message also does something the nudge cannot: it works when nobody replies. If the assumption stands unchallenged, you can proceed on it, and you have written down the basis you proceeded on, which is what makes it recoverable later when it turns out to be wrong.
Closing a quiet issue
Issues that nobody can act on should be closed. An open issue that has been unactionable for four months is not a backlog item, it is a monument, and a backlog full of monuments is how teams end up unable to see the twelve things that actually matter.
Silence is not agreement, though, so the close should say so plainly and leave a real way back in. The difference between a close that is honest and one that is dismissive is about two sentences.
Closing this one because we were not able to get far enough to act on it, not because it is not real. If it happens again, the single most useful thing is the time it happened, and this issue can be reopened rather than filed fresh.
How we handle it, since it is the same problem
WhatProblem asks questions on issues, so it runs into this constantly, and it takes the least
dramatic option available. If a thread goes quiet for more than a week, the conversation is
treated as finished. Nothing happens at the week mark itself: there is no reminder, no chasing, and no label or
close on the issue. The check only runs when somebody next comments, and a comment that arrives
after the week is up gets one short reply saying the thread had gone quiet, rather than an
unprompted new round of questions. Commenting !whatproblem analyze starts it
again.
It used to be a day, and a day turned out to be wrong in an instructive way. It closed threads on people who were answering, just not quickly: somebody we had asked for a log file on a Friday would post it on the Monday, into silence. A window that short was measuring our patience, not their interest.
Not chasing is a deliberate trade, and not obviously the right one. A reminder would probably recover a few conversations. It would also mean an automated system pestering somebody about a bug report they have already given up on, in public, in their own repository. Between the recovered conversations and that, the conversations lose.
What the silence is actually telling you
One unanswered question is noise. A pattern of them is a measurement, and it is a measurement of your questions rather than of your reporters.
If most threads stop dead at the first reply, the reply is asking for too much, or asking for things whose purpose is invisible, or arriving days after the person had stopped thinking about it. All three are fixable, and none of them are fixed by concluding that people do not care.
WhatProblem asks these questions for you
It reads new GitHub issues and asks what is missing, in the issue thread, before anyone on your team has to.
Install from GitHub Marketplace