On 14/06/2011 23:08, Rob Weir wrote:
Note the requirements here under "Using a wiki to Create Documentation". It
looks like we need to restrict write access to that wiki to those who have
returned iCLA's to Apache.
This is correct if you intend for the wiki content to be made available
via your project website or distributed as part of a release. I don't
think this is necessary if you have a wiki in the cwiki.apache.org or
wiki.apache.org and have no intention of exporting this content (other
mentors will correct me if I'm wrong).
http://incubator.apache.org/guides/sites.html
I wonder if this becomes easier if we segregate the documentation onto its
own wiki?
We have an SVN backed CMS system which is ideal for building project
websites. As Joe said elsewhere this is a home-grown, markdown based
system. It has the advantage of providing both a web based and SVN based
editing environment (although to be honest the web based interface is
usable but clunky - don't tell Joe though he wrote it for us -
volunteers welcome)
For documentation that you intend to distribute this is probably the
best system as you don't have to maintain separate access rights and
people can work offline with the sources. It also means that your
documentation writers are treated as first class citizens on ASF
infrastructure.
The downside is that your documentation writers will need to be able to
use SVN and some simple python scripts to work efficiently (the web
interface is fine for quick edits).
The CMS doesn't seem to be mentioned on the page you link to above. For
more info see http://www.apache.org/dev/cmsref.html
Ross
-Rob
On Tue, Jun 14, 2011 at 5:53 PM, Dave Fisher<dave2w...@comcast.net> wrote:
If we want to have different groups of users with update rights we
should definitely have two wikis.
See https://cwiki.apache.org/CWIKI/ for the instructions regarding
confluence.
We could start with the following confluence wiki spaces:
(1) ooo-dev - for developer facing documentation.
(2) ooo-user - for a prospective user wiki. We can debate whether
confluence, MediaWiki, moinmoin or ? are best by experimenting with
various approaches.
I don't understand, you just said you would start to create a
Confluence ooo-user space to debate whether to use a different
engine?
There is probably overlap between (1) and (2) so it needs to
be clearly defined what goes where. With (1) you are probably
referring to core development (coding OOo), but there is also
extension development (using UNO to develop extra functionality)
or office automation that probably are better placed in (2) (for
the developer-user).
For (1) you understand me correctly. This is the space we need now to start
doing all the planning and development blueprints.
For (2) I mean a possible way to handle the package user and/or developer
user documentation that will be migrated from the wiki at openoffice.org.
BTW - It should not be hard to move content between two confluence spaces
if it is put in the wrong location.
If we plan to reuse existing wiki content for docs, it would be
easiest to continue to use MediaWiki (if this is an option)
since this is where all content currently is. A lot of the
content in the docs section uses MW features like
subpages, auto page lists, templates/transclusions etc that
may be cumbersome to migrate.
To use MediaWiki someone will need to contribute at infrastructure-dev.
Otherwise it is moinmoin or confluence. I don't care so much, but confluence
is well supported here at Apache so it is an easy choice.
For (3) the options are greater and we can change.
I know we need (1) and it is not much harder to do (2) and (3)
prospectively and let the rest of the PPMC decide.
Here is the jira issue: (INFRA-3684) Create 3 CWiki Spaces for OpenOffice
Regards,
Dave
Frank
