On Tue, 2009-06-02 at 08:28 -0800, Jeff Spaleta wrote:
On Mon, Jun 1, 2009 at 11:32 PM, Brennan Ashton
<bashton(a)brennanashton.com> wrote:
> There is much more information that can be pulled via a turbogrears
> app we are running. But I am looking to see what is useful in terms
> of a weekly report. I have the date tuesday to tuesday as it matches
> up with the Bugzappers meeting time.
Are you geared up for component by component reporting or perhaps
groups of components?
Yes, we can do this.
How do triagers currently organize their time
when picking components?
We have a page:
https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers
which lists what we consider the most important components (they're
basically the ones for which the most reports are filed). Triagers are
encouraged to specialize in one or a few of these components, in order
that they will have a good knowledge base for the issues they're
triaging and won't just be doing 'drive-by triaging' of bugs they don't
really understand.
Would component-by-component reporting help
spread/grow triage manpower into hot spot areas of the repository?
It could do, but on the other hand, we're mostly getting to the point
where the components that lack coverage are ones which need a triager
who's already knowledgeable about that component: we can't just
parachute someone in. (see e.g. anaconda and kernel).
And the flipside, can you visualize how triage manpower is actually
spread through the repository currently? Are our expert smoke jumpers
landing near the hotspots without a lot of coordinated effort? or is
triage being done mostly by maintainers, fighting the local fires in
their back yards?
I'll leave this one mostly to Brennan, but I think the position is that
we don't currently have a report that tracks this really well, but it
could be done.
And in the future I'd like to see weekly reporting feature by
feature
that gives a sense of progress on bugs loosely associated with a
feature proposal. Can we visualize the effect that feature specific
test days have on the bug lifecycle for that feature?
It may be hard to use this system to specifically track test day-related
bugs with any detail. James Laska and I are interested in doing better
statistical tracking of the impact of test days; I did some preliminary
stuff on this for the graphics test days for F11, we will try and do
this in a more organized way, for more test days, for F12.
Also reporting on tracking the aggregate progress on tracker/blocker
bugs for the next release. Can you highlight work or drive interest
in working on release target and blocker bugs in some way in the
reporting?
For the F12 cycle we should have the new severity assessment process in
place, so we should be able to generate some numbers which take the
severity rating of the bugs assigned by the Bugzappers team into
account.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net