10 ms·

Meh. It's just a method of filtration. When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate and with little

by Jenk 5y ago

Meh. It's just a method of filtration. When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate and with little in the way of automatic triage determining the priority it is a borderline impossible task to wade through them. Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off.

tinus_hn 5y ago
It’s fine, as long as the time he submitter spent to write a decent bug report is worthless to you.
- frereubu 5y ago
  That's a straw man. It's a balance between your time and theirs, and I presume you don't think that all bug reports are carefully considered and well-written. Many are even obtuse, aggressive and self-entitled. I'd bet most well-written, civil bug reports are at least taken seriously, even if they end up as a wontfix.
  - tinus_hn 5y ago
    You don’t need to wait for a certain period of time to decide that a bug report is poorly written.
  - ForHackernews 5y ago
    There's nearly zero cost to leaving a stale bug report open. A few kB, and maybe not even that because closed tickets are rarely actually deleted. If you're not working on a bug, then, by definition, it's not taking up your time. Some people are just obsessive about not wanting to look like they have open bugs on their project. But closing tickets and fixing bugs are not the same thing.
    - thaumasiotes 5y ago
      > But closing tickets and fixing bugs are not the same thing. You can't measure how many bugs you have, but you can measure how many bug reports you have. ;D
    - marcosdumay 5y ago
      > There's nearly zero cost to leaving a stale bug report open. Triaging an endless list is very costly. I do agree with the idea that if you expect your project to be public (and not just something you did that you'll share if somebody wants) it is a cost you are expected to take. But it's wrong to pretend it's free.
      - oooooooooooow 5y ago
        Triage is what happens when you first look at a new ticket and decide what to do with it, any encounter/interaction after that is not a triage. If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling: tickets should only be closed if they're malformed, solved, or (arguably) wontfix.
        Jenk 5y ago
        Priority is a constantly moving slide.
        marcosdumay 5y ago
        > If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling Oh, yes. Yes it is! I think you were downvoted because the first part of your answer is wrong, but this one hits right on the mark.
        oooooooooooow 5y ago
        I've always interpreted "triage" as the first response whenever something comes up (paralleling the medical term were it's from), is that not how it is?
TeMPOraL 5y ago
> When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate A public bug tracker isn't just for you. It, arguably, isn't even primarily for you. It's for all your users who experience a problem and want to confirm if someone else also had it, and if there's a known solution. (It's something that particularly annoys me as a developer. I can fix problems on my own just fine, thank you. But I want to know if my problem is something tied to my configuration, or a known issue of some software that's failing for me - so that I don't waste time looking for the cause in the wrong place. I want the project's issue tracker to help me answer that question quickly - and auto-hiding/archiving/closing stale issues makes this job much harder.)
- feu 5y ago
  Closing an issue shouldn't prevent anyone from finding it though. At least on GitHub closed issues are still visible in the issue tracker.
  - innocenat 5y ago
    Who search for closed issues when searching if other have the same bug?
    - TeMPOraL 5y ago
      I do, because I realized people close stale issues just because (and then there are bots that do it now too). I'm happy I can still do it, and I worry that one day someone will have a bright idea to "archive" closed issues to where they cannot be easily found.
    - NicoJuicy 5y ago
      I do. Because perhaps it's fixed in a newer version or ...
  - kenniskrag 5y ago
    I think closed issues shouldn't be a problem on the current release. So why search through them?
MayeulC 5y ago
> Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off. You lose a lot of context from other reporters, and some discussion that could happen between reporters. All of this allows diagnosing an issue, and sometimes solving it without input from the team ("ah, this 3 years old bug? I solved it, turns out I had faulty memory, check yours"). I dislike closing them, especially as github only has two states: open and closed, and doesn't distinguish with invalid, wontfix, fixed, stale, needinfo, etc. At least they are still searchable and interactable with when closed, but who thought it was a god idea to lock them? All the original subscribers won't be notified of new discussion on the topic.
- Jenk 5y ago
  AFAIK when a closed/locked issue is referenced, watchers get notified. If they don't I agree they should.
MaxBarraclough 5y ago
> Meh. It's just a method of filtration. No, it's a method of automatically discarding valuable information. To put a different spin on what TeMPOraL said: a bug is roughly defined as a deviation from expected program behaviour. It is not defined as a deviation from expected behaviour which we intend to fix soon. There is value in keeping track of all the bugs in a codebase, even the ones you don't intend to fix soon. That is to say, a bug tracker is for tracking bugs. It is not a to-do list. (edit Although I wouldn't want items on my to-do list to expire without my knowledge, either.) If you want to mark a reported bug as Not a bug or Won't fix, that should be done manually. If a bug was fixed in passing as a result of some other work, the bug should be manually marked as fixed. It doesn't make sense to have a timeout act as a stand-in for a triage decision, in a way that fails to distinguish between these two outcomes.
- Jenk 5y ago
  > No, it's a method of automatically discarding valuable information. So.. a filter. I didn't claim it is a perfect filter. I did claim it is _a_ filter and one may subjectively decide it is a better choice than trying to track an ocean of issues which, if you're someone the size of Mozilla, will be a vast majority of "It crashed" useless issues anyway. _If_ something is that important, it will come up again and closed issues can be referenced. Again, no claim that this is perfect from me.
  - CRConrad 5y ago
    No, not "a filter". A filter is like "SELECT .... FROM TABLE WHERE ...." This is "DELETE .... FROM TABLE WHERE ...."
steerablesafe 5y ago
If you can automatically close old bugs then you can automatically filter those same bugs, without closing them.

by Jenk 5y ago

tinus_hn 5y ago

It’s fine, as long as the time he submitter spent to write a decent bug report is worthless to you.

frereubu 5y ago
That's a straw man. It's a balance between your time and theirs, and I presume you don't think that all bug reports are carefully considered and well-written. Many are even obtuse, aggressive and self-entitled. I'd bet most well-written, civil bug reports are at least taken seriously, even if they end up as a wontfix.
- tinus_hn 5y ago
  You don’t need to wait for a certain period of time to decide that a bug report is poorly written.
- ForHackernews 5y ago
  There's nearly zero cost to leaving a stale bug report open. A few kB, and maybe not even that because closed tickets are rarely actually deleted. If you're not working on a bug, then, by definition, it's not taking up your time. Some people are just obsessive about not wanting to look like they have open bugs on their project. But closing tickets and fixing bugs are not the same thing.
  - thaumasiotes 5y ago
    > But closing tickets and fixing bugs are not the same thing. You can't measure how many bugs you have, but you can measure how many bug reports you have. ;D
  - marcosdumay 5y ago
    > There's nearly zero cost to leaving a stale bug report open. Triaging an endless list is very costly. I do agree with the idea that if you expect your project to be public (and not just something you did that you'll share if somebody wants) it is a cost you are expected to take. But it's wrong to pretend it's free.
    - oooooooooooow 5y ago
      Triage is what happens when you first look at a new ticket and decide what to do with it, any encounter/interaction after that is not a triage. If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling: tickets should only be closed if they're malformed, solved, or (arguably) wontfix.
      - Jenk 5y ago
        Priority is a constantly moving slide.
      - marcosdumay 5y ago
        > If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling Oh, yes. Yes it is! I think you were downvoted because the first part of your answer is wrong, but this one hits right on the mark.
        oooooooooooow 5y ago
        I've always interpreted "triage" as the first response whenever something comes up (paralleling the medical term were it's from), is that not how it is?

TeMPOraL 5y ago

> When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate A public bug tracker isn't just for you. It, arguably, isn't even primarily for you. It's for all your users who experience a problem and want to confirm if someone else also had it, and if there's a known solution. (It's something that particularly annoys me as a developer. I can fix problems on my own just fine, thank you. But I want to know if my problem is something tied to my configuration, or a known issue of some software that's failing for me - so that I don't waste time looking for the cause in the wrong place. I want the project's issue tracker to help me answer that question quickly - and auto-hiding/archiving/closing stale issues makes this job much harder.)

feu 5y ago
Closing an issue shouldn't prevent anyone from finding it though. At least on GitHub closed issues are still visible in the issue tracker.
- innocenat 5y ago
  Who search for closed issues when searching if other have the same bug?
  - TeMPOraL 5y ago
    I do, because I realized people close stale issues just because (and then there are bots that do it now too). I'm happy I can still do it, and I worry that one day someone will have a bright idea to "archive" closed issues to where they cannot be easily found.
  - NicoJuicy 5y ago
    I do. Because perhaps it's fixed in a newer version or ...
- kenniskrag 5y ago
  I think closed issues shouldn't be a problem on the current release. So why search through them?

MayeulC 5y ago

> Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off. You lose a lot of context from other reporters, and some discussion that could happen between reporters. All of this allows diagnosing an issue, and sometimes solving it without input from the team ("ah, this 3 years old bug? I solved it, turns out I had faulty memory, check yours"). I dislike closing them, especially as github only has two states: open and closed, and doesn't distinguish with invalid, wontfix, fixed, stale, needinfo, etc. At least they are still searchable and interactable with when closed, but who thought it was a god idea to lock them? All the original subscribers won't be notified of new discussion on the topic.

Jenk 5y ago
AFAIK when a closed/locked issue is referenced, watchers get notified. If they don't I agree they should.

MaxBarraclough 5y ago

> Meh. It's just a method of filtration. No, it's a method of automatically discarding valuable information. To put a different spin on what TeMPOraL said: a bug is roughly defined as a deviation from expected program behaviour. It is not defined as a deviation from expected behaviour which we intend to fix soon. There is value in keeping track of all the bugs in a codebase, even the ones you don't intend to fix soon. That is to say, a bug tracker is for tracking bugs. It is not a to-do list. (edit Although I wouldn't want items on my to-do list to expire without my knowledge, either.) If you want to mark a reported bug as Not a bug or Won't fix, that should be done manually. If a bug was fixed in passing as a result of some other work, the bug should be manually marked as fixed. It doesn't make sense to have a timeout act as a stand-in for a triage decision, in a way that fails to distinguish between these two outcomes.

Jenk 5y ago
> No, it's a method of automatically discarding valuable information. So.. a filter. I didn't claim it is a perfect filter. I did claim it is _a_ filter and one may subjectively decide it is a better choice than trying to track an ocean of issues which, if you're someone the size of Mozilla, will be a vast majority of "It crashed" useless issues anyway. _If_ something is that important, it will come up again and closed issues can be referenced. Again, no claim that this is perfect from me.
- CRConrad 5y ago
  No, not "a filter". A filter is like "SELECT .... FROM TABLE WHERE ...." This is "DELETE .... FROM TABLE WHERE ...."

steerablesafe 5y ago

If you can automatically close old bugs then you can automatically filter those same bugs, without closing them.