[Libreoffice-qa] How to change QA processes: was: What should we do with bugs filed against Extensions/Templates?

[Rainer Bielefeld]

Petr Mladek schrieb:

> Ah, this sounds pretty bossy.

Hi,

yes, may be. My tone reflects my exception. I see too much unqualified 
discussion. Before thinking about changes everybody should have have 
understood the current system, why it is how it is? With such a base 
improvement seems more promising I know, that sounds rather obdurate, as 
I would want to defend "my creation" against any change. That's wrong. 
But I am such kind of Swiss wrist watch maker. 50 years ago that was an 
admired art, today it's considered spinning mills.

Quality Assurance has to do something with quality, and we have to 
observe and grant the quality of your own work. And here I have serious 
concerns.

Let's take "Bug 63210 - EDITING: Superscript Defaults incorrect". Joel, 
please excuse me for taking that example, it was the first but I saw 
this morning in my "New bug reports" folder, and it's a typical one for 
observations I see with rising number in the last months. The goal seems 
to be to get the reports out of the QA process as quick as possible 
(because we have so many untouched reports), but I do not like that way, 
that only increases the amount of unfixed confirmed bugs. If we cans 
save 5 developer minutes at each bugs with careful research, that's a 
potential of 55 hours for the 679 bugs what changed to NEW in March 
2013. That's 1 work of week for a busy developer!

It has status NEW, what means "ready for bugfixing",
<https://wiki.documentfoundation.org/QA/BugTriage#Step_5._Set_Status> 
item 1, but I believe it's not:

a) We have a report without info concerning Version and OS, and a 
confirmation for 1 Linux distribution. So current knowledge (for the 
moment) seems to indicate a LINUX problem? Should the report leave QA 
process ("NEW") without having this corrected or at least mentioned? 
Well, I confirm that for WIN, and so finally the found OS selection is 
correct, but without reasoning that's simply wrong. Reporter should be 
asked for related info.

b) In between we have 3.6.6.2, what might be the next release. Shouldn't 
be checked whether the problem has been solved in between?

c) This problem is text language related (of course), in German text 
language this auto correct does not exist. That might lead to the roots 
of the problem, I would have liked to find out where that problem started.

d) It should be stated that the problem is limited to <Enter> after the 
date, works fine if you simply type a space or even after 
<Shift+Enter> or <Control+Enter>.	

e) Not only Writer is affected, same in Calc with <Control+Enter> and 
Draw (and so probably Impress), might also appear in Base.

f) The summary line still has that meaningless "incorrect". After QA it 
should be "AUTOCORRECT: Superscript of English ordinal number suffixes 
continued behind 'Enter' directly after suffix". Or similar!
Queries for DUPs really are painful if you have lots of bugs only 
distinguishable by the words "improperly" and "incorrect" in Summary.

g) Back to versions: This worked fine in 3.3.3, so it seems interesting 
to know where this problem appeared? And it's a regression.

h) The example in the report seems a little misleading to me because of 
the parenthesis around the date. The screenshot shows what reporter 
typed, but I would have mentioned what I typed exactly (well, this is 
splitting hairs)

i) May be I even would have tested whether the bug persists with new 
User Profile? But I doubt that it's related and so I think I would have 
written "I doubt that it's profile related"

k) And after having added all this information I would think about 
adding András to CC. I agree with "minor" rating and we should not 
bother developers with too many odds and ends, but on the other hand a 
known bug can be integrated into the work flow for a fix some later.

l) And I would have thought about an enhancement request for localized 
list numbering with correct localized ordinary numbers, but that already 
is quite a different thing.

And so back to the beginning. I like to co work with "Swiss wrist watch 
makers", these guys who know for every of their actions at work why they 
do it exactly how they do it, and who always check whether there is a 
possibility how they could do better.

The question is whether there is a place for these people in the LibO 
community. From my point of view, at some places I see too much 
actionism instead of careful work and enhancement (beneath a lot of good 
work, of course), and that's a pain for me. We Swiss wristwatch makers 
need a wristwatch maker workshop with wristwatch makers tools, and I 
doubt that this workplace will be kept in the LibO project. I will not 
change the principles of my way of working, when my workplace will have 
vanished I will not whine, but simply move to a new place where I can 
work with congenial colleagues.

Of course I should have mentioned that I like the efforts to interest 
more people for bug wrangling, the cleanup in the QA wiki, the thoughts 
ofa more structured QA work and and and, but my time slot has been 
expended with laments, so there is no more time for this.

Best regards

Rainer