(warning: it's a long one) Hi Sergei, On 6/14/2013 6:26 PM, Sergei Golubchik wrote:
Hi, Elena!
On Jun 14, Elena Stepanova wrote:
On 6/14/2013 2:27 PM, Rasmus Johansson wrote:
Here is a suggested process to handle the ever growing amount of minors. If a minor issue isn't fixed after two consecutive releases it's re-reviewed and either priority changed to major (or higher), or the minor issue is closed with resolution Won't Fix and a comment. Example of comment can be that "this is an edge case where effort and benefits doesn't correlate".
I don't think the algorithm is quite fair. It means that if a really minor bug happens to be found during a relatively slow period, it gets fixed, but another bug, even considerably more important (but still falling into "not major => minor" category), can be by this time closed as "not worth fixing" just because people had been busy with some other stuff and couldn't fix it over two previous releases; while logically, if somebody suddenly has time to fix a minor bug, the latter should be fixed first.
This algorithm has a "re-reviewed and either priority changed to major..." step, so it's not just the timing. Not like automatic closing of old bugs.
Yes, I got that part; but it doesn't change the potential faulty result. Lets say we have imaginary priorities 1-5 which are all "minor", 1 being the lowest. For a while you had had a bug of "priority 4". After 2 releases the reviewing force reviewed it, decided it was minor (rightly so), and closed it. A few days later you got a bug of "priority 1". A few more days later you suddenly have time to fix a bug -- you are stuck at your main task and need a distraction, or you've got a headache and can't work on anything serious, or you only have half an hour before you need to go pick up kids... whatever. Naturally, you go to the list of your open bugs, take a quick look and pick whatever fits. If you still had the bug of priority 4, you'd fix it now, but instead you fix the bug of priority 1. I don't know about others, but I do keep a bunch of open low-priority tasks, and while rarely, sometimes it happens that I can do something about a minor one. And then I look at them and pick by importance and "suitability for the moment", not by the creation time.
I'm fine with closing bugs as "Won't Fix", but imho it should be based on the merits of the bug itself, not on the bad timing of its creation. Since all our developers are very senior and can totally make such a decision on their own, I suppose anyone who a bug is assigned to can take a look at it and either close it as "Won't fix" with a proper explanation, regardless the timing (even right after receiving it), or keep it open.
The main issue I didn't like - what that algorithm is making an attempt of solving - is a growing pile of minor bugs that we aren't going to fix.
I agree, there is no point at keeping those that we are really not going to fix. But I don't see anything critically bad at preserving those that we *want* to fix, just currently don't have time to -- as long as we don't schedule them for the closest release, thus lying to users and to ourselves (more on that later). I also think it's two essentially different categories. Later here you are saying that "a closed bug can always be reopened later and fixed". If we put the "don't have resources to fix" bugs into the same trash bin as we currently use for "really won't fix" bugs, re-opening will never happen. Who will go through the whole bunch of "Won't fix" bugs, review them *again* and see if they are really not worth fixing, or if we had to close them because we didn't have resources? Certainly you can't do it when you just have little time to fix one-two small bugs, you'll spend more time searching.
A bug is real, so it's difficult to say "won't fix", it's much easier, psychologically, to say, "okay, I'll fix it, *when I have time*". But really, for minor bugs this might never happen.
But sooner or later somebody who's reviewing them will dare close it anyway?.. Okay, I agree that psychologically it is easier to reject a bug *together with somebody* than make such a decision on your own, group mentality and all that, I get it and have it myself; so if it's all about having some kind of committee for closing such bugs, let it be. (I don't really know who could this committee consist of. Generally, I'm a big supporter of a triage team, it makes the process less personal. But in a company where everyone is pretty much unique in his area, it's a bit strange, because at the end only the expert can bring in an educated verdict -- and this would normally be the person the bug is already assigned to anyway; others will just be there to hold his hand.)
And de-facto this leads to wrong expectations (users believe the bug will be fixed in a specific version, but it isn't) and us lying to our users.
True, but I think the new approach will mess up more than it will fix. Now we have Fix version evolution like that: 5.5.30 => 5.5.31 => 5.5.32 => 5.5.33 => .... It's bad. I still think that we shouldn't schedule minor bugs for any particular version. We've discussed it before, and yes, I know that we do it to keep them on somebody's radar, but I would think that having it assigned to somebody should be enough, since it's already on a radar of the person who it's assigned to. But maybe I'm wrong and nobody looks at lists of bugs assigned to them -- shouldn't we try to change it instead, then? But with the new system, we will have 5.5.30 => 5.5.31 => "Won't fix, it isn't worth it". If I were a user, now I'd be mad. If it isn't worth fixing, why didn't you say so right away? Why schedule it and even move it to the next release then? That's even more of lying to users than we currently do, and in a more irritating way.
My idea is to be honest about it, and if we don't have resources to fix a specific bug, we won't drag it forever from one release to another, but close it eventually.
I agree. But I think we shouldn't even start dragging it then. If you are going to have a committee which would regularly review bugs (those that have waited for 2 releases) and decide if they're worth fixing or not, why not do it right away -- let the same committee decide it for *new* bugs instead, so that unimportant ones don't even get scheduled and go to the trash bin immediately. It will spare users wrong expectations.
And yes, I hate closing non-fixed bugs too.
If you can suggest another solution, please do. But "keep it open" doesn't work, as we've seen already.
Well, I'd suggest to consider adjusting yours a little, in the following way: - define who will be reviewing the bugs; - those person(s) will screen new bugs instead of those that have waited for 2 releases; - , set "Won't fix" when we really mean it (example: PBXT bugs, etc.), and create a new resolution "Don't have time to fix" or "Wishlist" or whatever, and put corresponding bugs there, while keeping them assigned. The last point is to preserve at least hypothetical possibility for the bugs to be re-opened later. So, if somebody has time to fix a minor bug, first he looks at the list of his open bugs (we already know that the committee kept only most worthy ones there). If nothing fits the moment, or (a miracle!) the list is empty, the somebody goes to the "wishlist" bugs assigned to him, and picks from there. At the same time, those bugs aren't shown as open, aren't scheduled for any particular release, the users aren't misled, etc. A couple more notes: - I think external bugs should generally have higher priority than otherwise equal ones found internally; - a different approach might be needed for bugs in new feature trees, it should be decided separately (the basic question is -- when we consider the feature good enough to be pushed to the main tree, whether it requires fixing minor bugs or not). /E
Besides, a closed bug can always be reopened later and fixed.
Regards, Sergei