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.
> 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.)
> A public bug tracker isn't just for you. It, arguably, isn't even primarily for you.
There is a lot of work still to be done on bug-tracking. The eternal attempt to keep users away from bugtrackers has meant that, when they inevitably became public because of FOSS growth, their interfaces did not really work for users.
I think it's high time we accepted bug trackers are also forums. There should be a way to mark certain comments as "effective workaround", and surface them at first glance. There should be ways for developers to mark certain comments as "useful info" so that the rest can be filtered. There should be ways to have lengthy discussions attached to the bug but not forced on the developer. There should be incentives to actually solve "historical" bugs first. In short, there should be different ways to look at a bug depending on one's role, without losing anything, without alienating anyone, and accepting the complexity of user-developer relations.
That's a great perspective. I agree with what you wrote here.
With that in mind, I believe that properly supporting all the various use cases an issue tracker serves without turning it into another JIRA is a hard UI design task.
But at the same time, practices like closing or locking stale bug reports can be seen as UI workarounds. Some people feel their boards are cluttered, so they reach for the only tools available - the close button, the lock button, an autoclosing/autolocking bot. It solves the UI issue for them, at the expense of other groups of board users.
This is to say: it's ultimately an UI deficiency on the part of a common issue trackers. Developers should be able to restructure their board as they see fit, but it shouldn't impact other users' ability to utilize the data stored on it. It would be great if major software forges solved this on their end.
Perhaps we need a concept of a "stale" issue/thread that's distinct from a "closed" one. A stale issue would be one that's not actively being looked at, but is nevertheless not resolved. The way it would differ from a regular open issue is:
- It doesn't sort itself up when somebody posts a comment on it.
- Posting on it doesn't notify people who didn't explicitly subscribe to it - all activity on stale issue is grouped under a single, inconspicuous indicator, that can be easily ignored.
- Stale issues are always sorted to the bottom or kept on a separate tab, and are trivial to filter in or out during searches. But the tab marker itself stays visible, so that people can find out there are such issues in the first place.
- Stale issue can be explicitly promoted to active at the discretion of the developers (or perhaps by community vote).
Hopefully this would reduce the need to aggressively close - and especially to lock - older issues.
PHP's documentation allowed (allows? Not sure anymore) comments. Especially in the pre-StackOverflow days, this was absolutely brilliant. I'm sure that's a pretty heavy moderation burden for any successful language (especially these days, maybe not as much when PHP's docs first added that feature) but damn it's nice.
I love the idea of bugtracker-as-forum (you're right that they already are and we're just in denial about it and don't design them to do that well) but it's the kind of thing that doesn't seem productizable (how many companies would want that, for instance? I doubt many) and non-commercial non-trivial open source isn't such a lively field, lately.
As an example of this, the SQLite bug tracker [0] is closed for submissions from non-developers (or some set of trusted people), and instead the SQLite forum [1][2] is used to discuss possible bugs.
Because - per the pattern of behavior we're discussing in this thread - some developers close old issues, whether they were actually resolved or not, and it's becoming a common practice, particularly with the appearance of bots performing this function automatically.
Also, not everyone is using the most recent release.
Some issues are not actually bugs but user errors (e.g. because they haven't read the manual). Personally I'm not sure if it's better to close such issues or keep them open with a special label.
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.
Stalebot (the popular one on GH) has exemptions which are configurable - branch, author, label, commenter, and probably more. AKA owner/maintainer can do as little as drop a label or even just a reply on an issue and it won't be pruned.
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.
> 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.
> 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.
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.
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.
> 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.
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.
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?
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.