Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
30

Generally you have two axes for bugs: gravity and frequency. So obviously something grave and frequent is of the highest priority. However, something that's serious but happens rarely should be weighed roughly at the same as something that's not serious but happens often. So supposing you rate gravity from 1 to 3 and frequency from 1 to 3, the types of ...


24

This really boils down to what you consider to be more important. The P2 bug or the new feature? Usually an agile project management system will include some sort of prioritisation meeting where tasks are ordered by priority and worked on in that order. Developers are not allowed to choose the tasks they work on. That's the job of the project manager. Who ...


10

In the cases in which it is absolutely clear that the issue/root cause is the same (for example crashes with the same traceback occurring in the same conditions, only reported by different customers) yes, closing it as a duplicate is IMHO perfectly OK - tracking the 2 (or more) issues separately is just a waste of time/resources. In other cases marking as ...


6

You want to have a clear view of the issues with a software. If a system has 10 issues, you want 10 open bugs. Not 10.000 open bugs of duplicates. You also want the minimum amount of administration. So closing a bug as duplicate when someone finds out it is, is the sensible thing to do. Time is expensive and you want to spend as little time as possible on ...


3

There's a fundamental difference between an issue that is unsolvable due to lack of information and an issue that is low priority. For issues that are unsolvable because they don't contain appropriate steps to reproduce or known debugging and troubleshooting techniques have not turned up anything, the closest you may come to a resolution is the addition of ...


1

You need a logging stack. ELK, app insights, splunk etc So your app just logs the error, to a file, syslog,api call whatever and moves on. No sending emails, just fire and forget. These logs are then collected and combined into a timeseries database. ie logstash monitors the file, app insights saves the api call, splunk.. splunks The time series database ...


1

We have a bunch of statuses and resolutions that can be used when a bug is closed without being fixed, or when it is left open without being actively worked: abandoned aged out cancelled cannot reproduce expired monitor on hold postponed waiting on info won't fix I don't know if we actually use all of these, but they can be filtered in or out as ...


1

It is a pretty common cycle for a software to pile up noncritical bugs until something gives, then a big event happens and many of them are fixed at a time; maybe by dedicating a sprint or two to only bugfixes before a big new release, or by the software being EOL and having survived the heap-o-bugs. So you're in good company if your devs just let them ...


Only top voted, non community-wiki answers of a minimum length are eligible