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