Separation of Concerns in a Bug Tracker
chiark.greenend.org.uk
chiark.greenend.org.uk
Both of them throw away real bugs and even work done by users to reproduce and turn a fact: "your program crashes when x happens" from something they can verify and accept to an ongoing time commitment to nag them. I don't want to nag them, I doubt they want to be nagged by me. What they probably want is some signal for prioritization of planning which stale bots do, poorly.
Why do they constantly ignore what their users tell them? Because to use the terminology from the article, to a user they are reporting a bug but to the maintainers that is potentially adding to planned work and their capacity is finite. A team should absolutely be able to say "we have no plans of addressing this even though it's true that our software doesn't work on an ancient version of glibc" for example.
In this model the stale bot would apply to plans not bugs. A "stale" plan would be an item of work that users have not expressed interest in for the last N days. Which at a gut level is a lot more acceptable than "the software we acknowledged is broken hasn't been fixed this month so we're going to close the issue".
If I'm the only one who felt that way maybe that's efficient. But that's not always the case and I've had bugs get closed when there were 4 other commenters with the same problem.
It's a picture of an old Bell telephone. It says something like, "If we ignore the problem long enough it'll go away."
Some problems like ancient versions of glibc are in fact likely to go away. But a security hole or ergonomics problem that gets ignored into closure may convince that user to switch to a competing project. Maybe in the marketplace of ideas that's actually a good thing. But it sucks for the people having to wander around.
I've always considered that if code I declared done isn't, that it's akin to a broken promise. Now if you wanted it to do something completely different than what we discussed, or you've invented some new definition of a word in your mind, then I'm likely to be almost as ambivalent as the next person. But if I said it would do something and it doesn't then it's a problem.
I have some trouble relating to people who can shrug this stuff off. It feels like a moral failure to me, and dismissals merely amplify that feeling.
I am working on designing a bug tracker, and this post completely clarified that I am going down the wrong road.
Back to the drawing board.
Here's a simple hack in this direction. In an issue tracker like github's, add "bug" or "wish" labels to all issues (except the few which turn out to be neither, eg support requests). "Bugs" are accepted defects (facts), "wishes" are enhancement requests/proposals (plans, or less than plans).
Actually I use A-BUG and A-WISH, and colour code them, to make them stand out and always be clearly visible at the start of the labels.
(I get about 60% bugs, 40% wishes).