Quality Teams on the wiki

Tom Chance lists at tomchance.org.uk
Mon Mar 8 13:10:02 CET 2004


Marc,

On Monday 08 Mar 2004 11:53, Marc Heyvaert wrote:
> While I understand the advantage that a wiki-page may
> have to keep the momentum going, I think that there is
> a certain overlap with existing web-pages and mailing
> lists. I am mainly interested in KSpread/KOffice and I
> think that a well maintained KOffice-website -with
> joblists, howto's, etc.- + active mailing lists +
> looking into and reacting to bugreports (hence the
> importans of bugs.kde.org) is enough really. And I
> don't think we're there yet...so the extra effort for
> maintaining a wiki-page is perhaps not the best way to
> direct the scarce resources that KOffice disposes
> of...

The problem with using the static web pages rather than a wiki is that it can 
only be used by a limited number of people. If I want to join the KOffice 
Quality Team and I want to do some testing, what do I do?

Let's say I join the kde-quality and koffice mailing lists, post my 
intentions, and begin my work. I now have to rely on the people with access 
to the web site to publish my name and what I am doing, so everybody knows 
what I am doing, and I have to pester them to update my status on the page as 
I work.

With the wiki I don't need to go through somebody else, I can continuously 
update my status myself. The wiki allows many people to collaborate and 
organise tasks without weighing down certain people with extra web admin 
work.

I think we should encourage all KDE modules to adopt this approach, keeping 
development info that is in flux and that Quality Teams need access to on the 
wiki, and keeping more stable information on web sites. It really won't 
create any more work for KOffice in the short term (simply transfer joblists 
onto the wiki, which I can do), and it should cut down on these tasks for 
developers in the long term... precisely the point of Quality Teams.

Regards,
Tom


More information about the kde-quality mailing list