Confluence updates

[Aristedes Maniatis <ar...@maniatis.org>]

I've wrangled some improvements to the Confluence templates:

1. All pages have edit/new links in the top right corner. This makes it easier to edit pages without having to dive around the backend hunting for the right page. It is very important for the wiki since it makes it easier for the public to change pages.

2. The wiki section now has automated links to children at the bottom of each page. See ( http://cwiki.apache.org/CAY/ ). We didn't do that before because it was previously not possible to put them in the right order, but now it is. This is a big improvement largely because it is less likely we'll have pages orphaned in the structure. Half of the wiki was effectively orphaned since the navigation doesn't match the actual pages very well.

This last point means that we need to do a bit of work to make sure the pages are in the right order in Confluence and then remove unneeded links, then I'll roll out the same idea to the entire site. At the same time the docs could do with a little re-organisation to ensure they are in the order that makes most sense to new users. In particular I'll be going through the modeler guide to clean it up.

When I'm done, I'd like to look at blowing away CAYDOC30 and making a new copy since I'm hoping it will make more sense. This is one of the reasons I don't like this forking of the docs so often, but I know I'm in the minority on this one. When that's done I can remove the DI page from CAYDOC30 which Andrus just added.




Ari


-- 

-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Confluence updates

[Aristedes Maniatis <ar...@maniatis.org>]

On 30/11/09 6:29 PM, Andrus Adamchik wrote:
>
> On Nov 30, 2009, at 3:39 AM, Aristedes Maniatis wrote:
>
>> When I'm done, I'd like to look at blowing away CAYDOC30 and making a
>> new copy since I'm hoping it will make more sense. This is one of the
>> reasons I don't like this forking of the docs so often, but I know I'm
>> in the minority on this one. When that's done I can remove the DI page
>> from CAYDOC30 which Andrus just added.
>
> Thanks for the heads up. I also changed the Cayenne version in CAYDOC on
> a few pages and added "What's new in 3.1" page. So maybe let's keep
> CAYDOC30 unchanged. It is mostly frozen after all, so do we care to
> clean it up at this point? What do you think?


Let's see how much I do after I find the time to work on the docs.


>> This is one of the reasons I don't like this forking of the docs so often
>
> Ideally we'd use an SCM and branches to maintain multiple doc versions,
> like we do for code. And we did that in the past. But that created a
> significant barrier to editing the content. No ideal solution I guess :-/


Well, I'm about to embark on an experiment in docbook for my company. I've just engaged a writer and we'll see in a few months how it all goes. We are doing just that: taking docs out of our CMS and putting them into svn. Our goals are to be able to generate pdf, embed docs into the application, etc.

In the meantime, let's keep going with what we have now.


Ari


-- 

-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Confluence updates

[Andrus Adamchik <an...@objectstyle.org>]

On Nov 30, 2009, at 3:39 AM, Aristedes Maniatis wrote:

> When I'm done, I'd like to look at blowing away CAYDOC30 and making  
> a new copy since I'm hoping it will make more sense. This is one of  
> the reasons I don't like this forking of the docs so often, but I  
> know I'm in the minority on this one. When that's done I can remove  
> the DI page from CAYDOC30 which Andrus just added.

Thanks for the heads up. I also changed the Cayenne version in CAYDOC  
on a few pages and added "What's new in 3.1" page. So maybe let's keep  
CAYDOC30 unchanged. It is mostly frozen after all, so do we care to  
clean it up at this point? What do you think?

> This is one of the reasons I don't like this forking of the docs so  
> often

Ideally we'd use an SCM and branches to maintain multiple doc  
versions, like we do for code. And we did that in the past. But that  
created a significant barrier to editing the content. No ideal  
solution I guess :-/

Andrus