Great idea! It will make it easier and more motivating to write
documentation , because you see result almost in an instant. On top of
that there are lots of other advantages, like more flexible styling
possibilities, export/import to other spaces, etc.
Big +1 !
Dennis
David Jencks wrote:
+1 to the "expanded" proposal. Even I can manage to write
documentation in confluence :-)
I'm by no means a confluence expert but I believe it is much easier to
create a new space as a copy of an existing one than it is to copy
content from one space to another. So, when creating a space for a
new release I strongly advise copying the space for the previous
version and then modifying it for the new release.
thanks
david jencks
On Mar 5, 2008, at 6:49 AM, Ate Douma wrote:
Carsten Ziegeler wrote:
Big +1 for using Confluence; we are using it for several projects
(Felix, Sling, Jackrabbit) already and it works nicely.
If they have a CLA on file, and are contributing to the official
project
documentation, they *ARE* Committers. They just aren't coders,
and don't
have SVN access.
Well, that's not how I understand how it is described on the CWIKI
page, or even here:
http://www.apache.org/foundation/how-it-works.html.
Although a committer must have a CLA on file, can't a "contributer"
have a CLA on file too without being a committer?
Yes, that's how we do it in other projects. You need a CLA and then
can contribute to the docs without being a "svn committer".
Cool, that's what I thought too.
Ate Douma wrote:
> My proposal is simple:
> - switch to using this Confluence+cwiki solution
I assume you mean for the whole portals project. +1
Well, I indicated upfront to propose this (initially) for Jetspeed-2
only.
But of course, I'd like to see this to be extended to the whole of
Portals project too.
See also my comments below.
> - maintain separate Confluence spaces for release specific
documentation
> for jetspeed-2, j2-admin and future products
Hmm, not sure if we need this. So this would also include to have a
specific space for Pluto, Bridges etc?
Yes, and even potentially, depending on the goals for each project,
distinct spaces per each (major) release.
See for example how Geronimo handles this:
Main website space - http://cwiki.apache.org/GMOxSITE/
Trunk development space - http://cwiki.apache.org/GMOxDEV/
Geronimo v1.0 space - http://cwiki.apache.org/GMOxDOC10/
Geronimo v.1.2 space - http://cwiki.apache.org/GMOxDOC12/
Geronimo v.2.0 space - http://cwiki.apache.org/GMOxDOC12/
etc.
Now, if we are going to extend my proposal for the whole of Portals
project (or at least including the main site), we might optimize this
a bit.
In my view, there is/should only be a need for one primary (release
independent) website space.
This space (PORTALS) can then contain all general information for
both the Portals project (like http://portals.apache.org) as well as
for the subprojects (Jetspeed, Pluto, Bridges, etc.).
Then, each sub project can need additional release related spaces,
like J2xDOC213, J2xDOC22, PLUTOx115, PLUTOx20, BRIDGESx104.
Finally, we can simply switch to one Confluence space for the
"public" wiki for the whole Portals project too, something like
PORTALSxWIKI.
> - integrate all the above in one new main cwiki based jetspeed-2
project
> website
Can you elaborate a little bit on this one please?
The global PORTALS space should integrate all of the above spaces
similar to how other projects do this, as well as additional
resources like generated javadocs, reports etc. for which we still
can use maven but need to provide links to from the Confluence space(s).
So, if you would want to expand this proposal to include Portals
itself, Pluto, Bridges, maybe even WSRP4J etc., +1
Ate
Carsten
