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