Separation of Concerns in a Bug Tracker

I would like to live in this world. If for no other reason than the idea of teams frequently declaring &quot;bug bankruptcy&quot; or the frequent use of &quot;stale bots&quot; to ignore issues that I haven&#x27;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: &quot;your program crashes when x happens&quot; from something they can verify and accept to an ongoing time commitment to nag them. I don&#x27;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 &quot;we have no plans of addressing this even though it&#x27;s true that our software doesn&#x27;t work on an ancient version of glibc&quot; for example.<p>In this model the stale bot would apply to plans not bugs. A &quot;stale&quot; 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 &quot;the software we acknowledged is broken hasn&#x27;t been fixed this month so we&#x27;re going to close the issue&quot;.

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&#x27;s a simple hack in this direction. In an issue tracker like github&#x27;s, add &quot;bug&quot; or &quot;wish&quot; labels to all issues (except the few which turn out to be neither, eg support requests). &quot;Bugs&quot; are accepted defects (facts), &quot;wishes&quot; are enhancement requests&#x2F;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:&#x2F;&#x2F;lanes.pm" rel="nofollow">https:&#x2F;&#x2F;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&#x27;s perspective.