New subject: [Maria-developers] Process suggestion for minor issues

14 Jun 2013

      (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

Re: [Maria-developers] Process suggestion for minor issues

Elena Stepanova

James Briggs

tags

participants (2)