Yeah and I agree especially for poorly documented issues, unclear demands on your time, etc.
But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway.
And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow.
I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets.
And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).
And the worst part is that for anything else than clearly laid out bugs/issues, I apply GP's described strategy (if it is important, it'll come back or I'll remember), especially as a protection against burnout. I have taught myself to stop worrying missing an email or not be on top of everyfuckingthing. Yeah I'll come around to look and will say 'must be redone, sorry' and there's waste. It's bad. But you can't do everything and when the external environment doesnt you adjust to your work capacity by itself, I've decided to let not-so-critical things slide a bit. If/when there's a complaint, either I'll resend the email about not having the time to follow subject X or my manager will... It's OK.
But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway.
And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow.
I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets.
And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).