15:00:18 <x1sc0> #startmeeting
15:00:18 <IZBot> Meeting started Tue Mar 27 15:00:18 2018 UTC.  The chair is x1sc0. Plugin info at http://wiki.debian.org/MeetBot.
15:00:18 <IZBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:28 <x1sc0> so let's get started
15:00:36 <x1sc0> anyone here for the QA meeting?
15:00:48 <buovjaga> yeah, someone is here
15:00:48 <x1sc0> #topic rollcall
15:01:05 * bearon rolls
15:01:33 * deneb_alpha rolls :)
15:01:54 <x1sc0> nice
15:02:24 <x1sc0> let wait a couple of minutes to see if someone else shows up...
15:02:39 <buovjaga> Roll Over Beethoven
15:03:24 <x1sc0> buovjaga, bearon deneb_alpha is there anything you would like to discuss from your side? from mine I have a topic
15:03:50 <deneb_alpha> x1sc0, not ATM
15:04:01 <buovjaga> I dunno, maybe just a mention that I published this article: https://pointieststick.wordpress.com/2018/03/21/guest-post-the-importance-of-qa/
15:04:25 <deneb_alpha> nice one BTW buovjaga :)
15:04:38 <x1sc0> #info buovjaga published a nice blogpost about QA: https://pointieststick.wordpress.com/2018/03/21/guest-post-the-importance-of-qa/
15:04:54 <buovjaga> while giving it visibility, I once again noticed, that users do not understand our basic jargon: we should not say "QA", we should not even say "quality assurance". We should say "bug testing" and for triaging we should say "bug analysis"
15:05:23 <bearon> that's a very good point, actually
15:05:29 <x1sc0> yep, indeed
15:05:34 <bearon> triaging is a very obscure word
15:05:40 <buovjaga> yep, that is kind of an invisible-to-us point, but might be important
15:05:41 <x1sc0> true
15:05:55 <buovjaga> I've had people react to "triage": WTF?
15:06:11 <bearon> can we consider revising our terminology in the future accordingly?
15:06:13 <buovjaga> and one person commented to another "thanks for letting us know what QA stands for"
15:06:17 <x1sc0> I think I'll change the welcoming emails I send accordingly
15:06:27 <deneb_alpha> buovjaga, but sometimes also the word "bug" is difficult to understand and has a negative impact on final users
15:06:34 <buovjaga> I think we could consider 1) users we want to recruit 2) veterans or existing contributors
15:06:44 <bearon> let's rename bug to feature :)
15:06:48 <buovjaga> so we use words according to context
15:07:16 <buovjaga> for "baby's first qa" stuff we use the simple words while explaining the Correct Jargon (because it is used in professional settings, after all)
15:07:17 <x1sc0> #topic QA wording
15:08:04 <x1sc0> yep, most of the welcoming emails I send are sent to end users, so better to reword it
15:08:24 <x1sc0> but... should the wiki be rewording as well ?
15:08:35 <buovjaga> x1sc0: maybe only for intro articles
15:08:42 <deneb_alpha> buovjaga, +1
15:08:43 <x1sc0> or at least the getinvolved page ?
15:08:52 <buovjaga> or having a small explanation in the QA index page, what the heck is this all about
15:09:00 <buovjaga> or == and :)
15:09:05 <bearon> deneb_alpha: do you have any thoughts on what could be a less negative term for bug?
15:09:29 <buovjaga> code problem? :)
15:09:34 <buovjaga> "issue"?
15:09:46 <deneb_alpha> bearon,  bug is connected to "we have issues" "the software doesn't work"
15:09:59 <buovjaga> we do use issue pretty regularly - yeah, but we have to be realistic when we recruit :)
15:10:02 <x1sc0> we can add a table of synonyms to the page
15:10:29 <x1sc0> buovjaga, issue sounds better to me than code problem
15:10:30 <bearon> deneb_alpha: ah, so by negative you mean hard to understand, not that the word is negative, go tit
15:10:34 <bearon> *got it
15:10:39 <deneb_alpha> we know that a software without bugs doesn't exist but for a final user could sound different
15:10:54 <deneb_alpha> bearon, I mean exaclty that the word is negative
15:11:27 <x1sc0> deneb_alpha, so 'issue' sound better ?
15:12:03 <deneb_alpha> x1sc0, probably quality in general is better
15:12:16 <deneb_alpha> quality testing, quality analysis etc
15:12:35 <x1sc0> probably it would be good to tweak https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&format=guided as well
15:12:37 <deneb_alpha> sounds more positive than bug or issue
15:12:55 <buovjaga> but we cannot use "quality" in a quantitative way, meaning how much we get issues and how many people we need
15:14:08 <x1sc0> yep, we can't see find unconfirmed qualities instead of find unconfirmed bugs -> https://wiki.documentfoundation.org/QA/GetInvolved#Find_unconfirmed_bugs
15:14:09 <deneb_alpha> I got your point buovjaga but we need to bring a little bit of marketing also here in this tech area ;)
15:14:24 <buovjaga> it is true that we can optimise wording in a more marketing-oriented way, but it is hard to get around some words :)
15:15:12 <buovjaga> there is a difference between "please help us we are drowning in bugs" vs. "you can work with us to make LibO shine"
15:15:31 <deneb_alpha> x1sc0, in that context probably is correct to use the term issue
15:15:40 <buovjaga> maybe just optimise the tone as far as possible and see how is feels?
15:16:15 <buovjaga> the marketing point is a good one as well
15:16:22 <deneb_alpha> buovjaga, the second one ("you can work with us to make LibO shine") shold be the preferred way to interact with new members
15:16:41 <buovjaga> yeah, sometimes I get desperate and want to shout in the streets :P
15:16:53 <buovjaga> "please take these bugs from my hands!!"
15:17:10 <x1sc0> I think for now we can replace 'Quality Assurance', 'bug' and 'triage' in some places, I think we all agree on that...
15:17:20 <deneb_alpha> x1sc0, +1
15:18:07 <buovjaga> yep, and we can recruit some skilled writers from doc team to make our intro texts more appealing etc.
15:18:55 <x1sc0> yep, I can also contact mike saunders to see if he can give us a hand with that
15:19:17 <x1sc0> to put some marketing point of view in the get involved page
15:19:29 <deneb_alpha> good idea :)
15:20:09 <x1sc0> buovjaga, Do you think a blogpost like yours in our blog would make sense? something like QA for dummies...
15:20:53 <buovjaga> x1sc0: perhaps :)
15:21:54 <x1sc0> #todo: x1sc0: replace 'Quality Assurance', 'bug' and 'triage' in some places
15:22:18 <bearon> please join our insect dissecting team :D
15:22:39 <buovjaga> insect eating popularity is growing in Finland, so I should try recruiting locals
15:22:51 <x1sc0> #idea: write a blogpost about QA for end users ???
15:23:22 <x1sc0> #link https://pointieststick.wordpress.com/2018/03/21/guest-post-the-importance-of-qa/
15:23:45 <x1sc0> we should consider making some videos...
15:24:18 <x1sc0> how to report a bug... how to bisect and issue...
15:24:49 <buovjaga> sure, I've kind of been waiting for Bugzilla 6 on those vids :)
15:24:59 <buovjaga> as the UI will change dramatically
15:25:14 <buovjaga> but we could write the scripts already to some extent
15:25:29 <x1sc0> maybe it's better to create one video now and update it once Bugzilla 6 is out
15:25:34 <x1sc0> it might take some time
15:26:03 <buovjaga> August
15:26:14 <buovjaga> one video now and the rest later
15:26:46 <x1sc0> #topic make videos about different QA topics ( report and issue, bibisect... )
15:26:49 <buovjaga> anyway, if you're going to do a vid, write a script beforehand - much better than live narration (of course you can narrate the audio afterwards)
15:26:54 <IZBot> News from tdfnew: [Bug 116662] [GTK3] Buttons have blank backgrounds, dropdowns have no arrow <https://bugs.documentfoundation.org/show_bug.cgi?id=116662> || [Bug 116663] Ungrouping collapsed rows leaves them hidden <https://bugs.documentfoundation.org/show_bug.cgi?id=116663>
15:27:15 <deneb_alpha> buovjaga, totally agree.
15:27:20 <x1sc0> ok, I thought it was going to be next year, or the next one
15:27:27 <buovjaga> I have done tutorial videos :)
15:27:31 <x1sc0> for now, I can create the one about bisecting
15:27:34 <deneb_alpha> and the text can be translated
15:27:35 <buovjaga> cool
15:27:51 <buovjaga> I think there is one old vid about bisecting
15:27:58 <x1sc0> and we can work on the script for the reporting one
15:28:09 <buovjaga> https://www.youtube.com/watch?v=SA88flop4MM
15:28:10 <IZBot> YouTube - Bisecting - LibreOffice by: Florian Reisinger
15:28:30 <buovjaga> after 6 years, an update will be good :)
15:29:34 <x1sc0> #info https://www.youtube.com/watch?v=SA88flop4MM
15:29:35 <IZBot> YouTube - Bisecting - LibreOffice by: Florian Reisinger
15:29:45 <x1sc0> oh, I didn't know about this video
15:30:03 <bearon> i found Matthew Francis' LibOCon presentation helpful
15:30:05 <deneb_alpha> x1sc0, is an old but good one
15:30:06 <x1sc0> but yeah, many things has change since then, an update wouldn't harm
15:30:49 <deneb_alpha> if I may suggest, we should follow the same steps between wiki and video
15:31:11 <deneb_alpha> so an user can read the steps from the wiki and see the video for reference
15:31:11 <x1sc0> yep
15:31:54 <x1sc0> #info <deneb_alpha> if I may suggest, we should follow the same steps between wiki and video so an user can read the steps from the wiki and see the video for reference
15:32:35 <bearon> now i understand why you were asking about my bibisecting tips the other day :)
15:32:54 <x1sc0> #todo x1sc0 to create a script for bibisecting an issue and share with the others
15:33:26 <buovjaga> bearon: the video can be one where Xisco interviews you about bibisecting
15:34:12 <bearon> the most important tip: have something you can causally watch/listen to while bibisecting, so you aren't bored to death ;)
15:36:00 <buovjaga> ADHD medication might work as well
15:36:04 <x1sc0> bearon, is it slow on win? bisecting on linux + ssd is quite fast here
15:36:15 <bearon> x1sc0: very
15:36:33 <bearon> in linux it's faster indeed
15:36:40 <x1sc0> ouch, I didn't know
15:36:42 <buovjaga> it is only slow in the beginning steps on Win for me (using a VM, even)
15:36:47 <deneb_alpha> in general a Linux user can bisect simply, the hard part is always for Win
15:37:28 <x1sc0> yep, the last 5 steps are normally really fast
15:38:05 <x1sc0> once we have the script, I can record it in my computer, np
15:39:03 <x1sc0> ok, so let's move to the next topic...
15:39:17 <x1sc0> #topic UI tests
15:40:32 <x1sc0> so raal asked me to remind everyone the existence of the needUITest keyword
15:41:11 <x1sc0> so if you see any bugs which clear steps, please add the keyword 'needUITest'
15:41:19 <deneb_alpha> ...to be added when?
15:41:27 <buovjaga> for crashers or others as well?
15:42:49 <x1sc0> ideally the bug should be fixed, no unittest is added with the fix, and it can be covered by the uitest ( the steps are like, 1. click here, 2. go there...)
15:43:04 <deneb_alpha> x1sc0, probably an update list of keywords and usage could be helpful. (I can't remember if we have this page in our wiki)
15:43:41 <x1sc0> #link https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords
15:44:37 <buovjaga> I will tweak the wording of the description
15:44:45 <deneb_alpha> thanks buovjaga
15:44:48 <bearon> when do ui test run? do they run during make, or only with some specific parameter?
15:44:50 <x1sc0> so, if you see any bug that might be a candidate, please add the keyword, if it's not, it can be deleted later on
15:45:09 <x1sc0> make check
15:45:26 <buovjaga> changed to "bugs which happen when interacting with the UI ..."
15:45:48 <deneb_alpha> x1sc0, but we have devs that exclude the make check phase
15:46:08 <x1sc0> deneb_alpha, but it's run in jenkins
15:46:21 <deneb_alpha> good point x1sc0 ;)
15:46:53 <bearon> what's the overhead of these UI tests? won't it be a problem if many are added?
15:47:05 <bearon> though we might be far from that
15:47:16 <x1sc0> so for instance, today I added the keyword to ŧdf#116640 even if it's not fixed yet ( so I don't forget ), the issue is related to the UI and it has steps to reproduce it
15:47:54 <x1sc0> bearon, they are slower than unittest, but necessary to cover the UI
15:48:04 <x1sc0> much slower*
15:48:06 <buovjaga> yep, it should do no harm to add keyword even before fix... queries can take that into account
15:48:17 <buovjaga> otherwise will be easy to forget
15:48:18 <bearon> sure, i'm not questioning if they're important :)
15:48:31 <bearon> just wondering about the potential time overhead
15:48:33 <bearon> in the future
15:48:56 <bearon> i guess we don't have to be afraid of that now
15:49:13 <bearon> let devs figure out something when it becomes noticeable
15:49:34 <x1sc0> we rely on the fact that the computers will be faster in the future ,-)
15:49:43 <buovjaga> uuh, bloatware principle
15:50:19 <x1sc0> if you want to see some examples of already covered bugs you can see the list here
15:50:22 <x1sc0> #link https://wiki.documentfoundation.org/ListUiTests
15:50:58 <deneb_alpha> x1sc0, oh, cool
15:51:09 <x1sc0> it can give you an idea of similar bugs where the keyword can be added
15:51:38 <x1sc0> and finally, if you want to write uitest, now it's easier than ever
15:51:49 <x1sc0> I've improved the UI test page
15:52:35 <bearon> i should really check it out sometimes...
15:52:35 <x1sc0> #link https://wiki.documentfoundation.org/Development/UITests
15:53:23 <x1sc0> so you no longer have excuses to don't write uitests ;-)
15:54:25 <bearon> :)
15:55:07 <x1sc0> but yep, the most important thing for now is to identify plausible bugs that can be coverted by the uitest and and add the keyword needsUITest
15:56:04 <x1sc0> so, I think that's it from my side
15:56:32 <x1sc0> any other topic/concern/question before we close the meeting ?
15:57:29 <bearon> nothing from me
15:57:39 <deneb_alpha> no for me and thanks for all the info shared today
15:58:03 * deneb_alpha learned something new today
15:58:50 <x1sc0> deneb_alpha, happy to know it was worth it, hope to see you next time as well
15:59:12 <x1sc0> bearon, buovjaga, deneb_alpha  thanks for attending the meeting
15:59:12 <x1sc0> closing now
15:59:18 <x1sc0> #endmeeting