What to do with abandoned issues in GitHub?

Question

If someone opens an issue on GitHub but more information to reproduce the error is asked and never given, what's the normal procedure? Example.

Here the author states that the "nav breaks". While I believe it is fixed, I would like word from the author to make sure we were talking about the same thing. But sometimes the issue's reporter just disappears. Is it a good/common practice to set a expiration date for abandoned issues?

Something like these conditions:

• A question is raised on the issue to be able to debug it.
• Over 2-6 months have passed since the last unanswered question/comment from the dev team.
• Bug cannot be reproduced at the time of closing it (for any reason, maybe they could never be reproduced).
• A warning is issued 2 weeks before closing it.

What do projects normally do? I couldn't find anything on Google. Also, how would I document this? Does a simple note in the README.md detailing the points above and a comment in the issue explaining why it's being closed suffice?

Note: it's different from this question since the bug might still be relevant (or not), however there's lack of information.

Answer 1

This is a dilemma: you cannot close the issue as "fixed", because you don't actually know if it was fixed, or at least even if some issue was fixed, you don't actually know whether this was the issue the reporter was talking about. On the other hand, you don't want to leave an issue that might have been fixed open, especially if you won't ever be able to close it because you'll never get confirmation.

So, you should close it, but probably not as "fixed". You could invent a custom close reason "maybefixed" or "unconfirmedfix" if you want to be positive or "reportervanished" if you don't. You could also just say "could not reproduce", and wait for the same bug to pop up for a more responsive reporter.

However, you should not expend resources on a bug for which you will never know whether it was actually fixed or not.

Answer 2

Your main question was already answered, but you also asked about documenting the process and that needs answering too.

The solution I've seen in many projects is not to put it in the project's README.md, but in a special contribution README - a README file for contributors. This file describes everything you want the people contributing to your project to know - be it about the code(naming conventions, module organization etc.) or about the process(how to write commits, how to handle tickets etc.). This file can be another .MD file in the project, or placed in an entirely different repository(so it can be shared among all your projects). Just don't forget to link to it from the main README.md!

The point of separating that information from the main README is that usually only a fraction of the project's user directly contribute to it. Most of the users don't need to be bored with that information - they just need to know what your project does and how to use it, and that's what the main README should contain. In your project's case the contribution section is very small so it doesn't encumber the main README - but if you document all the workflows you want contributers to follow it won't fit there as nicely anymore...

Note that any user can open a bug, so if you have special requirements about bug opening you should put them in the main README(try to keep it shourt though - unlike code contributers, bug reporters will probably be less willing to go to great lengths to study and conform to your rules). However, the person that actually fixes the bug and closes the ticket(be it you or one of the contributers you have confirmed) is a direct contributer and can be expected to read the contribution README - so the process of closing tickets when the reporter does not respond should be described there.

Answer 3

I read this as more a question about the practices around how to handle an unverified bug (using github's issue tracker) than anything else.

To me, that is a rather straight forward answer based on other issue trackers I have used. Github doesn't force anyone to use any workflow and this makes it very flexible... and rather useless in its default configuration.

Looking at Bugzilla's default workflow we get:

I'm going to point out a very important thing there - it gets resolved as fixed before it gets closed after being verified. The basic Github workflow shows only the red (open) and green (closed) states.

Thus, one approach is use the labels within Github (your application's labels) to try to show the additional information. You can create a pair of labels that are 'unverified' and 'verified' to be applied once you close the issue. Note that this is only one approach - if you search you can find dozens of different approaches to the use of labels. Here, the question How to manage github issues for (priority, etc)? addresses this.

You have fixed it, from a developer's standpoint it is done. Close the issue on Github. Apply the 'unverified' label to it. Once someone familiar with the bug in the previous version says "yes, this fixed it" you can change the label to 'verified'. If they say it didn't, then you reopen it.

Note also that there are other resolved states besides 'fixed'. There is 'wontfix' (the fix is something that just can't be done with the current structure) and 'worksforme' (the bug can't be reproduced) and 'invalid' (you are filing a bug about the OS, not the application type things).

Answer 4

I would take one of two views, depending how confident I was that I was talking about the same thing as the original reporter:

1) Since the reporter is no longer available, deem that the bug in question means whatever it was you fixed. If it helps, attach test cases to make clear what failures you found. Describe in detail on the bug report what it was you fixed and leave a note like, "I believe this is what 'nav breaks' means, please reopen or raise a new bug if that's not what you meant". Mark the bug as fixed.

2) Since the reporter is no longer available, deem that the bug cannot be (known to be) reproduced, since only the reporter's word for it would confirm it's the same thing they reported. Raise a new bug to describe the thing you fixed, for the sake of credit mention that it was observed under the conditions described by the absent reporter, note on both that they may be duplicates, mark the new bug fixed and mark this one invalid or not reproducible with a note like, "I can't work out what you meant by 'nav breaks', but I've solved the problem that I did find. Please reopen or raise a new bug if the nav still breaks, describing in more detail what goes wrong".

As for timescale, I think it should depend on the project. If you are very responsive, and are dealing with this bug within days of it being raised, then people should understand that you won't wait weeks for a response before resolving the issue. On the other hand, if it's been on your slushpile for months then it can sit open for another month or two without causing you any trouble.

For this reason I don't think there's one particular time limit that constitutes "good practice", or that you need to publish your policy and stick to it. Certainly you wouldn't want to record that the reporter can't be contacted until you've made an effort to contact them. But I also don't see any point leaving multiple warnings counting down to a deadline: either they'll revisit the bug and want to say something, or they won't.