Date: prev next · Thread: first prev next last

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)


 - Cor

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.