forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregor J. Rothfuss" <gre...@apache.org>
Subject Re: [PROPOSAL] A CMS for our Docs
Date Tue, 07 Jun 2005 15:13:21 GMT
Ross Gardler wrote:

> The CMS is a "super wiki" - loosely controlled, low barrier to entry - 
> most importantly *not* published as official docs

lenya does have the authoring and live view for this purpose (and 
workflow), so presumably the barrier for editing / submitting for 
approval would be lower, and approval/publish would come from a commiter.

> The published docs are managed by Forrest as normal using the 
> locationmap to bring content from both SVN and the CMS
> (this step may not be necessary if Lenya can use SVN as a repository)

it cannot yet, but that is one of the things we want to work out.

http://mail-archives.apache.org/mod_mbox/lenya-dev/200505.mbox/%3c4293FE22.3050000@apache.org%3e

>> Perhaps we are using different terminology here. I see that
>> committers review/edit and then "commit" changes. The "publish"
>> is a separate process whereby a group of committed edits
>> is now ready and the documents are generated and moved to the
>> actual website.

imho, the commit to SVN of the source document can and should happen 
only after a document has been reviewed & approved. this would keep 
intermediary versions out of SVN, and would make sure only commiters can 
initiate commits to SVN.


>> After that, how do those "finished" documents get edited again?
> 
> In the CMS just like before. Our published docs are generated from the 
> CMS repository, this is no different from the current situation in which 
> we publish from our SVN repository.

right, the CMS keeps track of both source and rendered versions, and 
after a rewiew/publish cycle, the editing process can start anew.

>>> In other words, we have the chaos of constantly evolving docs under 
>>> the surface, on the surface we have nice ordered, version controlled 
>>> and managed publications for our users. The migration path between 
>>> the two is the close attention to detali of the review process.
>>
>> Oh dear, i am feeling overwhelmed with the thought of chaos.

if these tools help to get more people involved with working on 
documentation, then i think having to review more changes to the docs 
than today is a nice burden to have ;)

> (with Daisy, Gregor has already acknowledge Lenya doesn't do diffs this 
> is a *big* problem)

.. and therefore needs attention from the lenya community:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32008

> Yes, this is one of the advantages of the fact that the Daisy wiki 
> tidies the edited content. you always get good diffs regardless of how 
> the author wrote the content.

lenya uses xml wysiwyg editors, so the diffs should also be quite ok. 
there are tools like xmldiff for that purpose.

wyona has some code for this, let me see if we can donate it.


> That is exactly my proposal - no dependency. However, if Daisy were to 
> adopt Forrest as the *only* publishing engine then there would be a 
> dependency in the sense they could not do static publishing without 
> Forrest. Since they do not need the multiple input formats they are not 
> interested in using Forrest as the publishing engine.

i personally would love to delegate lenya's publishing to forrest :)

> My thinking precisely. I'd rather go to infra with the start of a solution.

+1

>> Sounds like duplication of effort to me.

at least for lenya, this dogfood problem exposes some issues that we 
need to be working on anyway.


Mime
View raw message