I don’t think so. It should have an easy way of reopening - if it has, and you’re flooded with tickets on an open source project that you can’t possibly handle all, then it’s a good way to prioritize. Of course it doesn’t have an easy way to reopen here, which sucks, it’s some kind of locking instead of just closing it with a possibility to reopen.
Old tickets have a non-zero chance of the reporter being the only one to run into it because of a weird setup/usecase (and then abandoning the project), it being fixed by other work, or probably a bunch of other reasons it could be obsolete.
If no one cares enough to reopen it once every 6 months, then it’s probably fine to ignore it indefinitely.
I think it would be better to send a message after 1 month of inactivity, have the bot ask if the issue can still be reproduced with the latest version and then repeat every N months.
If no one cares enough to reopen it once every 6 months, then it’s probably fine to ignore it indefinitely.
It’s a matter of psychology. If I file a bug and it is ignored for years, I’m annoyed but eventually I either accept it, find a workaround or move on to something new. I may still file bugs in the future, especially if I’ve got a workaround, since other people probably want to know.
However if my bug is closed and I have to reopen it every six months. Now I’m kinda pissed. I have to be reminded every six months for years that this is just broken. I put in the effort, but now some bot has just come along and closed it. Plus it’s going to be harder to find an existing or similar bug. I’m less likely to look at closed bugs. But also, what if I find four similar closer bugs. Now if someone was tracking that bug they don’t realize this has happened to four different users. If we had just kept it in one big we’d all know. Also someone elses workaround is better than mine, or maybe it’s worse.
I understand if a project wants to declare bug bankruptcy. It shouldn’t happen often but if you do that’s the time to organize things.
That’s why the “easy way to reopen” is so important. Your concern is theoretically valid, but if tickets are usually ignored for years, then it really is a desperate situation for the project whichever way you handle it. You can decide between an endlessly growing list of issues that likely aren’t valid anymore, or pissing some users off.
I don’t really see why it would be harder to find an existing or similar bug. You should be looking (or rather you should be automatically notified) before/during creating a new ticket for existing tickets describing the problem. If a closed ticket describes the exact problem, you should be finding that too, and then should just be able to use the easy way of reopening if necessary. You should also be able to find the workaround in there if someone posted it.
It’s definitely not a beautiful solution, but if you implement something like this, the project is already in a desperate state, there’s not too much good choices there anymore.
Well the reason to auto-close is that this is not an entirely unlikely resolution. When I inherited a project with a bunch of issues and started going through the backlog, around 50% of tickets were duplicates, already solved, unreproducible, etc etc
When you’ve only got limited time, having less of those issues to analyze and then close anyway is a very valid reason. It leaves more time for fixing real issues. Of course it comes at the cost of ignoring perfectly valid issues as well, that’s why this is obviously never an optimal policy to implement, and should only be done in desperate situations.
Most counterproductive bug tracker feature ever.
I don’t think so. It should have an easy way of reopening - if it has, and you’re flooded with tickets on an open source project that you can’t possibly handle all, then it’s a good way to prioritize. Of course it doesn’t have an easy way to reopen here, which sucks, it’s some kind of locking instead of just closing it with a possibility to reopen.
Old tickets have a non-zero chance of the reporter being the only one to run into it because of a weird setup/usecase (and then abandoning the project), it being fixed by other work, or probably a bunch of other reasons it could be obsolete.
If no one cares enough to reopen it once every 6 months, then it’s probably fine to ignore it indefinitely.
I think it would be better to send a message after 1 month of inactivity, have the bot ask if the issue can still be reproduced with the latest version and then repeat every N months.
The close message should just say exactly this. If it’s one click to reopen, then the click is the response to your suggested notification.
It’s a matter of psychology. If I file a bug and it is ignored for years, I’m annoyed but eventually I either accept it, find a workaround or move on to something new. I may still file bugs in the future, especially if I’ve got a workaround, since other people probably want to know.
However if my bug is closed and I have to reopen it every six months. Now I’m kinda pissed. I have to be reminded every six months for years that this is just broken. I put in the effort, but now some bot has just come along and closed it. Plus it’s going to be harder to find an existing or similar bug. I’m less likely to look at closed bugs. But also, what if I find four similar closer bugs. Now if someone was tracking that bug they don’t realize this has happened to four different users. If we had just kept it in one big we’d all know. Also someone elses workaround is better than mine, or maybe it’s worse.
I understand if a project wants to declare bug bankruptcy. It shouldn’t happen often but if you do that’s the time to organize things.
That’s why the “easy way to reopen” is so important. Your concern is theoretically valid, but if tickets are usually ignored for years, then it really is a desperate situation for the project whichever way you handle it. You can decide between an endlessly growing list of issues that likely aren’t valid anymore, or pissing some users off.
I don’t really see why it would be harder to find an existing or similar bug. You should be looking (or rather you should be automatically notified) before/during creating a new ticket for existing tickets describing the problem. If a closed ticket describes the exact problem, you should be finding that too, and then should just be able to use the easy way of reopening if necessary. You should also be able to find the workaround in there if someone posted it.
It’s definitely not a beautiful solution, but if you implement something like this, the project is already in a desperate state, there’s not too much good choices there anymore.
You can literally sort issues by last activity if you want to proritize based on that. There’s no reason to autoclose issues.
Well the reason to auto-close is that this is not an entirely unlikely resolution. When I inherited a project with a bunch of issues and started going through the backlog, around 50% of tickets were duplicates, already solved, unreproducible, etc etc
When you’ve only got limited time, having less of those issues to analyze and then close anyway is a very valid reason. It leaves more time for fixing real issues. Of course it comes at the cost of ignoring perfectly valid issues as well, that’s why this is obviously never an optimal policy to implement, and should only be done in desperate situations.
“Locked” implies no easy way of reopening.
I… know… that’s why I explicitly mentioned this already xD
6 months would be reasonable, I see a lot that are 30 days or something similar