minutes of the LibreOffice QA call 2012-03-23 15:00UTC

Hi all,

here are the minutes of the qa call on 2012-03-23 15:00 UTC:

attendants: Cor, Rainer, Markus, Petr, Kendy, Bjoern

* pending action items
  - Check if test documents are URLs properly distributed to Checkbox (Bjoern)
  - Update/Create active triagers wiki page (Cor/Rainer)
  - Publish Rainers charts'n data on blog/planets (Cor)
  - collect further ideas for spending a dedicated resource (Cor/Rainer)
    -> blocked: to get a concise list need to make a CaseConductor/Litmus
                choice
  - Set Cor up with the Community/Forum maintainers at the distros
    to better propagate Hackfests, Bug Hunting Sessions etc.
    (Petr, Caolan, others?)
  - Walkthrough setup at Hackfest to find out what need better docs
    (Bjoern/Rainer)
  - Setting up a ready-to-go VirtualBox with everything installed would be
    cool (Bjoern/Korrawit?)
    https://bugs.freedesktop.org/show_bug.cgi?id=47648
  - automated test docs: really straightforward for Calc, just needs more
    CSV test documents (all)
    https://bugs.freedesktop.org/show_bug.cgi?id=47667

* completed action items
  - copypaste existing manual tests a one off for 3.5/Precise
    -> done by Nicholas Skaggs and Kaldor from the Ubuntu community. Kudos!
  - Provide Cor with suitable queries as possible with current means (Rainer)
  - Create some QA EasyHacks (Bjoern)
    http://sweetshark.livejournal.com/9491.html
  - Set Cor up with the Community/Forum maintainers at the distros
    to better propagate Hackfests, Bug Hunting Sessions etc.
    (Bjoern)

* structured manual testing: (Yifan, Rimas, Bjoern)
   - Litmus to Checkbox done for 3.5 (Nicholas Skaggs)
   - we should also tap into the l10n testers, it might be worthwhile to get
     them into not only testing l10n but also functionality along the way (Cor)
   - OpenID for Litmus would be awesome
   - ... but Litmus EOL at Mozilla, however CaseConductor (the replacement)
     might not suit our needs/be an overkill
AA - needs serious investigation if CaseConductor suits us or if its
     awesome for Mozilla but not for our usecase (Pedro)
   - Litmus proposal at:
     http://nabble.documentfoundation.org/Libreoffice-qa-Litmus-a-proposal-td3845560.html
     (If we greenlight that, it spawns a lot of action items :wink: )
     - 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?)

* bugwrangling (Rainer)
   - we are missing queries counting comments and not only reports (Cor)
     -> possible task
   - OpenID for bugzilla would be awesome
   - 3.4.6 release testing
     - few reports, but focus likely shifted to 3.5 (Rainer)
AA - provide Cor with dl numbers so we can confirm this (Petr)
   - 3.5 status
     - good progress (Rainer)
     - more windows build would be good (Rainer)
     - new Prague tinderbox should solve that (Kendy?)
   - release plan discussion redux
     - skipped, conclusion on list discussion suggested to be no urgent need
       for "fixing"

* community building/communication (Cor)
   - https://wiki.documentfoundation.org/QA/Easy_Hacks
   - some critic about the blunt invitation to join QA on the BSA (Rainer)
     - the QA wiki page not a good entry point (Rainer)
       (no concrete actionable tasks there)
     - we need competent QA, not just anyone (Rainer)
     - we should work on two levels, with different approaches: (Bjoern)
       - newcomers
       - good current contributors on bugzilla
     - maybe concentrate on exactly _one_ easy to communicate task for
       starters as landing page after BSA: bug confirmation (Bjoern)
AA - create a newbie-friendly wiki-page just about bug confirmation (Rainer)
   - good current contributors should be motivated/encouraged
AA - kindly ask them to introduce themselves on the QA-list or even blog
       about (both developer interview style) (Cor/Bjoern)
AA - link to ask.libreoffice.org from get-help on the frontpage

* automated calc testing (Markus)
AA - provide some examples what scope a 'feature' is to get people an idea
     https://bugs.freedesktop.org/show_bug.cgi?id=47667 (Markus)
AA - invite a broad audience (and endusers) to provide testdocs there (all)

* bibisect for 3.5 (Caolan hinted at that)
   - postponed to the next call

* next call: will be at 1400UTC (one hour earlier because of summertime)
   2012-04-06 1400UTC

Accompanying IRC channel for the calls is #libreoffice on freenode.

Because of some interfering tasks I couldnt write down the minutes right after
the call, thus all additions and corrections are most welcome.

Hi Bjoern, all,

Thanks for taking minutes Bjoern :slight_smile:

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)
     https://bugs.freedesktop.org/show_bug.cgi?id=47667

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:
      http://nabble.documentfoundation.org/Libreoffice-qa-Litmus-a-proposal-td3845560.html

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 :wink: )
      - 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
          (Cor/Bjoern?)
          (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:
http://lists.freedesktop.org/archives/libreoffice-qa/2012-March/001345.html
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)

Cheers,