Documentation Team Ideas

[Carlos Leonhard Woelz]

On Wed, 1 Sep 2004 21:26:56 +0100, "Tom Chance" <lists at tomchance.org.uk>
said:
> 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.

Yes, Philip, I think it is interesting for us. Documentation is a very
nice starting point for new contributors: it increases the general
knowledge about the app, it's excellent for non programmers. We are here
to help people starting to develop KDE, so it is clearly on topic for
this list. So bring them on!

I still want to finish the doc-primer. I think it is a great idea.And
improve / replace the documentation HOWTO... Let me see if I can put
some action with my words this week...

 
> 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? :)

I would be careful with an excessive number of wiki pages. The ones we
got are already hard to maintain... If we could have one updated page
per module, in the beginning of each  release cycle, that would make me
really happy. We could announce them widely, and see if new people
arive. It worked (on a small scale) for the last release cycle.

Cheers,

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