[opensuse-project] Re: Improving the bug management lifecycle/process
Forwarding the message I'd accidentally sent off-list. Hopefully it will
stay embedded in the correct thread.
In the light of what Jim says here - and others have said about the process,
too - perhaps it could be worthwhile to look at integrating FATE and
Bugzilla, but only if it doesn't come at the cost of becoming too complex to
manage.
The issue with the vast number of products making Bugzilla almost
unmanageable is an interesting - and worrying - point, and even from the
user experience of having to navigate the selection options on the front
page, it's daunting. Would it be possible to have a discrete instance of
Bugzilla purely for openSUSE/SUSE maintained separately to all the other
products?
How did the system cope when we had Bug Squashing Days?
cheers
Helen
---------- Forwarded message ----------
From: Jim Henderson
It may be more prudent to first talk about the tool itself. There's been talk from time to time by people wanting to see FATE and Bugzilla functionality merged because its too confusing going to two different places and not clear to some people the distinction between the two tools.
Hmm. I think they seem very different - one is ideas and the overall vision, the other with fixing breakages, really. Maybe it's a simple matter of putting some messaging on the gateway pages to help people identify which they want.
They can be pretty different, but I've seen implementations of Bugzilla that use it for both bugs and enhancements - and there is some benefit to doing that. For example, if someone submits something they think is a bug but is in fact a request for new functionality (which I see happen a bit in general - they think a program should have some functionality and that it doesn't is a 'bug' in their mind, even though it's new functionality), it's easy enough to recategorize it in Bugzilla. I think two systems puts us in the position of telling someone who's misclassified a feature request as a bug that they need to take it to another system, and we should try to reduce having to redirect people to a different system. Something that's integrated is going to be a bit clearer in terms of managing expectations. At the same time, Bugzilla isn't really geared towards tracking enhancements specifically, and there are some shortcomings in that area. The question in that regard is whether or not those shortcomings are show stoppers, or if even with them it would be "good enough".
I think it's a good idea to keep it very focused at this point: fixing the Bugzilla workflow. Much more likely to create results, rather than discussion!
Yes, I agree. :)
The numbers seem very manageable to me - a hundred, even a few hundred - that's human-auditable. I'd been thinking along the lines of scanning submissions for keywords, but for this kind of volume human eyeballs are probably better.
Yes, I think so as well. There is a tendency, especially amongst non-technical reporters, to misclassify bugs (due to the nature of them not knowing exactly how best to classify a bug).
Just having an initial browse of Bugzilla: not the most inviting of search interfaces! Fortunately the opensuse.org Bugzilla conveniently links to the submission-step-1 page with the 'hot 100' and 'two weeks' search options. A lot of contemporary computer users won't do an exploratory click to find out what they can find out: they have to be told stuff (in bold letters) and guided through by the hand. Is redesigning the user interface an option?
Probably not on bugzilla.novell.com, but maybe there's something we can do to "front end" it. Someone would have to do some research to see if that's possible. It might be possible to add a simple query form, but even then for the non-technical, if they're not sure how to classify a bug properly, they may not know how to identify a bug that's similar enough to theirs. Ultimately, the goal here would be to reduce the work for de-duping bugs rather than to eliminate the need to do that completely (that would be an unattainable goal, I think).
In the first instance I'm noticing some time being spent in marking duplicates, I suspect language might be an issue for some - a non technical user might not recognize a bug filed by someone who is expressing it in more specific terms - eg 'my printer won't work' versus 'cups-driver....'
Yep. (See above).
Also noting some problems in trying to replicate an issue. I'm wondering, with tricky issues, if there's some way to use virtualization and information from the user's installation to facilitate replication. How often is replication a problem? Is it always necessary?
Intermittent issues can be much more difficult to dupe (that's been part of the issue with solving the forums' issues the past several months). Duplication helps in diagnosis and /can/ shift information gathering to the person fixing the bug rather than having to go back to the original reporter(s) and having them try things. It depends on a lot on the complexity of the bug, though - something like a difference between signed and unsigned might be relatively easy to track down. A kernel bug that manifests itself with specific hardware (esp. hardware the dev doesn't have access to) becomes much more involved and complex.
What have the people who are hands-on fixing these bugs stated about the process? What really drives them nuts? What I'm seeing from my POV might be very different to their experience.
These are good questions and we definitely will need to ask the devs what their pain points are in order to try to resolve (or reduce) them.
Regarding the earlier observation about Novell's bugzilla being stretched thin: would you care to elaborate?
So I spent 8 years working for Novell in the training department, and a couple of the things I was involved in were initiatives to track issues with training courseware and the performance-based testing (the hands-on exams for CLP/CLE), so I spent some time working with the people who managed bugzilla. I also have years of experience in the Novell forums and have had access to large pieces of internal bug tracking as a consequence of that. The bugzilla permissions system (for example) is relatively simplistic, so adding a new group to grant permissions to non-public bugs is a pretty massive undertaking because Bugzilla was created really to have things open rather than hidden. As I recall, the number of products and components listed is testing the limits of what Bugzilla can handle. I've seen times with the full product list where you select a product and the list of components (which builds dynamically) seems to take ages to populate because of the amount of data involved. I think they've migrated to beefier hardware, but the limits are still really being tested, and to my knowledge, no other organization has an implementation of Bugzilla on this scale in terms of product/component count. I remember talking with the guy who used to run it (I don't think he's there any more) and even trying to get minor customizations in order to meet my needs (for example, being able to automatically create some components for a consistently-created type of product - training material - so we wouldn't have to manually create components for the course guide, labs, and workbook) was something they didn't have the bandwidth for. As far as I know, the number of people to work on those types of requests has been reduced rather than increased, so any customization we'd want would be, I think, unlikely (but I'd be happy to be proven wrong). Jim -- IRC: helen_au helen.south@opensuse.org helensouth.com -- IRC: helen_au helen.south@opensuse.org helensouth.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
participants (1)
-
Helen South