If we need to break things out into different namespaces (one Wiki
engine, but a clear split between developer and user info) that can
be looked at.
Can you show me a working implementation of such a clear split?
The most immediate thing I can think of is Wikipedia. They are using
language namespaces to provide a clear split between information that is
available in different languages. This uses a common database, and a
common Wiki engine (so one set of tools to maintain) yet keeps the
information in each namespace unique and separate. It should be noted
though that splitting any set of Wiki pages like this really does split
it... a search in one namespace will not (to the best of my knowledge)
return results from any other namespace. This was the reason (or so I
understand) that the original Wiki was set up without namespaces.
Instead, I believe that putting all project things in
one wiki and all end user help/documentation to a different place (wiki
or not) would make live much easier. As long as one wiki is forced to
serve both groups, one of the groups (the end user) will be irritated
(unless you separate the two content spaces completely as if they were
two completely different wikis - but you will need make big efforts to
get it working).
You are right, it will take a lot of effort no matter which direction we
go. The important thing is to try and spend that effort in the right
direction. :-)
One of the biggest issues is making sure that with whatever change is
considered that people who know the current locations of things are able
to still find things. In the current structure, any shuffling we do is
taken care of by the Wiki itself with the redirect pages.
But looking at the requirements level, it seems rather clear to me: the
end user needs a valuable and efficient (online) information resource
(ranging from help to extended documentation, tutorials and solution
examples contributed by users), which ideally should be taylored to
her/his os/platform. The possibility to leave comments or to edit the
document is desirable but not essential to the user. So in my eyes we
should at first agree what the respective target groups' requirements
are - and only then look at their best implementation.
This is something that has been discussed a couple of times. Some
people champion Plone or Drupal, others say leave things as they are,
others want a whole new Wiki rolled out.
There has already been some information and work done on this and
collected here:
http://wiki.services.openoffice.org/wiki/Documentation/Dashboard/CMS_Evaluation
but no action has yet been taken on it, and it has received very little
attention from the community in general (it also has not yet been well
broadcast to everyone).
C.
--
Clayton Cornell [email protected]
StarOffice - Sun Microsystems, Inc. - Hamburg, Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
