Thorsten Ziehm wrote:
Hello QA-Team,
the number of 'unconfirmed' defects increased in the last months to
nearly 1000 issues. It isn't possible for the Sun QA team to work on
all these issues alone. So the help of the whole team is needed.
Please visit my blog with some more details and links to queries.
http://blogs.sun.com/GullFOSS/entry/nearly_1000_unconfirmed_defects_are
Thanks
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/I understand the concern, however the cause may be partly a process
issue. This seems important - I spent a lot of time last night lying
awake thinking about it - please bear with the explanation below.
I take it as fundamental that everyone on this project is doing what
they believe to be right. The examples used below are intended to
illustrate the process problem, and are in not way intended as criticism
of individuals./
Several times in the last few months there have been comments about the
resolution of issues, the most recent of which was a message yesterday
by Laurent Godard about
http://fr.openoffice.org/issues/show_bug.cgi?id=3460
These cries from the heart seem to illustrate a fairly common if not
general disquiet with the issue process, underlying which is a sense
that the bug detection and correction process does not seem to set the
right priorities, especially in terms of deadline for bugs in categories
below P2, and as a result that the significant effort needed to
contribute to the quality process does not make a sufficient difference
to repay the effort involved.
For example, http://qa.openoffice.org/issues/show_bug.cgi?id=71957 was
an issue I found and spent several hours researching, considered at the
time as a 'feature'. Later, the problem was discovered independently by
someone with more influence, categorised as a regression, and fixed.
This is a clear example where my time was wasted. Now of course, in
processes as complex as they necessarily are within OOo, it's obvious
that some time is going to be wasted - it cannot be a perfect process.
However, there is a difference between feeling that 70% (ideally) or
even just 50% of ones effort is being used effectively, whereas my
current feeling is that 99% of what I have and might in the future
contribute would be a waste of my time, contributing primarily to a
stack of issues with completion deadlines of V3.0 or later which in
practice are unlikely to ever influence the development of the product.
'Ordinary' qa people like me need to feel that they have a direct
influence on priorities to make the effort worthwhile. For example, some
time ago I floated the idea of 'minimum acceptable functionality' as a
way of distinguishing the importance of certain bugs for fixing within,
let's say, the next two releases. There are no doubt a million other
ways to do it, but it seems to me that qa team members need to have the
authority to set the target deadline for a small proportion of issues
which are important to end users but not 'sexy' coding tasks for the
developers, even if the developers then set them back. Because this is
not available, it may be that many qa project people, like me, soon
become so disenchanted with the amount of effort for almost no result
that they end up just watching the correspondence on this distribution
list and not doing any work.
I don't pretend to know the best solution, but it is clear from where I
sit that the process is not fully fit-for-purpose and I plead with those
who are able to influence OOo processes to take this concern seriously.
I hope I have not spoken too much out of turn.
--
Mike Hall
www.onepoyle.net
