Reopening closed issues

[CyrilleB79]

Hello all

I have had a recent discussion with @britechguy , first publicly in comments of #13021 and #14541 and then through private e-mail exchanges. The discussion is about reopening closed issues.

There are issues that have been closed, for various reasons. But sometimes, the problem encountered by users and that had triggered them to report the issue comes back again and again though. This probably means that the people looking at issues (developers, triagers) have not well understood the root problem or have not been able to explain to the users/reporter why the problem culd not be solved by a modification in NVDA's code or documentation.

I have encouraged @britechguy to open a new issue with only a summary of the information that is still useful, up-to-date and relevant with a link to the old closed issue. From my experience, it seemed to me the most efficient to progress. But from a user/reporter point of view, @@britechguy disagree with this way to do; @britechguy, I let you explain your point of view yourself, you will do it better than I.

I realize that all the contributing documentation of NVDA does not seem to provide instructions when an issue is closed but is not resolved from a user's point of view. Or do I miss something?
We must remain attentive to making users feel heard.

NV Access' opinion (@seanbudd, @michaelDCurran) would be appreciated, as well as active contributors' ones (@LeonarddeR, @josephsl, @XLTechie, @lukaszgo1, @Adriani90).
Also active reporters opinion is needed (@britechguy, @cary-rowen).

I have no other name in mind but feel free to mention other people.

After this discussion has taken place, I hope that the contributing documentation will be updated accordingly.

Thanks.
Cheers,

Cyrille

[britechguy]

I am simply going to include pertinent segments of what I said to Cyrille privately:

My days of opening new issues, that are essentially direct extensions of existing, closed issues, are over. It's too damned much work and it's too inefficient for those on "the commenting" or "the opening" end. When the same thing comes up, again and again, and there exist issues for them, my opinion is that those should be reviewed for reopening if/when someone chooses to comment on them. They do that because what they've read is relevant to what they're about to say. It's also not, in my opinion, at all efficient to have issues that make reference to other issues when that can be avoided.

If someone's trying "to raise an issue from the dead" it's because they still have it.

If the semi-official policy is to brush aside those who attempt to revive a closed topic, I stand by my assessment that this is a mistake. I have been trying, for years now, to get the users of NVDA who post to the NVDA Group to get on to GitHub and communicate with NVDA developers. I routinely tell them to search for existing issues, and comment on same if they exist as opposed to opening new ones.

Activity on an issue, regardless of its status as open or closed, indicates it needs attention. It's no different than entering a new issue in that it's an attempt to get attention to some need. If those who are in the position to triage issues (and I don't just mean you) don't look at what the comment states, and how it ties in to what's already part of a closed issue, as part of considering whether it should be reopened or not, I really don't know what to say.

I'm capable, very capable, of creating new issues, yet even I don't like doing that when I'm just rattling the same proverbial cage that someone else has rattled in the past. If I comment on a closed issue, it's because what's in that issue was never resolved and it's directly linked to what I feel needs attention because I'm having the same issue.

When it comes right down to it, it's inefficient for all involved to have new issues alluding to one or more old issues when those happen to be about what appears to be exactly the same thing. It's the equivalent of topic-splitting in forums, where the same topic is being discussed, often in parallel, because someone decided to create another one without having checked whether there is a current one out there. The difference being that when it comes to forums, reviving many things from the dead does make no sense. But in a project management system, when a search on the issue you intend to report indicates it's been reported before, it makes far more sense to raise the flag on those prior reports, whether the issue was closed or not.

I see little difference in issues that have been allowed to remain open, sometimes for years (and I was just commenting recently along with a number of others, and it was opened in 2016), versus one that was closed, often with no clear rationale as part of the closure.

And note well, I'm not talking issues closed because they are fixed, or where they are closed because they are duplicates of another issue and where the closure message makes direct reference to where any further follow-up is required.

The time of reporters is limited, too, and "reinventing the wheel" rather than saying, "Me, too, now - and here are my details," on an existing issue is often going to discourage actual communication from the user community. One of NVDA's great strengths is that a mechanism exists for end users to have direct communication with the development team. Making that as easy as possible needs to be a significant consideration.

[lukaszgo1]

I'd say there is no single good answer here, an a lot depends on why the given issue was closed. Most of the time this is because:

• someone triaging misunderstood the problem (just an user error, or, way too often IMHO, lack of technical competence on part of the person doing triage). In that case the issue should be simply reopened no question asked.
• The problem was not fully solved - in that case new issue should be created listing exactly what remains to be done. This is by no means making it harder for reporters. Time of developers able to contribute a fix is limited too, and if we can avoid reading (often quite long) trail of comments we are way more likely to contribute a fix.
• The last category (both issues linked above fall there) is simply the case in which someone disagrees with the reason for closing. I don't think we can come up with any hard rules there, and these should be considered on a case by case basis.

For the issues where core developers do not intent to accept a change of behavior we can consider simply locking the conversation, though that can be considered too strict by some.

[britechguy]

@lukaszgo1

I agree entirely that there is no single good answer here.

For issues where core developers do not intend to accept a change in behavior, the closure note should include that. Most of us who've "been around the block" can accept a, "No, we're not doing that," or a, "No, we're not doing that with detailed rationale included." What is very hard to swallow is a No with either a weak rationale that does not address the issue, as written, or just a closure without any comment.

I know better than many how little spare time developers have, and I respect that, but when an issue is closed some reason, even if it's a straight, "We do not intend to implement this now, or in the future," should be supplied.

As to the "trail of comments," I personally, when I'm the developer, prefer to have them there for referencing if I need or want to. I'm perfectly capable of zooming straight to what's just been added, first, then deciding if I need or want any of the back story. But when I do, I find it much easier to have it there, at the ready, than having to go through multiple levels of redirection to other issues, and the like. That's part of why I said that if a user lands upon a previously closed issue, and it really is a direct reflection of what they believe their current issue to be, that a comment on that should trigger a review, and a sincere one. It feels like reinventing the wheel to report, in its entirety, something that's already been reported and where you need only add something as simple as a "me, too, now" and/or how what's going on for you may differ, slightly, from what's come before. A variation on the central theme, as it were.

[Brian1Gaff]

The only thing I'd say is that sometimes we do not understand the ramifications of what we ask for. I do agree that a simple non technical non patronising explanation can go a long way to preserve trust that the decision was not made lightly, ignoring an issue. Brian

…

-- ***@***.*** Sent via blueyonder.(Virgin media) Please address personal E-mail to:- ***@***.***, putting 'Brian Gaff' in the display name field.

[britechguy]

a simple non technical non patronising explanation can go a long way to preserve trust that the decision was not made lightly, ignoring an issue.

And that is the crux of the matter. If someone has taken the time to create an issue, those closing them should at least try to give some rationale for the closing if it's not being closed because the requested fix has been made.

End users (and I'll include myself, too) often make requests that are not feasible to implement for one or more reasons. Having a one or two liner saying something along these lines, and being specific but not overwhelmingly technical when possible, goes a long way toward preserving trust and not turning people off to reporting what they believe to be other issues in the future. I have been saying, for years, that NVDA's end users are blessed because it is one of the few instances where an established direct communication line exists for end users to developers.

Giving a rationale also goes a long way toward preventing someone from resurrecting certain issues from the dead if the explanation for why the request is not feasible makes sense to them. It'll sometimes stop them right in their tracks and prevent the creation of another issue or feature request that would have the same fate. This cuts down on work for all who are fielding these requests.

[CyrilleB79]

I agree that if issues are closed without a fix going to NVDA, a justification should be provided. And as Brian says, the justifications should be understandable at least by the person who has opened the issue. I think that it's done for most of the issues, and specifically for #13021 and #14541 that I have cited as example.

However there are issues (maybe 1 out of 4) for which such justification is not provided. In this case, users/reporters are more than legitimate to ask for a clarification in the closed issue; and as an issue reporter, I have already done so and received an answer. But many users/reporters will probably not dare asking for this clarification. That's why the triager is primarily responsible for providing this clarification when closing.

Also some reactions to what was written before, especially by Brian:

I routinely tell them to search for existing issues, and comment on same if they exist as opposed to opening new ones.

That's a good point if open issues are found. That means that no duplicate will be opened and that the discussion will take place at the same location. Regarding closed issue, there is of course no good and unique solution. Especially when the reporter disagree with the reason why it was closed, we should take care that the issue does not become a forum thread.

Activity on an issue, regardless of its status as open or closed, indicates it needs attention.

If users try to interact with developers/triagers, it should of course require attention. But users reporting issues should be aware that an open issue means some work to do for developers; and a closed issue means no more work to do on this task. These issues are first a way to organize the work. On the opposite, forum threads are primarily discussions and thus, remain open forever.
To illustrate with a similar situation: in my company, the IT manages the issues reported by users through an issue tracking system. Once the issue is considered resolved by the IT, the issue ticket is close. And as an user, I have one week to accept or decline the solution, i.e. I have one week to re-open the issue.
Of course, for NVDA we probably do not need to be so strict but this illustrates that re-opening discussions after many months on a closed issue is not desirable for developers.

So maybe instructions/checks should be provided to users who would like to re-open closed issues:

• Have you understood why the issue was closed? (if not, ask for clarification)
• Do you disagree with the reason why it was closed? (If yes, please provide clear and strong arguments explaining why the reason is not relevant)
• etc.