6 ms·

Last message in the thread: > I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything mor

by mhils 5y ago

Last message in the thread: > I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report. I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(

thrdbndndn 5y ago
I'm kind of on the fence for these (in general, not specific to this ticket). Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?
- xdfgh1112 5y ago
  No other approach is sustainable.
  - jfrunyon 5y ago
    Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?
    - ReverseCold 5y ago
      Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.
      - Chilinot 5y ago
        Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.
      - mpweiher 5y ago
        And if not, the bug is probably not important. ¯\_(ツ)_/¯ At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares. And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.
        amyjess 5y ago
        At my last job, this was the attitude we eventually took with tickets that were several years old. If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out. [0] when I say "customer", I'm talking about a department, not a single individual
      - dmz73 5y ago
        There are two instances I can think of (I've done it myself) where the bug is important but user does not come back to check on the report after 1 or 2 weeks: 1) Trying out different environment and finding things that do not work. Report a bug with reproducible example and don't check it for a while (months or years) since there is important work to be done in working environment. 2) Find a bug and then find the workaround since work can't wait for external fixes. Report a bug with reproducible example, check the status for a few days with no responses and then ignore the bug since there is important work to be done and workaround has been applied. Now you know one of the reasons why "legacy" code might look messy - it has workarounds for the bugs that may have been fixed...but who has the time to go back and check, change, and test the "fixed" code which may introduce other bugs.
    - dotancohen 5y ago
      Not five year. Two months went from the OP in September 2015 to the final dev message in November 2015, during which the OP and the dev were communicating regularly. It was the OP who didn't respond after the dev mentioned that he believes that he fixed all the outstanding issues. It was five years later that someone came along and closed the bug.
      - LanceH 5y ago
        I would estimate the chance of a user coming back to close a bug at near zero, even after only two months.
        laumars 5y ago
        Indeed. As a fellow maintainer I will manually replicate the error the user reports, write an test to around the failing function, then fix said function. After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.” That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family). Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.
        pwdisswordfish0 5y ago
        > ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.” This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope. It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.
    - jodrellblank 5y ago
      Recognising the orignal bug opener's name, Markus Triska, I know he's on HN. I checked his username to see if he's been active recently and, well, see for yourself: https://news.ycombinator.com/threads?id=triska https://news.ycombinator.com/threads?id=triska
  - SquishyPanda23 5y ago
    For what it's worth, when I encounter a project doing this I treat it as a giant red flag that the developers don't care about the quality of their project. In the majority of cases, there's another project that I can move to and I do so as soon as possible. There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.
  - EugeneOZ 5y ago
    While reporter is still alive.
  - jcelerier 5y ago
    sometimes it feels to me that people collectively forget that writing software (especially FOSS)'s primary goal is to empower other human beings, before anything else - including our own little developer comfort. Closing unfixed bugs because of no activity really really goes against that in my mind.
    - lobocinza 5y ago
      Closing issues by itself do not fix bugs.
- yonixw 5y ago
  IMO, It is the user responsibility to make a reproducible bug (to become a failing test). From there on it is the developer responsibility to fix it (make it a passing test)
  - ajnin 5y ago
    Absolutely. If there is nothing new and a bug is still there, there is simply nothing to add to the bug report. Too often now bugs get closed automatically for "inactivity" after a short period. Should users come back every months to "ping" the thread ? Some bugs last for years, they'd sooner be blocked for spamming. It's just Goodhart's law in action, a cheap way to reduce the bug report count.
yashap 5y ago
Agreed. The bug report was one reporter and a maintainer discussing a bug for 2 months back in 2015, and at the end the maintainer says he believes he’d fixed it. Then no more messages. After 5 years of no complaints after a likely fix, closing it is very, very reasonable.

by mhils 5y ago

thrdbndndn 5y ago

I'm kind of on the fence for these (in general, not specific to this ticket). Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?

xdfgh1112 5y ago
No other approach is sustainable.
- jfrunyon 5y ago
  Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?
  - ReverseCold 5y ago
    Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.
    - Chilinot 5y ago
      Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.
    - mpweiher 5y ago
      And if not, the bug is probably not important. ¯\_(ツ)_/¯ At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares. And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.
      - amyjess 5y ago
        At my last job, this was the attitude we eventually took with tickets that were several years old. If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out. [0] when I say "customer", I'm talking about a department, not a single individual
    - dmz73 5y ago
      There are two instances I can think of (I've done it myself) where the bug is important but user does not come back to check on the report after 1 or 2 weeks: 1) Trying out different environment and finding things that do not work. Report a bug with reproducible example and don't check it for a while (months or years) since there is important work to be done in working environment. 2) Find a bug and then find the workaround since work can't wait for external fixes. Report a bug with reproducible example, check the status for a few days with no responses and then ignore the bug since there is important work to be done and workaround has been applied. Now you know one of the reasons why "legacy" code might look messy - it has workarounds for the bugs that may have been fixed...but who has the time to go back and check, change, and test the "fixed" code which may introduce other bugs.
  - dotancohen 5y ago
    Not five year. Two months went from the OP in September 2015 to the final dev message in November 2015, during which the OP and the dev were communicating regularly. It was the OP who didn't respond after the dev mentioned that he believes that he fixed all the outstanding issues. It was five years later that someone came along and closed the bug.
    - LanceH 5y ago
      I would estimate the chance of a user coming back to close a bug at near zero, even after only two months.
      - laumars 5y ago
        Indeed. As a fellow maintainer I will manually replicate the error the user reports, write an test to around the failing function, then fix said function. After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.” That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family). Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.
        pwdisswordfish0 5y ago
        > ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.” This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope. It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.
  - jodrellblank 5y ago
    Recognising the orignal bug opener's name, Markus Triska, I know he's on HN. I checked his username to see if he's been active recently and, well, see for yourself: https://news.ycombinator.com/threads?id=triska https://news.ycombinator.com/threads?id=triska
- SquishyPanda23 5y ago
  For what it's worth, when I encounter a project doing this I treat it as a giant red flag that the developers don't care about the quality of their project. In the majority of cases, there's another project that I can move to and I do so as soon as possible. There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.
- EugeneOZ 5y ago
  While reporter is still alive.
- jcelerier 5y ago
  sometimes it feels to me that people collectively forget that writing software (especially FOSS)'s primary goal is to empower other human beings, before anything else - including our own little developer comfort. Closing unfixed bugs because of no activity really really goes against that in my mind.
  - lobocinza 5y ago
    Closing issues by itself do not fix bugs.
yonixw 5y ago
IMO, It is the user responsibility to make a reproducible bug (to become a failing test). From there on it is the developer responsibility to fix it (make it a passing test)
- ajnin 5y ago
  Absolutely. If there is nothing new and a bug is still there, there is simply nothing to add to the bug report. Too often now bugs get closed automatically for "inactivity" after a short period. Should users come back every months to "ping" the thread ? Some bugs last for years, they'd sooner be blocked for spamming. It's just Goodhart's law in action, a cheap way to reduce the bug report count.

yashap 5y ago

Agreed. The bug report was one reporter and a maintainer discussing a bug for 2 months back in 2015, and at the end the maintainer says he believes he’d fixed it. Then no more messages. After 5 years of no complaints after a likely fix, closing it is very, very reasonable.