3 ms·

To be fair, he said to do exactly what you said: cut the backlog off at X weeks. For something new to come in, something else has to go. It was the bug db he r

To be fair, he said to do exactly what you said: cut the backlog off at X weeks. For something new to come in, something else has to go. It was the bug db he recommended clearing out, which I kind of agree with. Little is more disheartening to a developer than seeing a project with 3000 bugs. You can't help think your project sucks, so why bother (or you learn to completely ignore the bug db). Regardless, your last statement of "don't be cargo-cultish" always applies. Understand the tradeoffs for your organization. Even Joel just called them "suggestions" not "here's how you do it".

keithpeter 14y ago
"Little is more disheartening to a developer than seeing a project with 3000 bugs." Try 100,000 I was slightly active as a tester for Ubuntu 12.04 (a long term release so things that did not make the UI and package freeze would be there for years) I noticed a lot of minor bugs being labelled 'won't fix', and I noticed a lot of 'down chain' bugs happening because of kernel/X server &c which automatically got sorted once the fixed packages made it in. The whole thing was most educational to me (as an end user) and the result is rather nice.
- SoftwareMaven 14y ago
  That would be an interesting experiment. 100,000 bugs, the vast majority of which you have no control over; 3,000 bugs, the vast majority of which you have control over but aren't going to do anything about; or 100 bugs that you know you are going to quash. I can see how the first two could be quite painful for developers, but they are also helpful for support reasons. "Yes, that annoying menu things has been reported and we just aren't going to get around to fixing it," seems better than a bug black hole that continually swallows everything customers/support tells it.
  - keithpeter 14y ago
    launchpad does that triage, they have people processing stuff most days. It was educational watching how the various freezes along the time line funnelled the bugs that would get fixed. This is an extreme example, a whole operating system with non-trivial packaging. Your phone app should be easier! pyroom have a suggestions tracker... the thing is meant to be minimal!
- infinii 14y ago
  The biggest reason against removing such "won't fix" bugs from a bug db is that it's kept for historical reasons. If a user reports it again, a search of the bug db will indicate that an investigation has been performed and the bug isn't worthy of being fixed. If it'd been deleted, support would waste time duplicating the investigation again.
  - warp 14y ago
    This is about open bugs. Closed bugs are easy to ignore. Ubuntu has 98614 open bugs: https://launchpad.net/ubuntu/+bugs https://launchpad.net/ubuntu/+bugs (Though I expect that would also include feature requests / wishlist items, so the actual bug count would be slightly lower).

keithpeter 14y ago

"Little is more disheartening to a developer than seeing a project with 3000 bugs." Try 100,000 I was slightly active as a tester for Ubuntu 12.04 (a long term release so things that did not make the UI and package freeze would be there for years) I noticed a lot of minor bugs being labelled 'won't fix', and I noticed a lot of 'down chain' bugs happening because of kernel/X server &c which automatically got sorted once the fixed packages made it in. The whole thing was most educational to me (as an end user) and the result is rather nice.

SoftwareMaven 14y ago
That would be an interesting experiment. 100,000 bugs, the vast majority of which you have no control over; 3,000 bugs, the vast majority of which you have control over but aren't going to do anything about; or 100 bugs that you know you are going to quash. I can see how the first two could be quite painful for developers, but they are also helpful for support reasons. "Yes, that annoying menu things has been reported and we just aren't going to get around to fixing it," seems better than a bug black hole that continually swallows everything customers/support tells it.
- keithpeter 14y ago
  launchpad does that triage, they have people processing stuff most days. It was educational watching how the various freezes along the time line funnelled the bugs that would get fixed. This is an extreme example, a whole operating system with non-trivial packaging. Your phone app should be easier! pyroom have a suggestions tracker... the thing is meant to be minimal!
infinii 14y ago
The biggest reason against removing such "won't fix" bugs from a bug db is that it's kept for historical reasons. If a user reports it again, a search of the bug db will indicate that an investigation has been performed and the bug isn't worthy of being fixed. If it'd been deleted, support would waste time duplicating the investigation again.
- warp 14y ago
  This is about open bugs. Closed bugs are easy to ignore. Ubuntu has 98614 open bugs: https://launchpad.net/ubuntu/+bugs https://launchpad.net/ubuntu/+bugs (Though I expect that would also include feature requests / wishlist items, so the actual bug count would be slightly lower).