Triage Project Update

[Joel Madero]

I agree that FDO has some benefits but the limitation is really that 
each user is needed to query every time,  the possibility of overlap is 
great, and no one is really responsible for an individual bug until the 
query is made and someone takes the time to look into it. I'm not sure 
if others would agree but it seems like having a "group" of 50 or so and 
being able to just do those at your convenience makes people more likely 
to help and feel like their is an end in sight for "their portion". This 
is vs. just seeing a never ending list from FDO or even having to 
"teach" new users (or even not new users) exactly what to search for 
every time with FDO.

Similar to how developers assign themselves bugs and then can just go 
look at their own bugs ("My Bugs") it would be nice to have this ability 
for QA triagers but have it somewhat automated since it's just triaging, 
not programming. In the long run (once we're through the back log of 
650+ that are really old), it would be amazing if we had a team of QA 
staff that signed up to have bugs "auto assigned" to them for triaging. 
What I imagine:

QA triagers "sign up" for components they are willing to triage and 
their "max" load
New bug is reported, if the bug has a component listed the bug gets 
"auto assigned" for triaging purposes according to some rule(s)

For now the google docs works, FDO does not as it is now but I'll 
discuss this further with Bjoern, Petr & Rainer to see if we can come up 
with something more functional than the chaos that is FDO :) Or maybe 
I'm just not familiar enough with FDO to really feel comfortable myself 
with it, this is more likely than not true :)



Best Regards,
Joel





On 09/04/2012 01:53 PM, Nino Novak wrote:
> 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