Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.