4 ms·

146 messages in that bug thread. Wow.

by tpmx 5y ago

irrational 5y ago
> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If only there was a way to find out, instead of guessing. I’m going to start trying this at work. I wonder how it will be received?
- jerrysievert 5y ago
  I’m going to guess that when you close issues that are years old, a fraction of them will reappear as enough people have devised workarounds for the issues and they will become the de facto fix.
- namdnay 5y ago
  > I’m going to start trying this at work. I wonder how it will be received? You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year
  - nsizx 5y ago
    That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?
    - arthur2e5 5y ago
      I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…
  - deleted 5y ago
    [deleted]
  - irrational 5y ago
    Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.
    - phkahler 5y ago
      For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?
      - joshuaissac 5y ago
        The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.
      - irrational 5y ago
        See my response to kortilla above.
    - Chilinot 5y ago
      QA is not your test suite. Test your own code, submit working code, let QA try to break it. Dont just push code and expect others to point out your flaws. Take some responsibility.
      - irrational 5y ago
        See my response to kortilla above.
    - kortilla 5y ago
      > Though, to be honest, it is QA who is testing it, not us developers. Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues. Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).
  - dragonwriter 5y ago
    In most places I’ve worked, having a bug untouched for even a fairly small fraction of that time would result in someone getting, at a minimum, corrective counseling.
    - kortilla 5y ago
      Corrective counseling for a single bug? I take it you’ve never worked in a US software company.
- taeric 5y ago
  Yeah... This actually seems standard for old backlogs. Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen. Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.
- toast0 5y ago
  When I worked for Facebook, the had a bugtracker bot that closes open issues after 6? months of no activity. It's sort of nice, but also terrible.
- aprdm 5y ago
  I’ve done this at work many times, it’s the only way I’ve found to keep a big project back log under control… if people care enough they can reopen
- thrower123 5y ago
  Everybody does this, it's the normal behavior with enterprise bugs. They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.

146 messages in that bug thread. Wow.

by tpmx 5y ago

146 messages in that bug thread. Wow.

> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If only there was a way to find out, instead of guessing. I’m going to start trying this at work. I wonder how it will be received?

jerrysievert 5y ago
I’m going to guess that when you close issues that are years old, a fraction of them will reappear as enough people have devised workarounds for the issues and they will become the de facto fix.
namdnay 5y ago
> I’m going to start trying this at work. I wonder how it will be received? You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year
- nsizx 5y ago
  That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?
  - arthur2e5 5y ago
    I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…
- deleted 5y ago
  [deleted]
- irrational 5y ago
  Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.
  - phkahler 5y ago
    For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?
    - joshuaissac 5y ago
      The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.
    - irrational 5y ago
      See my response to kortilla above.
  - Chilinot 5y ago
    QA is not your test suite. Test your own code, submit working code, let QA try to break it. Dont just push code and expect others to point out your flaws. Take some responsibility.
    - irrational 5y ago
      See my response to kortilla above.
  - kortilla 5y ago
    > Though, to be honest, it is QA who is testing it, not us developers. Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues. Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).
- dragonwriter 5y ago
  In most places I’ve worked, having a bug untouched for even a fairly small fraction of that time would result in someone getting, at a minimum, corrective counseling.
  - kortilla 5y ago
    Corrective counseling for a single bug? I take it you’ve never worked in a US software company.
taeric 5y ago
Yeah... This actually seems standard for old backlogs. Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen. Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.
toast0 5y ago
When I worked for Facebook, the had a bugtracker bot that closes open issues after 6? months of no activity. It's sort of nice, but also terrible.
aprdm 5y ago
I’ve done this at work many times, it’s the only way I’ve found to keep a big project back log under control… if people care enough they can reopen
thrower123 5y ago
Everybody does this, it's the normal behavior with enterprise bugs. They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.