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.<p>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.<p>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.<p>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".
I have rarely been so happy to see a post.<p>I am working on designing a bug tracker, and this post completely clarified that I am going down the wrong road.<p>Back to the drawing board.
A nice writeup.<p>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).<p>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.<p>(I get about 60% bugs, 40% wishes).
Really interesting perspective that i think i did not read in this form before. I think these two things should be separate tools a bug tracker as a database of bugs and a project tracker for the planning part. I try to build this project tracker here (<a href="https://lanes.pm" rel="nofollow">https://lanes.pm</a>)
Separating plans from facts is such a great idea for ticketing. That would also make stories have a clearer separation from tasks. Your ticketing system could be used as a way to document your software from the customer's perspective.