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.
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.)
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.
But there is very little money in it, I guess.
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.
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.
[0] https://www.sqlite.org/src/reportlist [1] https://www.sqlite.org/src/wiki?name=Bug+Reports [2] https://www.sqlite.org/forum/forum
Is there a reaction emoji that signals "effective workaround"?
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.
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.
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.
This is "DELETE .... FROM TABLE WHERE ...."
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.
