Original reporter should be able to reopen a closed issue

[jmarshall]

Oftentimes we commit some fix in response to an issue, run our own tests, and close the issue with a comment along the lines of “We believe this has fixed the problem; please reopen if it still fails on your data”.

However it turns out that only organisation-members/contributors/people-with-write-access-to-repo/something-similar have the ability to reopen issues. It would be useful if the user who originally opened the issue also had the ability to reopen their own issue, as they are also intimately concerned with whatever problem the issue is about. If our fix has not been effective for their test case, they should be able to reopen the issue to signal this.

Maintainers / repo owners would probably need to have some control over this; e.g., using “Lock conversation” could also prevent third parties such as the original reporter from reopening the issue.

See for example the conversation in samtools/htslib#305 and samtools/htslib#306. These are both the same underlying problem, but the reporter's inability to reopen his issue has led to duplicate issues and more noise.

[jmarshall]

[Pretty run of the mill response from [email protected], quoted in full with my replies interposed:]

Thanks for sharing your idea with us, John -- I agree that might be useful in some situations. I'll pass your feedback to the team working on issues, but can't make any promises. Also, I'm not convinced this would really solve the duplicate issues problem. Sometimes the user who reported the issue isn't the one who wants to reopen it, but a different user, so those users would still open duplicates.

I think most often it is the original reporter who is particularly motivated to get their own problem fully resolved.

However you are right that sometimes others may want to reopen an existing issue. Considering that everyone has access to the New Issue button, perhaps there is a case to be made that anyone should be able to reopen an existing (unlocked) issue -- if the alternative is that they will just use New Issue to create a duplicate.

Or perhaps "add a comment and OP/we'll reopen it" suffices for such people.

For now, instead of asking users to "reopen the issue" if they can still reproduce the problem the reported, you could ask them "let us know in a comment if you can still reproduce the issue, and we'll reopen it". Would you be able to use such a workflow?

That would be a workaround, but it is more complicated and disempowers the users reporting issues. So allowing the original reporter to actually reopen the issue would be a better experience for them, i.e., for people whom projects are presumably trying to encourage.

[hkdobrev]

I don't remember a time when this wasn't working. When I saw this issue I thought GitHub may have removed that recently. However here's a recent example of original creator re-opening the issue after has closed it: composer/composer#4967 (comment) The issue creator is not a contributor to the repository.

I suspect that GitHub may have built it like so:

• If original issue creator closes the issue, they can then reopen it
• If a contributor closes the issue, the original issue creator is not able to reopen it

This workflow makes a lot of sense to me so maintainers can control the open state of their issues and when they mark something as a wontfix for example to be able to easily enforce it stay closed.

However if you think you want original issue creator to always be able to reopen an issue, please adjust the title and description of this issue.

[sbordet]

+1

Given that issues can be closed automagically with commit messages, the ability for the reporter to reopen the issue if the commit does not completely fix the issue is IMHO important.

Thanks !

[timotheecour]

+1
my number 1 issue with github issues.
Maintainer of a project closes an issue forcing me to reopen a duplicate issue, resulting in much noise and lost time.

[pcgeek86]

Yup I agree with @timotheecour -- it causes unnecessary noise. Project maintainers are inclined to close out issues quickly, which makes it really annoying that I, as the issue reporter, cannot reopen it.

[lukehutch]

+1, I don't see the utility of denying a bug creator the ability to re-open their own bug by default.

The real question is how often this default behavior solves problems (e.g. preventing belligerent bug creators from re-opening their pet issue when a bug is marked as WAI) vs. how often it creates new problems (when a bug is closed too early, especially when bugs are closed automatically by a commit message). I would think the current behavior creates more problems than it solves.

[buhtz]

What is the status of thatIssue? Does someone work on implementing it?

[tekbasse]

Maybe change status from "closed" to "closed/disputed" or "open/ignored" ie something that shows the stat as closed to the developer, and yet differentiates closed/solved tickets from closed/disputed ones. This would be handy in helping to quickly assess the nature of developer support in some cases.

[mlewand]

Maybe change status from "closed" to "closed/disputed" or "open/ignored" (...)

I think that adding new status names like that would bring unnecessary noise. I believe all we need here is a checkbox below "close" issue (or PR) button saying "allow reporter to reopen this issue" enabled by default.

That would be somewhat similar to "Allow edits from maintainers." checkbox when making the pull request.

[tekbasse]

@mlewand Yes, a single state Open/Closed is ideal in an ideal world. However, stackexchange and many open source bug trackers (as well as github) allow a ticket to be permanently closed to prevent "noise" from end-users etc re-opening a ticket that they conclude has been fixed. In these cases, an end user has the option to create a new ticket/issue.

Allowing a ticket to remain closed and disputed/challenged, provides some indication to others that the issue is not resolved. This can be done in such a way that the developer may continue to ignore the issue thread, while others may participate and/or collaborate on a solution (until re-closed by OP). This also is helpful in providing analytics for assessing how well the developer handles issues overall.

[mlewand]

@tekbasse Sure, I understand what's your idea. My point was just to propose a simpler solution, similar to existing feature.

[jonas-eschle]

Given that a discussion can be locked anyway, I do not see a single use case for the current behavior. Can maybe anyone provide a single usecase why the original author (let's focus on the very simple case) cannot re-open an issue? (but create new issues, so if he wants to make troubles, he still can)

[VNJoe]

Can we report the person that closed the case for Abuse?

[bcutter]

Given that a discussion can be locked anyway, I do not see a single use case for the current behavior. Can maybe anyone provide a single usecase why the original author (let's focus on the very simple case) cannot re-open an issue? (but create new issues, so if he wants to make troubles, he still can)

Double that. Creates duplicates.

[jonas-eschle]

Hi there, it's been quite some time and this issue seem from a technical point trivial to fix, from a logical point absolutely clear as well. What exactly is preventing this to proceed?

[Shredder5262]

Perhaps not so much be able to re-open the issue as much as a mutual agreement that the issue can be closed along with some rational on why it is being closed . I would like it if i (as a reporter) have a say on if the issue can be closed or not. Occasionally i will raise an issue with a project and it is simply dismissed without further question, or closed without resolution. Therefore, I as an end user am left with something that was broken, and i raised an issue for, is still broken. If I follow the process of raising an issue, it should lead to a resolution...not whatever the Dev decides is an issue and non-issue.