[Libreoffice-qa] minutes of the LibreOffice QA call 2012-03-23 15:00UTC
oolst at nouenoff.nl
Tue Mar 27 00:43:21 PDT 2012
Hi Bjoern, all,
Thanks for taking minutes Bjoern :-)
Additions from me on few points.
Bjoern Michaelsen wrote (25-03-12 00:34)
> * pending action items
> - collect further ideas for spending a dedicated resource (Cor/Rainer)
Cor & Rainer propose to look at extending possibilities for querying
commenters in bugZilla.
> - automated test docs: really straightforward for Calc, just needs more
> CSV test documents (all)
I thought that related to this we talked about contacting experts in the
community in e.g. the area of charts.
> * structured manual testing: (Yifan, Rimas, Bjoern)
> - Litmus proposal at:
My take on this:
- Oour QA people already are very active plus having enough area's in
mind, that they would love to spend extra time on.
So posting extra lists of interesting areas to the QA team or asking
their attention in other way's, will not help that much for now.
- Apart from that, there is the risk of pseudo certainty when extra
attention is given to clear work-areas/features mentioned by devs/read
from the commit logs. Since work is ongoing in so many areas, that
possibly have influence all over the product.
- What does make sense, is having indeed a list of areas that can be
clearly pointed at, and to mention them in a sort of standard post on
our official TDF blog. E.g. every two weeks 4 to 8 items and guiding
users interested to test in these area's to the daily builds.
Thus we make use of the idea and information, and help growing the QA
team, which IMNSHO is the most important issue now.
This is in the minutes:
> (If we greenlight that, it spawns a lot of action items ;) )
> - essentially means devs drop oneliners with affected area for commits
> along with review requests to the list (Bjoern)
> - Devs are already overcommited with their current tasks (Petr)
> - QA even more so given their current resources (Cor)
> - whatever form of communication/workflow we set up, we should trying it
> on the release branch first, becaus of commit volume (Bjoern)
> - this info really should be in the commit messages (Petr/Kendy?)
> - otherwise we should make it a custom for devs to CC the QA-list as we
> do with ux-advise, which works reasonably well (Petr)
> AA - propose proactive QA-list CCing on ESC (Bjoern)
> - as long as Litmus is not easily accessable this is pretty much in vain
> - alternative: Wiki or Blog instead of Litmus?
> - Blog, not Wiki (broader audiences) (Kendy?)
> AA - Blog regularly about affected areas with call for testing (Cor/Bjoern?)
So I would suggest the action items:
AA - propagate clear commit messages to recognise features/
functional area's (Petr)
(I suggested t
AA - Blog regularly about these areas with call for testing
(Of course this only is going to work when there are clear
items to mention)
The also mentioned action items for CC-ing QA list by devs is important
too, IMO, but will have effect more in the bit distant future.
> * community building/communication (Cor)
I outlined my ideas on this before. See the last part of this mail:
In that area, the next AA is related:
> AA - kindly ask them to introduce themselves on the QA-list or even blog
> about (both developer interview style) (Cor/Bjoern)
More information about the Libreoffice-qa