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