-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Everitt wrote: > > On May 13, 2005, at 9:34 PM, Martijn Faassen wrote: > >> Julien Anguenot wrote: >> [snip] >> >>>> As for the website, my personal preference would be that we see >>>> this as >>>> a publication medium primarily and not as a collaboration medium. We >>>> could for instance use CPS for publishing "finished" design content to >>>> the web for public consumption and the like, and to draw new people >>>> into >>>> the project. >>>> >>>> The alternative which I think is presented is to use the collaboration >>>> features of CPS to do this. I myself do not have a lot of experience >>>> with these. What do others think? >>>> >>> yup Why CPS ? >>> Because : >>> 1. It proposes everything almost out of the box. (Just need to add the >>> specific content types and the layout) >>> 2. Jean-Marc and I proposed to setup the portal and we can have it >>> running by this week-end. >>> 3. it proposes both collaborative and publication features all in one. >>> Let's not fight again for the the portal technology... :( >>> >> >> This is why I carefully separated the collaboration features from the >> publication features in this discussion. I'm absolutely fine with >> using CPS for publication of design documents and there is no debate >> from me on this whatsoever. >> >> I'm just wondering whether we should use it for *collaboration* on >> these documents as well. I realize it's called Collaborative Portal >> Server, but using a CMS is not the *standard* way open source >> developers tend to work and may increase barriers to entry. >> >> Anyway, I understand now that you'd like to do collaboration by >> passing around OpenOffice and DocBook documents on a CPS site. The >> alternative I'm proposing is restructured text and a few binary >> assets like images in svn. >> >> CPS + DocBook/Openoffice >> ------------------------ >> >> Advantages >> >> * very easy web publication thanks to integration with OpenOffice, >> DocBook, etc >> >> * Lots of knowledge and resources at Nuxeo. >> >> * DocBook + OpenOffice can be exported with lots of things. >> >> * CMS and OpenOffice more accessible to non-geeks. >> >> Disadvantages >> >> * higher barrier to entry for J. Random Open Source Developer >> >> * harder to do simple 'diff' to see what changed >> >> svn + ReST >> ---------- >> >> Advantages >> >> * lightweight >> >> * svn diffs, checkin mailing lists with diffs, help see what's going on. >> >> * Compatible with what Zope 3 is doing already. >> >> * Increased familiarity for developers; lots of people can handle svn >> and plaintext. >> >> * Can be exported easily to HTML and simple PDF. >> >> * Documentation can be kept in synch with the code, doctests. >> >> Disadvantages >> >> * Somewhat harder to publish end result to the web as no integration >> with CMS. >> >> * Less programmable features, all very flat and plain. > > > Very good writeup of the pros and cons. > true. we got the pros and cons of both solutions like this. Though, I guess we need both. rst for svn with doctests is of course the smartest approach but OOo / dockbook for big design documents seems to be more accurate. > I propose that we tolerate both approaches. Ultimately I think > Martijn's view will prove right, that developers will jot things down > in an Emacs buffer as they are writing code. Tolerating both approach will be probably the wise solution if people really don't want to use OOo to generate dockbook. The problem is that managing more than 10 pages, for instance, with Rst doesn't make any sense. I'm an emacs user big time as well and I had the same reaction at first. But seing basically, that OOo can be seen as a wysiwig Dockbook editor was just amazing. BTW, you may type as well the dockbook in emacs in plain text ;) > > However, I'm personally interested in the OO.o/Docbook approach the > Julien described and will use it as soon as he gives me a login. > it's coming :) > Moreover, I think we should recognize Julien and Jean-Marc's > initiative, just like we should recognize Philipp's initiative. I > think the two directions can work together Philipps's initiative about what ? documentation ? J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Plateform : http://www.cps-project.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFChjYNGhoG8MxZ/pIRAtrOAJ4q7iZ/QvmrfnziPUDeNKhPnPBnvwCfUWQw VZ6NOXN4KPXiwC4pJBUj80k= =SBeG -----END PGP SIGNATURE-----
Hosting: Nuxeo: Zope service provider