Doc - Mine wiki and tickets for site documentation

[GoogleCodeExporter]

The wiki and issue tickets contain detail that should be in the web site
documents now. 

Before creating any new content, I'll review and pull over existing content
first. 

Original issue reported on code.google.com by ted.husted on 31 Dec 2009 at 1:34

[GoogleCodeExporter]

Obviously, the wiki pages were started before www.vosao.org was self-hosting. 

Now that we can document the CMS in the CMS, are there any pages that we want to
leave in the wiki? Release notes? Roadmap? 

One use of a project wiki is to document new features for upcoming releases?

A related question is whether www.vosao.org should represent the current release
(0.1) or the upcoming release (0.2). The latter is easier but can confuse new 
users
who grab the latest stable release. 

A middle path is write the documentation so that we can insert notes like 
"Since 0.2"
to indicate when a feature first became available. This approach means we have 
to be
more careful when writing the documentation, but it can produce the best long 
term
result.

Original comment by ted.husted on 31 Dec 2009 at 1:47

[GoogleCodeExporter]

Hmmm, or given Vosao's site backup and restore capabilities, once we catch up 
on the
TODOs, we could setup a development web site (like dev.vosao.org), and make the
changes for the next release there, and then restore it over the production 
site when
the WAR is released. 

When I worked on Struts, we would create a copy of the web site for each 
release, so
people could refer to the documentation whichever release they were using. 

* http://struts.apache.org/2.0.14/

In practice, organizations cannot always get authorization to use the "latest 
and
greatest" version, and so developers need a copy of the documentation for the 
release
they are able to use. 

Of course, with Vosao CMS, in the future, we can always make the site backup
available to people using an older version. (Not so important now because we can
expect early adopters to stay current.)

Original comment by ted.husted on 31 Dec 2009 at 1:56

[GoogleCodeExporter]

Brought a few pages over so far, but haven't approved the updated versions.

* Developer
* Features
* recaptcha 
* Design Template 

Original comment by ted.husted on 31 Dec 2009 at 3:40

[GoogleCodeExporter]

Since majority of visitors are coming to google code site we need to have a 
nice 
overview page with listed features. For details users should go to vosao.org 
site.
We can leave only wiki home page for overview. Other pages: Release notes, 
Roadmap, 
etc. will be links to vosao.org site.

Original comment by kinyelo@gmail.com on 1 Jan 2010 at 10:08

[GoogleCodeExporter]

For me the best strategy in documentation management is to use "Since 0.2" 
approach
before we  release 1.0 version. After that we can use dedicated website for 
every
major release or create web site copy for every release like used in Struts.  

Original comment by kinyelo@gmail.com on 1 Jan 2010 at 10:25

[GoogleCodeExporter]

> create web site copy for every release like used in Struts.  

Could that be an actual static HTML export of the site? 

Aside from our own archival needs, it could be a performance enhancement for 
some
other sites. The Vosao CMS performs well, but for a site that is not going to 
change,
or change any time soon, a HTML version would be even faster. 

Confluence has an auto-export feature that renders a pure HTML copy of the page
whenever the CMS page changes. The public site then loads the HTML version, but 
links
to the CMS version for editing. 

Original comment by ted.husted on 2 Jan 2010 at 6:56

[GoogleCodeExporter]

Static HTML export feature stands in one line with PDF export, DOC export. When 
site
exported this way it becomes unchangeable. 

Current import/export feature satisfy our own needs much better.

Original comment by kinyelo@gmail.com on 2 Jan 2010 at 8:54

[GoogleCodeExporter]

Original comment by ted.husted on 11 Jan 2010 at 2:23

• Changed state: Fixed