On Sunday 14 November 2004 18:44, Duncan Mac-Vicar P. wrote: > On Friday 12 November 2004 10:29, Kurt Pfeifle wrote: > > On Friday 12 November 2004 10:49, Cornelius Schumacher wrote: > > > On Friday, 12. November 2004 09:23, Frerich Raabe wrote: > > > > did anybody here meditate about a KDE 4 development book yet? > > > > > > I did meditate about such a thing a while ago. The problem is that it's > > > not very likely to find a publisher. > > > > Not true. > > > > If you guys take care of the writing, I'll take care of finding a > > publisher. I might even find half a dozen, and in the end you > > could choose to negotiate the best deal. > > > > Cheers, > > Kurt > > would a sort of wiki help to make writing an official kde book > collaborative? > > http://doc-book.sourceforge.net/homepage/ provides a wiki whoch is saved in > docbook format and kept under CVS version control. A tough question, and I have no good answer. I think it's important to have clear what problems we try to solve and what we want to achieve, before looking at solutions. I had a quick glance at that docbook-wiki project. * With its web interface it makes editing easier, but I don't see that as an issue; people can write in whatever format they like, and the Docbook conversion is taken care of. * It makes it easier for /many/ people to contribute(the community aspect of wiki), but I wonder if that's needed. There may be a large initial interest, but it will as usual boil down to a couple of persons doing the work. * The guidelines, the (technical) KDE Development Book, the HIG, CIG and AG guidelines are all serious -- they dictate rules, and the design of KDE. I think a clear view of what goes in and out is necessary, and that the usual patch-submission and kde-cvs supervision works fine. The docbook-wiki allows password/user accounts, but I wonder if not our usual methods works fine. * The solution takes care of everything, it's all-in-one, and I don't know if it meet all the requirements we have(see kde-guidelines archives). But OTOH, those aspects doesn't hurt, so they don't have a negative impact. I think it boils down to how easily it can be styled/changed. Another thing is that whatever solution that is chosen, requires buy-in from the guidelines group, currently there's a mentality of "only person X and Y will edit, so it doesn't matter what others thinks", since much of the idea of this whole project is to unify and integrate. BTW, anyone should feel free to lurk on the kde-guidelines list, which is excellent for these topics: https://mail.kde.org/mailman/listinfo/kde-guidelines Cheers, Frans