When to set VERIFIED in BugZilla?

[James Richard Tyrer]

Carlos Leonhard Woelz wrote:
> There is no QA in KDE currently.

And this is a serious problem.

> There are no volunteers for the hard (and technical) work of designing 
> such programm, and no volunteers for doing the massive work of following
>  all bugs.

It appears to me that we should not fall into this trap.  Just because we
can not follow *all* bugs doesn't mean that we shouldn't start following
*some* bugs.

> Currently there are not enough people to even manage the bugs we have 
> properly. So why not start with something simple (managing bugs),

I'm not 100% certain that I understand what you mean by "managing" bugs.
As I see it this involves:

	Writing test cases to add to BugZilla.

	Watching the bug (adding yourself as CC) to add comments as
	appropriate and making sure that it isn't marked as FIXED before it
	is actually fixed.

	Verifying that the bug has been fixed in the next stable release.

and when this is well handled, try the next step?

Since we have a system which is based on constructive anarchy, the next
step would also be taken by the person that was managing the bug.  That
person should mark the bug as VERIFIED or ask the maintainer (or other
person) to do so if they don't have the authority.
> 
>> My question is: do you (do we, do all the people that read these 
>> mails) think about quality from the point of view of the user or from 
>> the point of view of the technical properties of the product?
> 
I think of it first from the point of view of the user.  I also think about
the technical properties of the product but at the present time this is a
secondary consideration for the Quality Team since others are addressing this.
> 
> You are asking if a QA team can be formed with "user defined rules" 
> instead of "technical rules". I am not a specialist, but I think no, 
> because there is no such a thing as "user defined rules".

Using *user defined rules" is called eXtreme Programing.  To me, we should
include "user defined rules".  The most important "user defined rule" is: 
'Has the bug been actually fixed'.

> The "User" is a mithological entity: in real life, each user has a 
> different opinion.

But there are many bugs that have nothing to do with an opinion.

> Also, QA is a technical process by definition, so it is impossible to 
> have a non technical QA process.

Yes there are more technical aspects that we can get to after we have an
efficient user oriented process in place.  The usability project is already
working on some of this.

> Also, in free software, you depend on people's will, not on hierachy.

Yes, we need to have a distributed model for QA -- not one based on
hierarchy except that those that do not have write authority in BugZilla,
will have to ask someone to do various things.

> So if an arbitrary group of people (let's call them "users")

No, lets call them us (the Quality Team)

> wants to change the direction of a project,

And lets presume that the change in direction we want is to have the
project have better quality.

> they can do so only by convincing the developers using good arguments 
> (or good bug reports).

Yes, good bug management should improve the reports by adding comments from
those with more expertise than the original reporter.

> Something that does not motivate people to work is useless, unless the 
> interested group hires someone to do it.

Obviously people differ in their motivation.  I do not know how to motivate
developers that have a "users be damned" attitude -- I do not understand
how they could have such an attitude.  This may be an uphill fight.

--
JRT