Matthew Miller wrote:
On Wed, Jun 08, 2005 at 05:48:36PM -0400, Mike A. Harris wrote:
This would lend support to using "DEFERRED".
Anyway, thanks everyone for your comments. For right now, I'm going to
leave all the bugs in NEEDINFO state while I reflect on everything.
I disagree. DEFERRED == PROCRASTINATED_WITH_NO_ACTUAL_TARGET
Well, to be blunt, as not-@-redhat, that kinda feels like the honest thing
to be saying for a lot of these bugs.
I'm of the opinion that every single bug report that comes in,
should have an initial "triage" which consists of at least one
person reviewing the bug, updating the status to request more
information if necessary, and deciding wether to close the bug,
or to keep it open. If "keep it open" is the decision, then
the "next step" should be decided, and a target of some sort
given to the bug - either data based, or milestone based.
The goal of the target is not necessarily to "fix the bug" or
"solve the problem", but it can and often will be. Other
possibilities include merely "reviewing" the issue, or digging
into it deeper and performing another decision making step to
determine what is "next" in the life of the bug.
Right now, a lot of bugs are just left open forever with no
definite decision made, because it appears that there is no
solid decision that can be made, or because there aren't enough
hours in a day, or one of many other reasons which vary from
package to package, release to release, developer to developer,
and problem category to problem category.
Nonetheless, having concrete decisions of some kind helps to
keep the total list of issues cleaned up. A perpetually increasing
list of "things to do when we get around to it" just ends up being
a list of things that will never get done - ever. There might be
the odd exception here and there I'm sure, but the exception does
not make the rule of course.
It's better to make a solid decision which later turns out to be
a bad decision, than to be indecisive IMHO. Bad decisions cause
learning experiences, and often can be corrected later anyway,
which creates a better net result in the long run.
If something is going to be done, it should be left open, and
assigned to an active target tracking bug, such as FC4Target,
FC5Target, etc. and an explicit "goal" defined for that target.
This would clearly be *better*, but are there resources to do it? Or the
commitment?
Bugzilla bug handling is a per-developer thing. There are general
guidlines, but not really any strict policies adhered to across all
of engineering. I personally believe that it is an area that we
should focus on in the future, to strive for consistency, but I'm not
aware of any specific resources allotted to this at this point in time.
I have helped develop a methodology for our team (X Engineering),
which we've been using for a while now with good results, but this
is limited in scope right now to 4 developers.
Wether there are resources to do it, or commitment to do it would
be up to someone in higher level management, and only likely if the
problem was considered big enough to both make it on radar, and
also to not be buried under higher priority things that such
resources would be better spent on.
I don't know the answer to that however, which is why our team
developed our own guidelines rather than waiting for a larger
effort to form. Perhaps our methodology can be extended and used
by other groups. It's something to start with at least.
"DEFERRED" essentially amounts to "indefinitely procrastinated
with no goal or solid decision being made". Our team have
specifically been avoiding such indecision as much as possible
for the last 6 months or so, trying to make solid decisions
with each phase of a bug's life, to both reduce the active bug
list, and to reduce the lifespan of bugs to a minimum.
And if I remember right without doing a bunch of bugzilla searches right
now, there are few if any pre-FC3 xorg.org or xgl-maint@xxxxxxxxxxxxxxxxxxx
bugs in open or "limbo" states. And only a handful for FC3. So assuming
that's the team you're talking about, awesome job -- and it lends a lot of
credibility to what you're saying.
Correct. In the last 12 months roughly, I have personally went through
every single bug in bugzilla assigned to myself and/or xgl-maint, and
applied the new methodology to it, while also evolving the methodology
as was deemed necessary to solve problems that arose. The goals our
team decided were important were to work towards what we termed
"steady state", which roughly is described as:
1) Every bug filed in bugzilla, gets an initial triage/review by someone
within n days. The value of n initially would be a larger number,
with a goal of reducing n over time as processes refine. The initial
value of n was to aim for 7 days minimum initial response time, 21
day maximum response time. This is something that is still evolving.
2) Once a bug has been triaged, it immediately moves to another state.
If kept open, it must be moved to ASSIGNED or NEEDINFO as
appropriate. If closed, an appropriate comment is supplied for the
reason for closing/resolving the bug, and if the issue is fixed, an
indication of where it was fixed (ie: in Rawhide, errata, etc.)
3) If a bug is open, and has enough information supplied already that
no additional info is required from reporter, etc. - then it is put
into ASSIGNED state, and assigned to a target bug (ie: FC5Target)
Over time, lists of bugs are reviewed for processing. "NEW" bugs,
bugs in "NEEDINFO" for n days with no response, "UPSTREAM" flagged
bugs being tracked are reviewed every n days, and bugs not assigned
to a target are reviewed every so often to assign them to a target,
request more info, upstream them, or close them.
Additionally, locating bugs that are not Red Hat OS specific, and
having the reporter report them to the horse's mouth upstream project
is a goal for many classes of bugs, in particular bugs that are
hardware specific that we don't have the hardware for, or for things
like the "nv" driver or other issues that require hardware or
hardware knowledge that only upstream people have for a given area.
That cuts down on a LOT of issues, and also has proven to be a faster
way of seeing certain classes of bugs actually get fixed - once the
upstream folks responsible for an area of code are made aware there
is a problem.
Additionally, it was a goal to go through all bugs previously marked
as "DEFERRED", and pass them through this more solid decision making
process, either closing them outright, or moving them to an appropriate
state.
It took a long time, spread over about a year to get it to what it is
now, but we went from almost 600 open bugs, down to about 80 open bugs
now. It's much easier to see what the higher priority issues are, and
to get on top of things now, than it was wading through 600 bugs before.
;o)
There's still a lot of room for improvement, both to our process, and
to bugzilla itself, but the current method our team is using, works
pretty well within the existing confines. I aim to get the steady-state
bug count down below 50 by the time FC4 sails.
Hope this is useful info. ;)
