QA Advance Volunteer List?

[Jamethiel Knorth]

>Date: Wed, 03 Mar 2004 08:30:54 -0800
>From: "Carlos Leonhard Woelz" <carloswoelz at imap-mail.com>
>
>On Wed, 03 Mar 2004 10:51:13 -0500, "Jamethiel Knorth"
><jamethknorth at hotmail.com> said:
> > I am hoping that a service could be offered by the Quality Team to have
> > people sign up in advance to be active at a later date. That is very
> > unclear, so let me explain:
> >
> > I could sign on now, giving my e-mail to a list, basically saying, "I'm
> > really busy and can't work now, but call me when a lot of work is
> > needed."
> >
> > That sounds really bad, but the idea would be that, when the next 
>version
> > of
> > KDE was primed for release, right when the feature freeze went in,
> > everyone
> > who had put themselves on that list would be e-mailed. I am somewhat in
> > this
> > situation right now. I post a bit on KDE-Usability, and don't have 
>enough
> > time on my hands to really work on the Quality Team. However, I could
> > spare
> > a week or three once a year to really get down to business when the
> > feature
> > freeze is in.
>
>More on that below.
>
> > Also, from my experience with programs, it is very hard to write
> > documentation before a feature freeze. Screenshots are out of date 
>almost
> > the second they are taken, howto's never exist for the new (and as such
> > unknown and in need of a howto) features, and options will move or
> > disappear
> > the instant you write down where they are.
>
>Indeed.
>
> > I am not up to doing any sort of QA work on a regular basis, but I would
> > love to lend my help during crunch time, those couple weeks before the
> > final
> > release.
>
>That's when QA is really necessary. You are correct. That is a very good
>idea for QA, but not necessarely true for other areas.

I realize the quality team is more than QA. I was suggesting this primarily 
in regards to QA.

> > Hopefully, that reminder e-mail could also include some other useful
> > information, such as:
> >
> > - The programs that seem to really need help (they have NO docs, they
> > haven't even started doing What's This? help or tooltips, their 
>interface
> > needs vetting, they're getting tons of bug-reports without much
> > substantiation behind them)
>
>The problem with documentation is that the strings freeze is close in
>time with the feature freeze. So during the betas, you can't update the
>docs. This is necessary because of the huge ammount of work for
>translating KDE. We could try to postpone the strings freeze, but that
>would mean that KDE would be released with the english version only.
>
>Also, some applications are more stable than others. There are
>applications that are very stable for years, and  still not very well
>documented. Documentation is hard for non native english speakers, and
>take a lot of time.
>
>For all that reasons, one has to start much earlier than the feature
>freeze, and for some stable applications, any time is a good time.

I was not aware of this. That makes things much more difficult. If there 
were at least a little time between the feature and string freezes, it would 
be good.

> > - The exact CVS commands to check out the right CVS version, as well as
> > any
> > known build issues and workarounds, so all the QA guys are actually 
>doing
> > QA
> > on the right program.
>
>OK, this is easy: this text is ready and already online.

I realize that, I was just saying that a note about exaclty what is 
'current' would be good to include in an e-mail of the sort that I 
recommended.

>  - A very simple format in which QA guys should report the issues they
> > find
> > (maybe a really good template set, so they could say: "Program:
> > Konqueror,
> > Issue: Documentation of Toolbar Editor, Solution: *really long help
> > chunk*"
>
>For that, we already have the tools: bugzilla and KDE Wiki.
>
> > - How to check which problems have already been noted by other QA 
>people,
> > and which programs have been gone over how many times (obviously, that
> > would
> > also need a server where QA people could note that they checked
> > something).
> > So, that last one was a bit too much to hope for, as was the good
> > template
> > set, quite likely. I can dream.
> >
>
>Bugzilla! http://bugs.kde.org

As far as I could tell, Bugzilla did not do exactly what I was asking for. 
For example, I am a QA tester, I go over Konqueror and decide it is 
error-free. Where do I put that comment? It is not a bug. The purpose is to 
make sure that QA people don't just keep checking the same app over and over 
and over and over again. Something like a page listing the app and who has 
said it is clean.  It can't just be an is it done/not done, it needs to 
allow people to see who has okayed it, at least for generic testers.

Maybe people with higher privileges (the people with CVS commit rights) 
would be able to declare an app 'Done for release X.X.X'. That is mostly 
important for right before the big releases, like 3.3.

If that is in Bugzilla somewhere, I just totally missed it.

> >
> >
> > I do worry that this idea might result in many potential contributors
> > deciding to only contribute before a major release, but I don't think 
>the
> > harm would outweigh the benefit. Many, many people just don't have the
> > time
> > to really contribute regularly, but could spare a lot of hours for a
> > couple
> > of weeks each year. Also, it might encourage people who would otherwise
> > be
> > reluctant, as their efforts would directly improve the version of KDE
> > that
> > they are about to receive.
>
>You definitely have a point regarding QA: we can try a midia blitz
>calling for testers before the releases. But for other areas (usability
>(as you know!), docs, artwork, complex features testing, etc...) more
>constant work is required.

As I said, I was just recommending it for QA. For everything else, that's 
not gonna work, but QA really is one of those crunch-time, power-hour 
activities, where it a lot needs to get in between the feature freeze and 
the release.

_________________________________________________________________
Create a Job Alert on MSN Careers and enter for a chance to win $1000! 
http://msn.careerbuilder.com/promo/kaday.htm?siteid=CBMSN_1K&sc_extcmp=JS_JASweep_MSNHotm2