QA Advance Volunteer List?

Carlos Leonhard Woelz carloswoelz at imap-mail.com
Wed Mar 3 17:30:54 CET 2004


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.

> 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.

> - 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.

 - 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

 
> 
> 
> 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.

Cheers,

-- 
  Carlos Leonhard Woelz
  carloswoelz at imap-mail.com

-- 
http://www.fastmail.fm - Same, same, but different



More information about the kde-quality mailing list