Separation of Concerns in a Bug Tracker
5 comments
·March 8, 2025shanemhansen
hinkley
I thought Despair.com kept all of their old posters but I can't find the one you're reminding me of.
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.
pm215
I'm not a fan of the "stale bot" approach to bugs either, but I think what it's doing can at least somewhat be classified as part of the "facts" side of the division. The initial bug report conveys the fact "version 3.5 crashes when passed the --wombat option". A year later that fact is still true but is of very little interest to the dev team: what they want to know is whether "version 5.0 crashes when passed --wombat" is true or not. The stale-bot is pushing the obligation to test that new different fact onto the bug submitter. (I think it's better to leave that with the dev team; plus unless the devs plan to actually fix it then retesting on 5.0 is just gathering another fact that isn't going to matter...)
hinkley
If a problem hasn't been fixed in 1.5 versions then I'm likely to have moved on to a different tool, and I no longer have the context to reproduce it.
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.
simonmic
A nice writeup.
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).
I would like to live in this world. If for no other reason than the idea of teams frequently declaring "bug bankruptcy" or the frequent use of "stale bots" to ignore issues that I haven't nagged about enough recently are actually offensive.
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".