Triage Project Update

Nino Novak nn.libo at kflog.org
Tue Sep 4 13:53:13 PDT 2012


Am 04.09.2012 21:52 schrieb Joel Madero:
> Basically it would be really nice to be able to group and assign bugs the
> way that the document does. I think bugs are much more manageable this way
> and we've seen a relative spike in QA triaging activity since starting the
> process this way.

Ok, I see: it makes the process a bit more transparent/obvious. And thus is more
pleasant and possibly "invites" more contributors.


 Not sure if you looked at the document but it's basically
> manual everything,

I looked at it but could not see what is so special with it...

I'll try to compare (please comment if you find this inadequate):


 I download FDO bugs to Calc, group them based on
> Component,

can be done by a bugzilla query

 then manually copy and paste into groupings of no more than 50.

(is this really that important? for crowdsourcing, it might suffice to do
coordination by e-mail)

> It would be incredibly nice to have the list updated automatically based on
> FDO, group the bugs based on component and then group each of those to a
> max of 50 bugs per group.

if it's a live query, it's current every time you run it

 If each group of 50 could then be assigned to a
> user it would be easy for members of QA to get involved with this project
> and get this back log taken care of.

Ok, I don't know how to build such chunks of 50 bugs using a query - but - is it
so important? Couldn't we use e.g. time periods (weeks or months) to group the
bugs? Then the number would not be constant but who cares?


 I'm not sure if this is possible or
> incredibly time consuming (if it is, probably not worth it).

I don't know either but wanted to understand what exactly is needed and if it's
possible to find (slightly) different solutions which can be implemented more
quickly (or are already existing but not thought of)


 It would be
> even better if we, as the QA team could do a custom "group" and then it
> could assign us bugs based on that. For instance, I'm a QA member and I
> want to do 20 bugs that are either Writer, Calc or Presentation, and I want
> the oldest bugs (in terms of those that have been left UNCONFIRMED for the
> longest period of time). It could then give me the list and allow me to
> assign myself to the group, and thus prevent other QA members from getting
> those bugs in their list when they do a custom search.

There is a QA Contact field which has not been used extensively (at least
according to my recent search). Could it be used for this purpose? (Rainer? Björn?)


> Sorry I felt like that was a bit of rambling, let me know if you need it
> clarified, I can hardly understand it myself ;)

So let me be a bit of a devil's advocate, aka clarification helper :-)

(I've been working in a project as QA helper years ago for several months, they
used excel sheets, so I think I understand the need to master the bugs, and to
make the processes transparent and obvious. And thus lower the entry barrier for
noobs, too btw.)

So my present guess would be:
- asking for a web tool is ok but - if there's no better tools ATM, let's stay
with google docs for the time coming
- but let's also try to use bugzilla itself as much as possible
- we have also the wiki, but I do not see much advantage of using it compared to
a google spreadsheet as it does not support storing/handling structured data.
But it's a web, so we can document all processes nicely and link the documents
in the wiki.

Regards,
Nino


More information about the LibreOffice mailing list