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
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
