3 ms·

+1 - subtly, if it's important someone will re-file or re-open it.

by asah 5y ago

touisteur 5y ago
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).
- touisteur 5y ago
  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.
xoa 5y ago
>+1 - subtly, if it's important someone will re-file or re-open it. With all due respect, this absolutely is not the only outcome. I'm going through this right now with UniFi and Ubiquiti, which has been a raging development dumpster fire for years now though the rot has only really started to become critical and more generally obvious the last year or two. UniFi is full of very important bugs, issues, and missing or badly implemented core functionality. But, like many many others, after devoting a lot of time to detailed bug reports and figuring out how to make it reproducible and extensive work helping identify how to meet standards that all got closed/ignored or even actively got worse? I simply don't give a flying fuck any longer. I'm not "re-filing" (of course, they've dumped even their minimal mediocre old feature/bug tracker anyway with no replacement, but I don't make new threads either). I mostly don't bother anymore with reporting anything UniFi at all. Instead I've been steadily migrating away entirely. For me, UniFi is now in a completely subservient role, still doing a certain amount of switching and WiFi but with 100% of core network functions, routing/gateway coverage etc moved to OPNsense. As the time comes to get new gear anyway for WiFi 6E/7 and more multigig switching that'll be the end of it for my ~100 pieces of kit. Of course companies/projects are free not to care, and depending on what sort of goal a project has or what sort of lock-in/stickiness and core revenue areas a business has it may indeed not matter if there is an exodus of small/older users/customers. But it shouldn't be assumed in every instance that "if this is really important someone will poke us again" because everyone only has so much time themselves to poke you, and if word gets around that it's pointless to even try than that will be the last you hear from them until they're gone entirely. IMO, the true terror for many business/projects shouldn't be criticism, it's silence. When people simply don't even care enough to even invest the time to get mad anymore.

+1 - subtly, if it's important someone will re-file or re-open it.

by asah 5y ago

+1 - subtly, if it's important someone will re-file or re-open it.

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).

touisteur 5y ago
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.

xoa 5y ago

>+1 - subtly, if it's important someone will re-file or re-open it. With all due respect, this absolutely is not the only outcome. I'm going through this right now with UniFi and Ubiquiti, which has been a raging development dumpster fire for years now though the rot has only really started to become critical and more generally obvious the last year or two. UniFi is full of very important bugs, issues, and missing or badly implemented core functionality. But, like many many others, after devoting a lot of time to detailed bug reports and figuring out how to make it reproducible and extensive work helping identify how to meet standards that all got closed/ignored or even actively got worse? I simply don't give a flying fuck any longer. I'm not "re-filing" (of course, they've dumped even their minimal mediocre old feature/bug tracker anyway with no replacement, but I don't make new threads either). I mostly don't bother anymore with reporting anything UniFi at all. Instead I've been steadily migrating away entirely. For me, UniFi is now in a completely subservient role, still doing a certain amount of switching and WiFi but with 100% of core network functions, routing/gateway coverage etc moved to OPNsense. As the time comes to get new gear anyway for WiFi 6E/7 and more multigig switching that'll be the end of it for my ~100 pieces of kit. Of course companies/projects are free not to care, and depending on what sort of goal a project has or what sort of lock-in/stickiness and core revenue areas a business has it may indeed not matter if there is an exodus of small/older users/customers. But it shouldn't be assumed in every instance that "if this is really important someone will poke us again" because everyone only has so much time themselves to poke you, and if word gets around that it's pointless to even try than that will be the last you hear from them until they're gone entirely. IMO, the true terror for many business/projects shouldn't be criticism, it's silence. When people simply don't even care enough to even invest the time to get mad anymore.