7 ms·

"I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. " This is not a way to assert a bug is fixed. Success

by jph 5y ago

"I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. " This is not a way to assert a bug is fixed. Success looks like actually trying the code in the bug report that demonstrates the bug, and/or contacting the report participants, to confirm that the bug is actually fixed for the participants.

convolvatron 5y ago
cleaning up the bug reporting system is often one of my jobs. the point of a bug report is to let you know something is going on, to provide context useful in tracking it down, and tracking for the eventual resolution. as they years tick by, some bug reports are counterproductive because they are unclear, dont give _any_ diagnostic information, or are no longer relevant because the codebase has shifted. its great to say for each of these issues we should spend a day or two trying to reproduce them - but its really not the best use of time. we're not talking about capriciously trashing useful bug reports. we're trying to lower the noise floor so that the actionable bugs stand out and are more likely to be dealt with.
- woko 5y ago
  The same way we have text classification for the spam in our mail inbox, couldn't someone train a model to classify issues as actionable bugs vs. noise for large projects like the one mentioned in the OP? Data would come from closed issues: - if the issue lead to a commit, or a merge is mentioned in the thread, then it is actionable, - if the issue was closed without any code change, then it is noise.
  - convolvatron 5y ago
    maybe. but i think this process really helps develop a deeper understanding of the evolution of the project and doesn't take that much time. and I bet your AI isn't going to be able to say 'oh yeah, thats just that thing we fixed in 2.1' seems useful in a second-order capacity though - process introspection
  - 542458 5y ago
    You do see a decent number of GitHub bots that will trash issues if they don’t comply to some sort of “expected/observed/steps/specs” format, which I think more or less accomplishes the same thing. The only issue is you’re potentially losing out on issues from less-tech-savvy users, but I guess simply using GitHub filters many of those people anyways.
chrsig 5y ago
It had been believed to have been fixed over 5 years ago, and had no follow up from the reporter to confirm or refute. Why should a maintainer spend more time on it at this point?
fragbait65 5y ago
My company that I work at actually closes bug reports that has been in "pending customer feedback" for more than 6 months automatically. The customer is free to re-open the issue at a later date if it's still an issue. I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.
- mook 5y ago
  That seems reasonable, because you're waiting for a response that may not arrive. This is very different from a bug where all necessary customer feedback had already been collected, and is pending a fix.
UglyToad 5y ago
I'm reacting from a place of emotion here but your suggested approach just doesn't scale for an open-source project. Nothing is more soul-destroying than an ever growing backlog. If people don't care enough to follow up with an easy reproducible case or even open the PR to fix themselves then they have no right to squat the backlog. Sure for commercial situations you expect the customer to sign off on a fix but a maintainer's responsibility in open source is exactly 0. Even having a bug tracker is an affordance from the maintainer, GitHub supports turning issues off. I'm going to continue to terminate old issues where the problem described was vague or the reporter has gone AWOL and I would encourage all OSS maintainers out there to do the same, let's manage expectations.

by jph 5y ago

convolvatron 5y ago

cleaning up the bug reporting system is often one of my jobs. the point of a bug report is to let you know something is going on, to provide context useful in tracking it down, and tracking for the eventual resolution. as they years tick by, some bug reports are counterproductive because they are unclear, dont give _any_ diagnostic information, or are no longer relevant because the codebase has shifted. its great to say for each of these issues we should spend a day or two trying to reproduce them - but its really not the best use of time. we're not talking about capriciously trashing useful bug reports. we're trying to lower the noise floor so that the actionable bugs stand out and are more likely to be dealt with.

woko 5y ago
The same way we have text classification for the spam in our mail inbox, couldn't someone train a model to classify issues as actionable bugs vs. noise for large projects like the one mentioned in the OP? Data would come from closed issues: - if the issue lead to a commit, or a merge is mentioned in the thread, then it is actionable, - if the issue was closed without any code change, then it is noise.
- convolvatron 5y ago
  maybe. but i think this process really helps develop a deeper understanding of the evolution of the project and doesn't take that much time. and I bet your AI isn't going to be able to say 'oh yeah, thats just that thing we fixed in 2.1' seems useful in a second-order capacity though - process introspection
- 542458 5y ago
  You do see a decent number of GitHub bots that will trash issues if they don’t comply to some sort of “expected/observed/steps/specs” format, which I think more or less accomplishes the same thing. The only issue is you’re potentially losing out on issues from less-tech-savvy users, but I guess simply using GitHub filters many of those people anyways.

chrsig 5y ago

It had been believed to have been fixed over 5 years ago, and had no follow up from the reporter to confirm or refute. Why should a maintainer spend more time on it at this point?

fragbait65 5y ago

My company that I work at actually closes bug reports that has been in "pending customer feedback" for more than 6 months automatically. The customer is free to re-open the issue at a later date if it's still an issue. I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.

mook 5y ago
That seems reasonable, because you're waiting for a response that may not arrive. This is very different from a bug where all necessary customer feedback had already been collected, and is pending a fix.

UglyToad 5y ago

I'm reacting from a place of emotion here but your suggested approach just doesn't scale for an open-source project. Nothing is more soul-destroying than an ever growing backlog. If people don't care enough to follow up with an easy reproducible case or even open the PR to fix themselves then they have no right to squat the backlog. Sure for commercial situations you expect the customer to sign off on a fix but a maintainer's responsibility in open source is exactly 0. Even having a bug tracker is an affordance from the maintainer, GitHub supports turning issues off. I'm going to continue to terminate old issues where the problem described was vague or the reporter has gone AWOL and I would encourage all OSS maintainers out there to do the same, let's manage expectations.