KDE 4 Development book

[Frans Englich]

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