Documentation Team Ideas
Tom Chance
lists at tomchance.org.uk
Wed Sep 1 22:26:56 CEST 2004
On Wednesday 01 Sep 2004 21:02, Philip Rodrigues wrote:
> Hi,
> I've put up some notes from documentation team discussion at aKademy on the
> wiki at:
> http://wiki.kde.org/tiki-index.php?page=Documentation+Team+Ideas
>
> One of the ideas floated was that we in the docs team should send all new
> contributors to the quality team, instead of directly dealing with them
> ourselves. There's some more detail about the idea in the section
> "Interaction with Quality Teams" on the wiki page above.
>
> Would the quality team be interested in doing this? Does anyone have any
> thoughts about the best way to go about organizing such a system? The docs
> team will still need to be involved, for technical knowledge etc, but will
> need to be slightly hands-off, otherwise we end up with the same situation
> that we have now.
I should think we would :-) As I said in my talk, the more work comes out way
the more likely we are to succeed.
One thought I just had is that the documentation team could maintain a wish
list. Let me explain this properly :)
At the moment we have lots of wiki pages for each module or app trying to
summarise every area of work, the status, who's working on what, etc. That's
a *big* job and one that is unlikely to be done unless the maintainers can
see results frequently.
In your wiki page, Phil, you mention Fab's welcome e-mail in which he gives
the potential contributor a few areas to start working on. How about adapting
this to have one wiki page for the documentation team (and for app authors)
outlining what work needs to be done. The page can be as sparse or as
detailed as people are willing to maintain, so long as it fulfulls these two
roles:
1) It must be useful for the docs team
2) A potential contributor must quickly understand it
An example I can think of would be to mention the user guide and the glossary
as two areas that need a lot of work. You could either just maintain a
description of this work, or even organise your work on the page. We can then
easily pick new volunteers up, point them to the page and hold their hand
until they're able to work on their own.
In other words, we have role-based wiki tasklists, not app- or module-based,
wherever teams are willing to maintain them. This already seems to be
happening with art (re: kde-look and kde-artists discussions).
Counter-thoughts? :)
Regards,
Tom
More information about the kde-quality
mailing list