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.
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.
“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
Even worse is finding a rejected pull request that would have added the exact feature you need.
This except it’s activity on the PR I submitted and it’s just a bot marking it as stale because there’s been no activity. Well it’s ready to merge if a maintainer would just click the button… Or tell me why they won’t merge it
This is how bugs take 10+ years to be fixed
I understand that developers don’t always have time or interest to fix my problems (specially with FOSS projects), but this just feels like rubbing it in my face. Just close the issue after initial assessment if it looks like a non-fixable and low priority.
“See this is how much we care, we even have a bot to remind you that we are still ignoring you”
exactly, if devs ignore issues that is to me just them telling the world that they don’t care about the project and we should encourage people to fork it and take over the mantle of de-facto version, or just let it die if it’s not important.
The bug persists, preparedness for the bug has ceased.
every time I see this it always follows with comment that reopens the issue. inactive != resolved.
