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