[Bugsquad] New bugsquad fields/flags/features [Was: Re: Triaging-Bot in #kde-bugs? [FiNeX-Analysis]]

Michael Leupold lemma at confuego.org
Wed Aug 20 22:00:09 CEST 2008


Hey everyone,

after FiNeX pointed my nose directly at it I'd like to get back to some of the 
stuff we already discussed a while back. Now that the new bugzilla is in place 
and it has the sysadmins' attention at the same time we are free to make 
wishes to mold it to our needs.

On Thursday 19 June 2008, FiNeX wrote:
> * Better analyzed problem *
> Triagers needs to bring a sub-set of bugs which will be tested and
> confirmed/closed/... Triagers could already do this working directly in
> bugzilla, but there is the need of a coordination point.
> Actually the wiki page list the sets of bugs. It show the triaged bugs
> divided by type. Also each bug can be marked as closed on the wiki (but you
> have to do this to b.k.o too).

As far as I understand it we'll still need a central point to grab "buckets" 
of fresh bugs to triage. But by enriching bko with new fields and flags we 
should be able to get rid of the wiki page for most of the other things. With 
the xmlrpc features and a new website we might even be able to semi-
automatically create bugzilla queries by some php and make people grab their 
workload from there.

Currently our main problem is that editing the wiki page is a chore and we 
basically don't do more than duplicate the information we already put on bko 
(plus some categorization). We should be able to do most of it with bugzilla 
only.

Here's what we might do:
- Picking a working set (from wiki page/custom webpage)
- For each bug you handle:
* Set a "bugday" date-field to the current bugday (marking it as handled 
during that bugday - good for querying for leftover stuff)
* Set patch / step-by-step / backtrace / testcase flags as appropriate
* Set NEEDSINFO bug state (already in) if you need more information from the 
reporter
* set a special bugsquad flag to categorize this bug like on the wiki page 
(INVALID, DUPLICATE, ...). This also tells other people in bugsquad these bugs 
need a second pair of eyes to look over.

Well, this might still be a little vague, but what do you think of a workflow 
like that? I think we could probably do almost all we can right now with the 
wiki.

(FiNeX wrote some things quite similar to what I did. I just didn't bother to 
pick everything for proper quoting :-D)

> It could be more interesting if triaging could be managed directly into
> b.k.o. Actually bugs can be assigned to an user.
> The structure could be exteded to allow bugs be assigned even to a triager
> and it could be added a field like [ triaged | not triaged ] (only when a
> triager is assigned).
> Doing that will allow to assign a sub-set of bugs to a triager.
> In this way each triager can filter only his assigned bugs and check only
> bugs which are not yet triaged.
> This will force triagers to give a feedback directly on the bug report
> instead of writing on two places (wiki + b.k.o, or IRCbot + b.k.o).

This might be a good idea too. Having a "bugsquad assignee" who will take care 
of the bug in case anything happens. Basically like a specially flagged CC.

> This could allow to use an improved version of kbugbuster that, at this
> point, will continue to follow his purpose: being a frontend to bugzilla.

Having that as a goal would be something really really nice. Maybe that 
deskzilla application is worth looking at. I'll try it out soon-ish. Of course 
having some page for easing some of the harder queries would be a nice thing 
as well.

Regards,
Michael


More information about the Bugsquad mailing list