Hi,
some of you might have read Thorsten Ziehm's blog at [1].
(Side note: I wanted to summarize the discussion and bring it to this
list, but I've been at LinuxTag Berlin for some days - not able to
review the mails.)
Thorsten is referring to a discussion that happened some days ago at the
german project list [2]. The Discussion was triggered by a users's mail,
asking for some rather old but still not fixed bugs in OOo.
After this has been answered with the ususal "sorry, you need to
understand, that software is never bug-free and we have limited
ressources ..." some project members expressed that they are not
satisfied with this situation and the everlasting excuses. In fact, I am
one of those members.
While Thorsten's conclusion (in the blog) is, that OOo 3.x has no
general quality issue, mine is different: The OOo project has a quality
issue.
Following Thorsten's arguments, you can indeed excuse all and everything
by the two facts that we have limited ressources and that software will
never be error-free. What makes me upset, is the silent acceptance, that
the total number of reported issues is constantly growing. If we
continue that way, we will once be burried under a pile of open bugs
(imho, we already are). No matter what numbers you take, there is one
simple fact: we fail to handle the incoming bugs - the rate of fixing
(or handling) bugs is lower than the rate new bug reports come in.
Ok, back to the discussion at d...@de. Tome, Stefan Weigel gave a very
good summary in the middel of the thread (he was referring to some of
Thorsten's statements) . I'll try to translate it here.
<quote>
...
What you are writing is correct but not true at the same time. It is not
true, because something was left.
True is: "Quality Assurance reveals bugs."
True is: "QA will prioritize these bugs."
True is: "QA is not responsible to fix these bugs."
To get the truth in this context, the missing piece is: "Quality
Assurance without Quality Management does not exist. The responsibility
of Quality Management is to plan and control the bug fixing - and (most
important) to prevent that new bugs will be introduced."
</quote>
This Quality Management is (imo) the missing link. Nobody seems to be
(or even willing to be) in charge of this.
There was an interesting post from Herbert Duerr in the discussion, that
referred to his blogpost about a "not so easy to catch" bug [3]. He (as
a developer) had to spend a lot of time to identify the root cause of a
class of issues. This work could have been done by a volunteer user or
QA member as well - saving valuable developer's time. So the question is
- why did no volunteer do this? The answer (from my perspective) is
simple: because a volunteer would have spent a lot of time, but this
would have almost no influence on the time line for fixing the bug.
Unless as we don't know, that a developer is going to work on an issue,
QA members might see the effect of their work in months, if not years or
never. At a certain number of processed but not fixed bugs, this nothing
but frustrating.
So - we have a constantly growing number of bugs, developers who waste
time to track those bugs down (while this was the task of QA) and QA
members, who get frustrated because bugs get not fixed (and lower
theirengagement within the project). I cannot help - but to me this
seems as we have a problem.
Ok .. we should get something positive out of this :)
Matthias Bauer brought up the idea to identify areas for bugfixing and
then start a collaborative effort by developers and QA. This might work
like the iTeams for new features - but with the focus on bugs. For
developers this would more efficient, as it is easier to fix bugs within
the same area. For QA volunteers this would be more interesting, as the
their work will result in real bug *fixes*.
I hope, we can start some of such projects soon.
But even this would only help to ease our current problems. If we do not
change our mind from "there is no Software without bugs" to "only a
fixed Bug is a good Bug" we will find ourselves spending more time for
excuses than for doing the real work.
What I'd like to see in the future is:
- joint and better coordinated efforts from QA and development to *fix* bugs
- the common goal of the project to work on bugfixing (instead of the
separate statement of the QA project that fixing bugs is not within our
responsibility)
- the commitment to fix bugs even in old features (and not only
regressions). Each feature once was new. Following our current policy
you just need to wait long enough to counter the regression argument.
Comments are welcome :)
André
[1] http://blogs.sun.com/GullFOSS/entry/does_openoffice_org_3_x
[2]
http://de.openoffice.org/servlets/BrowseList?listName=dev&from=2243806&to=2243806&count=56&by=thread&first=1&windowSize=1000
[3] http://blogs.sun.com/GullFOSS/entry/what_could_possibly_go_wrong
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
