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.
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.
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.
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.
“Locked” implies no easy way of reopening.