[kde-doc-english] Re: Google summer of code documentation project

[Daniel Rutz]

Philip (and everyone else),

While I'm not averse to the Content work, it seems to me like the 
Technical-type items are a bit more focused and measurable, which would 
make them more suitable for a Summer of Code project.  I don't want to 
get into anything way over my head, but I also want to pick a meaty and 
relevant project because I gather that I will be competing with many 
other students for a very limited number of Google sponsorships.

In the absence of any other suggestions, I think that I'd like to 
explore Technical ideas #2 (KDE-wide glossary) and #3 (Documentation of 
DCOP calls) as candidates for my SoC project.  Perhaps if someone could 
explain a bit more about where the glossary info would come from and 
where/how it could be collected, and a quick overview (and/or reference 
to more info for either idea) on how DCOP calls work and what methods 
could be used to document them, this would allow me to choose one of 
these to dig into.

Thanks again!

Daniel



Philip Rodrigues wrote:

>Hi Daniel,
>(First, a disclaimer - I've been a little out of the loop for the last few weeks, so what I say might be wrong. If so, hopefully someone will correct me.)
>
>Great to hear that you want to work on documentation; we're always happy to welcome new people. I've just done a little reading up on the Google Summer of Code, so hopefully I have some idea of the sort of things that are suitable projects. Did you have something particular in mind? If so, we can work on discussing it and refining it if necessary. If not, some things off the top of my head, in two broad categories:
>
>1. Content:
>
>* The User Guide: The new KDE User Guide is intended to be a general guide to KDE; a first place for users to look if they have problems. It's at a stage now that could be called complete, but there's plenty left to be written, and some other improvements that can be made (adding a comprehensive index, adding "Related information" links). You can see the user guide online at http://docs.kde.org/en/HEAD/kdebase/userguide/ .
>
>* KOffice: The KOffice suite is large and featureful, and always in need of more writers. I'll leave Mike and Raphael to suggest particular areas which could do with help, but if you're interested in working on KOffice, we can put you in touch.
>
>2. Technical:
>
>* PDF generation of the KDE docs: We have the beginnings of this working, but it needs more testing, integration into the build system, and work on internationalization. Requires knowledge of XML, XSL and maybe LaTeX and Perl.
>
>* KDE-wide glossary: Having a central glossary for all of KDE would be great. There are tools to do it with DocBook (which we use for all the KDE documentation), but there are some issues, I think with i18n, to be worked out.
>
>* Documentation of DCOP calls: Something on my personal wishlist. DCOP is the KDE inter-process communication system, but it could really do with a method of documenting the function of each DCOP 'method' (like doxygen in the KDE API).
>
>If any, or none, of those interest you, get back to us, and we can work on it. Any other thoughts, we'd be glad to hear them.
>
>Regards,
>Philip
>
>(PS: for the 'regulars': if you already had some plan or set of ideas, and I've just gone and contradicted them, I apologise. Hopefully those ideas are useful anyway :-)
>
>  
>