> 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.
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.