Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Every once in a while I get an email about a ten plus year old bug finally getting fixed in some open source project. If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority.


> If it's a good bug accurately describing a real thing, there's no reason to throw that work away rather than just marking it lower priority.

Perhaps. But the triage to separate the "good bugs accurately describing real things" from the chaff isn't free either.


Storage is cheap, database indexes work. Just add a `TimesChecked` counter to your bug tracker.

Now when considering priorities, consider not just impact and age, but also times checked.

It's less expensive than going and deleting stuff. Unless you're automating deletions? In which case... I don't think I can continue this discussion.


In what world is adding a custom field to a bug tracker and maintaining it cheaper than anything? If someone proves out this workflow and releases a bug tracker that has the functionality built in then I'll consider adopting it, but I'm certainly not going to be the first.


Wild.

Okay, keep deleting bug tickets.


We already have a TimesChecked counter:

If (status != Active) { /* timesChecked > 0 */ }




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: